New release when?

[Borderliner]

It's been more than 2 years sonce the last release. Are there any plans for newer releases? I really want to use Gerbil, but not having new releases is a bit concerning for me.
Thanks for the awesome project.

[vyzo]

Hi!

Very understandable.
We are working on v0.19 specifics in the v0.19-staging branch, tracked with prs. Quite a few things are changing... Hard to say when we release, but there is definite progress.

Master is quite stable nonetheless.

[Borderliner]

Awesome, thanks! Please keep this issue open until the next release to stop further questions for those who search it.

[vyzo]

Yes, that's a good idea.

Let me give you a bit of context and background at what the current status of development is.

Since the last release, v0.18.1, a great deal of work has been done.
The MOP has been completed, and gerbil is internally strong typed -- partially static when the compiler can proves, and using contracts for necessary checks when it can't.

Initially the plan was to do a series of smaller releases -- see https://github.com/mighty-gerbils/gerbil/discussions
This is not how it played out however. Little by little, the type system was implemented in the compiler and the syntactic layer manifested for annotating types and before you know it, you can have safe fully statically typed gerbil modules already with some pretty good performance, because all the runtime checks can be eliminated once you are past the interface boundary.

This all works in current master. After careful consideration, we decided that there is no point in smaller releases (it has already taken us a whole while, and i couldn't type for a while because of RSI.

Anyhow, we also realized that we need to finish certain thing and that now is the time to make breaking changes, as we want to v0.19 to be stable and the next release will be v1.0, when we add the fully syntactic layer for the type system, things like constraints, effects, pre and post conditions, and some pretty fancy things that can let you write safe code that is highly performant. Really, for a fully statically typed module, the baseline is C.

And thus the #1398 v0.19-staging branch was born, anchored in a v0.19.-dev tag. The plan here is to go through the entire stdlib code base and clean up old craft an debt, some of this code is 15 years old or more. Once we reach v1.0 we will make a promise, similar to go, that code that works with v1.0 will continue working in the indefinite future. Simple as that.

So no we are going through the stdlib and restructuring, throwing away cruft and modernizing the code to be fully typed.
In the process we also made some decisions:

• srfi will move to an officially maintained packages in mighty-gerbils
• r7rs prelude too

We will ensure that those packages work and have first class perrformance at release checkpoints.
This in turn will allow us to remove a lot of code that I don't deem of sufficient quality for the main tree -- I am talking about all the srfi code from reference implementations, with no tests, poor performance, and questionable design choices.

Also, to avoid misunderstandings, we are fully committed to supporting r7rs; however Gerbil has moved a long road from them, It is now a fully object oriented LISP, with type classes (Interfaces!) and machinery that no other languages have.
It is still a Scheme of course; but it is more of a rosetta stone scheme, so taking the r7rs prelude independent is a good thing as it will ensure that we have clean and well defined interfaces for implementing custom language preludes.

Some things to track:

• V0.19: layout restructure and test basis #1399 this is pretty much ready, we need to add some more tests
• V0.19 dev format #1408 that's what I am current working on,

And I think we should convert this to a discussion.

[vyzo]

An important change that has already happened in #1399 is that procedures with contracts now can be lift the contract checks to the call site. This has some very important effects: the call site has more type context, and so contract checks can be easily be peval'ed out.

Also bindings now have properties, and an associated type and macro -- macros already in use for the contract check lift, types will soon be in use so that type information is visible to macros (right now in master a lot of it is only avaiable at the compiler).

[Borderliner]

@vyzo Thanks for the detailed clarification. Once thing that I didn't quite understand is that will we have static typing (or type hinting) on dev space, or is that all internal?

[vyzo]

another note here: for v1.0, we want to have a restricted/safe prelude that won't let you use any unsafe thing directly.

[Borderliner]

@vyzo That's amazing. One of the biggest Scheme (and in general Lisp PL family) flaws is type checking/safety. Dynamic typing is easier to write but adds maintenance burden the bigger the project gets. Static typing is necessary especially for a system PL. Can't wait to try them!

[vyzo]

Yeah, I totally agree with you -- it is hard to maintain systems code when you constantly have to guess and dig around to figure out types. Also quite annoying when you are trying to fix something.

A nice side effect is that we have finally solved the comically long procedure names problem that has plauged lisps since the beginning. Now you specify the class or interface and dot away.... almost python easy.

[Borderliner]

@vyzo My main concern though is that adding static typing can pose a significant challenge to macros. Expanding code is fairly easy for dynamic typing, but for static ones it could be a source of major bugs. I believe there has to be some sort of compile time macro expansion just like how Rust does it. Even then it wouldn't be as powerful as regular Scheme macros because you can go pretty nuts with them and I think it would be very challenging to offer the same power in static typing.

[vyzo]

well, the idea is to have types fully visible to user macros.

So you can look up a binding for its type info, and you can do type directed expansion. I dont think there is any need to dump things down. One can certainly derive macros for specific pattetns.