Dreaming about end-user/programmer use-cases about basil HOT 2 CLOSED

Okay, gonna respond to each of these in turn:

1. Teishi seems...complicated? To the point I'm not entirely sure what it's doing in these examples...😓 But it's vaguely in the plans to support compile-time assertions to a deep level. Since Basil makes it relatively easy to manipulate compile-time evaluation (all code is evaluated at compile-time by default!) all we really need to enforce assertions is some kind of assertion/error primitive - which should be quite trivial to add as a compiler builtin. Since Basil functions are also generic (meaning dynamic at compile time) by default, we could add quite expressive assertions very naturally:

def foo x? =
    if x < 0 then # reports compile error
        error "Expected non-negative argument in 'foo', found " + x as String
    # do function body...

Of course, in this case, x < 0 will only be resolvable at compile time if the input x is resolvable at compile time. We could consider extending this with some kind of dependent typing...but that would be pretty involved. At bare minimum, asserting arbitrary conditions about compile-time constructs (like modules, types, etc) should be pretty straightforward.

2. Seems like it wouldn't be too hard to represent in Basil somehow! Not all syntax can be represented 1:1, there's still some context-free core syntax in Basil that is hard to work around (like parentheses or indentation for code lists). But you would at bare minimum be able to embed some kind of similarly-structured representation in the grammar, and theoretically it wouldn't be too hard to attach a code generator to the backend of that.

3. Async is a huge can of worms I'm not really qualified to make judgements about at the moment. My cursory answer to this is I'd rather have something more like green threads or goroutines or whatever, and support structured async through threads. But this is really up in the air at this point.

4. Seems like something like PythonCall is best left up to a third-party library - I assume it operates through some CPython API? Not sure Python is general enough to include in the language or stdlib core but I'd like to ensure Basil is powerful enough to express such an API effectively in userspace.

5. Basil already sort of supports native compilation - I've successfully run small "hello world"-type programs (literally hello world, as well as factorial and recursive fibonacci) from a C main function, as well as called C functions from Basil using a past extern function interface. Since the backend is in the process of being totally rewritten at the moment, the exact interface we'll use going forward is kind of unclear. But ideally I'd like to support both static and dynamic linking with native object files, and support dynamic linking within Basil's JIT.

6. Oh man. This seems like a bit of a stretch...I'd say this would be best left to userspace, I don't think persistence is essential to enough use cases to merit making it the default of the language. Interesting concept but Basil is getting big enough as-is...😅

from basil.

1. ...At bare minimum, asserting arbitrary conditions about compile-time constructs (like modules, types, etc) should be pretty straightforward.

I think this is the safe and good beginning. Later we could add some examination of the type itself to check for only certain aspects of the given type (see the rabbit hole starting at 21:01 to understand what I mean 😉).

2. Seems like it wouldn't be too hard to represent in Basil somehow! Not all syntax can be represented 1:1, there's still some context-free core syntax in Basil that is hard to work around (like parentheses or indentation for code lists). But you would at bare minimum be able to embed some kind of similarly-structured representation in the grammar, and theoretically it wouldn't be too hard to attach a code generator to the backend of that.

Perfect. The goal wasn't to do 1:1 syntax, but something very closely resembling it and having the corresponding "expected" semantics.

3. Async is a huge can of worms I'm not really qualified to make judgements about at the moment. My cursory answer to this is I'd rather have something more like green threads or goroutines or whatever, and support structured async through threads. But this is really up in the air at this point.

What I wanted to say by that paragraph was actually that I want to strongly discourage you from implementing async support at the language level. There can be of course some backend support for it (e.g. for performance reasons), but it must not interfere with "true" parallelism, with error handling, etc. And second it must not influence the Basil language per se. Therefore I've proposed async as an independent part of stdlib (probably tier 2).

We can discuss this in a separate issue if you think this is too radical. But I think you're well aware that async is by far not a scalable solution to most problems (if you didn't yet, enjoy reading http://joeduffyblog.com/2015/11/19/asynchronous-everything/ and dozen of other posts about how async is a "cancer" etc. - I actually like it, but only if it's contained & well separated from the rest & explicit - as demonstrated e.g. by the Julia async support).

4. Seems like something like PythonCall is best left up to a third-party library - I assume it operates through some CPython API? Not sure Python is general enough to include in the language or stdlib core but I'd like to ensure Basil is powerful enough to express such an API effectively in userspace.

Yes, it uses CPython API. And yes, I meant it to be in userspace (tier 2 stdlib).

5. Basil already sort of supports native compilation - I've successfully run small "hello world"-type programs (literally hello world, as well as factorial and recursive fibonacci) from a C main function, as well as called C functions from Basil using a past extern function interface. Since the backend is in the process of being totally rewritten at the moment, the exact interface we'll use going forward is kind of unclear. But ideally I'd like to support both static and dynamic linking with native object files, and support dynamic linking within Basil's JIT.

👍

6. Oh man. This seems like a bit of a stretch...I'd say this would be best left to userspace, I don't think persistence is essential to enough use cases to merit making it the default of the language. Interesting concept but Basil is getting big enough as-is...sweat_smile

😜 Yep, it's crazy, but I think some tier 2 stdlib project might take that route - could be interesting to see it. I just don't necessarily want Basil to block such crazy but cool concepts by making a decision in its architecture or syntax which would essentially prevent such free use 😉

from basil.