Ah, yes. The carousel has been a source of frustration especially on mobile for designing the website. Perhaps disabling swiping to scroll on the carousel on mobile would help. Or defaulting to use a dropdown to select the example on mobile instead.
203 karma · joined June 17, 2017
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: I'll add to this a point I haven't seen discussed before about functional languages using the `f a b` syntax specifically. Without significant whitespace you cannot really have semicolon ellision with this syntax since almost any line may be interpreted as a function application of the next line. E.g. `a = b + c` and `foo 32` as subsequent lines would be interpreted as `a = b + (c foo 32)`, hence why ocaml requires semicolons. For some people semicolons are fine, but they're just noise to me :)
There's more detail on the specific significant whitespace scheme used on the website here: https://antelang.org/docs/language/#significant-whitespace
You don't touch on it, but there are some more difficult cases with lifetime inference as well. Namely branching the compiler must decide whether or not to extend a refs lifetime. This and a lack of granularity in container types are known problems with region inference (they lead to more memory than necessary being used by assuming the longest lifetimes), and are things I hope to tackle.
Function arguments are passed by value currently, though I may explore pass by move and other options in the future.
I hope for ante to be usable without a heap, though the `ref` type automatically handling lifetimes makes this more difficult. These refs compile to an equivalent of destination-passing in C, but can require dynamic allocation if a function creates a ref and another function calls the first in a loop. I also plan on having an Allocate effect for whenever a function can allocate, so that it is trivial to handle this with your own handle that can do anything. This would be an easier alternative to zig's approach of "pass the allocator everywhere manually," but there are still things I need to iron out, like how it interacts with the lifetime inference issues above, so its still in the design phase.
As for the examples, they definitely showcase things that aren't present in most languages and can thus be confusing. That is on purpose though, since ante for me is a language to experiment with novel features I find interesting. The second example on lifetime inference for example can be thought of as like rust's lifetimes but completely inferred and instead of issuing errors for "x does not live long enough" it will instead automatically extend the lifetime of x. So my hope is it is easier to use at the loss of some control (control can be regained by using other pointer types like `Ptr a` for a raw pointer used to implement other things on top of).
These are all checked at compile-time though, since interpolation can only be done inside string literals we can check for all uses of ${expr} inside literals and ensure e.g. that expr is convertable to a string. Since these are only in string literals, all placeholders are known in advance so there are none that cannot be checked at compile-time. (A string like "foo \${" ++ "foo}" must both escape the interpolation begin ${ and is concatenated to the actual string "foo ${foo}" with no interpolation. Otherwise it would be very confusing having interpolation happening in unintended circumstances (and would make string operations less efficient by having to check for this)).
This way of computing expected value works because for each flip we essentially have a case-split: the value can be true or false with a 50-50 chance, so the expected value of the whole thing is is 0.5 * the result of the true branch + 0.5 * the result of the false branch!
This is more of a fun use of effects than a practical one. If you're still curious about effects, check out the full page on them here: https://antelang.org/docs/language/#algebraic-effects which includes some actually useful effects like State, Generators, looping constructs, parsers, etc.
(1) Zero-cost Effect Handlers by Staging: http://ps.informatik.uni-tuebingen.de/publications/schuster1...
That being said, by no means do I claim that all extensions will work together perfectly, or at all. For example, a garbage collector would be completely incompatible with a plugin that frees all variables once they go out of scope. Compatibility is left up to the plugin's author in the case of multiple plugins having conflicting goals.
I'm not sure where I stated I was opposed to making tradeoffs, I have done several (albeit mostly syntactic) already. I knew the project was ambitious when I first started it, that is part of the fun of working on it.
You can extend the compiler's functions during compile-time by doing more than just messing with llvm-ir. You are free to implement an automatic linter, or garbage collector for example. You can even do an optimization pass without operating on the llvm-ir. To do this, you could walk the parse tree of a function before it compiles and change around any common node patterns you are looking for before it is translated to llvm-ir. Alternatively, you can muck around in the ir and do the same thing.
The goto construct in the example provided does not need to be deeply integrated because the existing API is setup largely separate from the internal structure of the compiler. For example the function ctStore stores a variable in a compile-time container separate from the scope-separated table used internally by the compiler for other variables. The primary advantage of Ante as a language is that these functions enable compiler extensions to be made within the program and thus allow the swapping out of, eg. a garbage collector, without recompiling the compiler itself. This lets each application developer decide what features they need for their application. Instead of changing languages for a gc or desired optimization pass, just swap out a library.
I share your concern with the LLVM library constantly updating and the need to update bindings with it. I plan sometime to use the clang api to make a C++ -> Ante converter program, although I expect there to be numerous difficulties with its implementation.
One of the only disadvantages is that because llvm is so large it requires some odd build steps that can be a pain to setup, especially on windows. The llvm-config tool however, manages many of required flags for you. Also, because there are so many libraries, compilation of the compiler itself can be rather slow.