Is there a reason not to force a linear typing system (at first) -- a la mercury? To simplify the lifetime analysis? And then in later versions that can be relaxed to affine typing, and then subsequently normal lifetimes?
Ante: A low-level functional language
141–150 of 226 posts
Re: Ante: A low-level functional language
#142Very interesting to see you essentially replace Tuples with Cons! I'll be following that development for sure. Coming from Scala, Tuples are entirely how you represent Product and then that has tons of downstream implications on case classes and constructors. This leads to situations like Scalaz creating NonEmptyList to get Tuple-like behavior out of List. So your approach has the potential to unify these similar but different types and I find that fascinating!
Re: Ante: A low-level functional language
#143Hello, author here! As the website says, the compiler itself is still in a very early state where basic things like functions, types, traits, inference, monomorphisation, and codegen are implemented. The fun stuff of algebraic effects, lifetime inference, and refinement types are not however. Though I can elaborate on implementation strategies of these for anyone curious. For example, algebraic effects in existing la…
Very neat project! I noticed that Ante doesn’t have explicit region type declarations. As I recall, existing algorithms implemented for ML can sometimes infer very large regions which causes memory usage to balloon. It looks like smart pointers are part of the plan to address that possibility, but I’d love to hear more about your thoughts on memory management.
Correct, a key goal is to have no explicit region/lifetime annotations. There have been several papers on region inference after the originals by Tofte & Taplin, all attempting to refine the original analysis by inferring shorter lifetimes. First by analyzing when a region can be safely emptied and re-used, then by abandoning the stack discipline, etc. Unfortunately, none of these are viable in a real program in my opinion. Although they each infer shorter lifetimes in a few cases the core problem of "collections will unify the lifetime variables of all elements in the collection" and "branching on a value and conditionally returning it extends its lifetime, even if the branch was not taken" remain unsolved.
An ideal solution to me needs to solve these problems. Since there is already a large body of research trying to address this on the static side and failing, I believe it needs to be solved with runtime checks. The specifics of which I'm still exploring but its worth mentioning these would only be necessary to tighten existing lifetimes so one can envision annotations or compiler options to elide these if desired. Lifetime inference in MLKit (and I believe ante as well) tends to speed things up by turning more dynamic allocations into stack allocations, so there is some room there for runtime checks without making the result more expensive than the version with dynamic allocation I believe.
Re: Ante: A low-level functional language
#144Earlier quoted context omitted.
I'd really like to find "the low-level functional language" without "the fun stuff". Or at least it should have simple and boring subset that is usable without "the fun stuff". Something like Caml Light - precursor to Ocaml - but with translation to C instead of bytecode, so it will be fast and will have comfortable integration with C libraries.
This is definitely an interesting thought. My thinking is that "the fun stuff" tends to help make the language more functional, so removing it you are left with a more imperative language resembling a C clone with traits and type inference. Then if you want easier C interop you must remove traits and either remove modules as well or provide a standard method of mangling module names into function names. At that point…
what makes Ante low level? Just from a cursory look over the website seems pretty high level to me.
Re: Ante: A low-level functional language
#145Earlier quoted context omitted.
I'd really like to find "the low-level functional language" without "the fun stuff". Or at least it should have simple and boring subset that is usable without "the fun stuff". Something like Caml Light - precursor to Ocaml - but with translation to C instead of bytecode, so it will be fast and will have comfortable integration with C libraries.
This is definitely an interesting thought. My thinking is that "the fun stuff" tends to help make the language more functional, so removing it you are left with a more imperative language resembling a C clone with traits and type inference. Then if you want easier C interop you must remove traits and either remove modules as well or provide a standard method of mangling module names into function names. At that point…
[deleted]
Re: Ante: A low-level functional language
#146Earlier quoted context omitted.
This is definitely an interesting thought. My thinking is that "the fun stuff" tends to help make the language more functional, so removing it you are left with a more imperative language resembling a C clone with traits and type inference. Then if you want easier C interop you must remove traits and either remove modules as well or provide a standard method of mangling module names into function names. At that point…
what makes Ante low level? Just from a cursory look over the website seems pretty high level to me.
My definition of low level is no tracing GC, values are unboxed by default, and users still have control to do low level things (raw pointers, other unsafe operations) when needed, even if it is not the default.
Re: Ante: A low-level functional language
#147Hello, author here! As the website says, the compiler itself is still in a very early state where basic things like functions, types, traits, inference, monomorphisation, and codegen are implemented. The fun stuff of algebraic effects, lifetime inference, and refinement types are not however. Though I can elaborate on implementation strategies of these for anyone curious. For example, algebraic effects in existing la…
I'd really like to find "the low-level functional language" without "the fun stuff". Or at least it should have simple and boring subset that is usable without "the fun stuff". Something like Caml Light - precursor to Ocaml - but with translation to C instead of bytecode, so it will be fast and will have comfortable integration with C libraries.
> fun stuff of algebraic effects, lifetime inference, and refinement types
> I'd really like to find "the low-level functional language" without "the fun stuff"
But current stable Ocaml has neither of the "fun stuff" mentioned and compiles to native code. So isn't that exactly what you want?
It doesn't even need lifetime analysis because automatic garbage collection be praised.
And algebraic effects are awesome. Sure they are not mainstream yet but conceptional there is a strong parallel to the Common Lisp condition system which is quite established. Not sure why you wouldn't want to have them. Also it is still a long way until we will see them used in user facing stuff in Ocaml.
Re: Ante: A low-level functional language
#148Is there a reason not to force a linear typing system (at first) -- a la mercury? To simplify the lifetime analysis? And then in later versions that can be relaxed to affine typing, and then subsequently normal lifetimes?
Lifetime inference originates from region inference which is actually completely unrelated to linear/affine/uniqueness typing. Uniqueness typing can definitely complement lifetime inference, but isn't really generalizeable to it.
Re: Ante: A low-level functional language
#149Earlier quoted context omitted.
I'm not a fan of python (it handles significant whitespace somewhat poorly). Cases like mixed tab-space whitespace and single-line only lambdas are python-specific problems for example. I chose it mainly because I like the style and I haven't found it to be an issue in practice yet, especially with flexible rules for line continuations. The biggest detriment to me is the lack of auto-formatters for indentation. Edit:…
Regarding single-line only lambdas, I think that isn't an intractable issue with the grammar. Guido van Rossum basically said parsing them is hard, and he doesn't like lambdas in the first place, so it won't happen. [0] Similar to "tail call optimization encourages dirty FP nerds" logic. Terrible decisions IMHO. [0]: https://www.artima.com/weblogs/viewpost.jsp?thread=147358
Agreed. Other whitespace sensitive languages like Haskell, F#, and Ante handle multiline lambdas just fine
Re: Ante: A low-level functional language
#150Earlier quoted context omitted.
I'm not a fan of python (it handles significant whitespace somewhat poorly). Cases like mixed tab-space whitespace and single-line only lambdas are python-specific problems for example. I chose it mainly because I like the style and I haven't found it to be an issue in practice yet, especially with flexible rules for line continuations. The biggest detriment to me is the lack of auto-formatters for indentation. Edit:…
You claim, significant whitespace helps mitigate "goto fail" errors. As for me, indent syntax allows more human errors during refactoring. When moving code blocks around, you can easily misplace whitespaces and compiler/editor has no ability to help you.
This is definitely an issue, but isn't one I run into often. Just like if I'm pasting code in rust I need to make sure it is inside or outside an if statement, I likewise need to ensure pasted code in ante is inside/outside the if statement by looking at its indentation relative to the previous line. The compiler can help somewhat here, just not a lot. If your indentation is not on an existing indentation level you will get an error since you cannot randomly start indent blocks in your code. I do think the biggest detractor of indentation-sensitive syntax in general is the loss of auto-formatting indentation though.