search

elucent / basil

Stack-based, multi-paradigm language with an emphasis on metaprogramming.
23 stars 0 forks source link

Future plans? #1

Open dumblob opened 3 years ago

dumblob commented 3 years ago

Wow, this is actually kind of an impressive language. Disclaimer: I'm a bit crazy into languages.

I read the TODO documenting mainly the development 3 months ago. It feels Basil has lots of potential! What actually convinced me was the post about stack allocation with copying instead of any heap allocation (that's an older idea some concatenative languages and Fortran etc. use to get up to speed). As a side effect this could make Basil one of the very few fastest languages for Wasm.

I wonder whether there are any plans for Basil? IMHO Basil would deserve some real use cases and for that the first thing needed is seamless first-class support for something like FFI.

I'd be also very much interested if you could comment on the points outlined in https://github.com/arturo-lang/arturo/issues/23#issue-726344173 and then the points in https://github.com/henrystanley/Quark/issues/2 .

Basil seems to have the hardest part kind of solved - namely the decision "eval everything in compile time and make an AST subtree as fallback" (the splice principle) which is something I'm crazy about (see e.g. sassert and assert and claim from the linked issues above).

Thoughts? Comments? I'm really excited about Basil so far!

dumblob commented 3 years ago

Ooops, wrong repo. Maybe this should be moved to https://github.com/basilTeam/basil/issues ?

dumblob commented 3 years ago

@minchingtonak would you also have some thoughts?

elucent commented 3 years ago

Sorry for not responding earlier! Basil is on a bit of a hiatus while we're both wrapping up a semester at university. We'll be getting back to its development over the coming weeks.

Also yes, this is an old repo for an old version of the language - the basilTeam/basil repo is the new one. Not sure if you found the project through the language jam or not, but just to clarify, this repository is for a previous iteration that's basically a completely different language. The new version isn't concatenative, and we probably won't be using stack-based allocation as previously planned - sorry to disappoint if you were interested in those aspects!

To actually respond to your question, we have lots of plans for Basil! The current implementation is a good proof-of-concept, so now our job is basically rounding out what we have (and implementing the things we skipped over for time), and also adding in some new language features to make the language more usable. On the backend side, we need to implement proper memory management (might be going the GC route instead of stack allocation, I suspect it'll be faster) and some compiler optimizations. On the frontend side, you can see some of our current plans on the new repo's issue tracker - more built-in types, type annotations, FFI. I'd also like to try implementing some kind of overloading, and supporting variadic functions, but those will probably be pretty complex given how generic the rest of the language is.

I also just read through your issues for arturo and Quark. I don't know that I have time to respond to everything, and I'm not sure how much of what you said pertains to Basil. But broadly, I think the features you talk about fall into one of two categories with Basil. Some are things we'll be adding as language primitives - things like built-in map types and container operations are on the to-do list at some point, for example - but Basil is intentionally quite a small language and even as we add new features, a small language it will remain. For higher-level features - things like an object system or error handling - the goal is for them to be expressible entirely within Basil using metaprogramming. They might be candidates for the standard library later down the line, but they won't be included in the language core. One final thing that caught my interest was the idea of compiling to C, similar to V. It might be nice to add a C or LLVM backend to Basil at some point, but rolling our own compiler gives us total control over the code generator while also reducing dependencies. The Basil compiler binary is currently under half a megabyte and depends only on libc, and while binary size might not be the biggest deal nowadays, I'd like to think this keeps a few doors open for Basil moving forward - maybe one day the language could be easily embedded as a library in other programs, a la Lua.

Anyway, thanks for the interest! It's great to see people interested in our language, and I hope we can deliver on that in the future. :)

dumblob commented 3 years ago

Sorry for not responding earlier! Basil is on a bit of a hiatus while we're both wrapping up a semester at university. We'll be getting back to its development over the coming weeks.

No need to hurry. Take your time.

  1. Could you move this issue to the correct repo?

  2. Reading in between the lines I suspect I don't have an overall picture of Basil as it stands and its future. Could you elaborate on that once you have more time?

    Maybe a longer blog post pointing out some new currently implemented (i.e. functional as it stands) features, old abandoned features and the future features?

    I'll then revive this discussion with a more accurate points :wink: (I'm especially interested in compile-time evaluation with the potential to get rid of garbage collector altogether).

dumblob commented 3 years ago

Btw. one of the Repl.io judges is an author of Popr language which feels quite low level and rough, but compiles to C (and Verilog :open_mouth:) and has some nice properties and ideas and maybe even similarities which might be interesting for Basil - read more in this presentation.