Ante: A low-level functional language

The dot product example gave me pause because map2 seems to be the same as zipWith. Does that exist in Ante? Without context I might have thought map2 was going to act as bimap. Take that for what you think it's worth :)

Also I might be having a brain fart -- but isn't the dot product in your example equal to 32?

Joking aside, looks cool, good luck with the project!

Joking aside, looks cool, good luck with the project!

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.

I've found Clojure to dominate the ease of parallelism. For problems that are actually stupidly parallel the number of changes to your code is often measured in letters rather than lines. For example, you might change map to pmap or you might change reduce to reducers/reduce and change nothing else but now be fully leveraging all your cores. For problems that aren't stupidly parallel I feel like Clojure shines even more. Most languages didn't implement software transactional memory and encourage it as the default way to work with things that vary over time, but Clojure did. On account of that you can have a not massively parallel algorithm that would be full of tricky lock code in another language and still end up leveraging all your cores by doing something as simple as map or pmap, but not run into horrible issues.

If your standard function call convention is just `f x`, but you also support precedence operators, then `f (x)` automatically becomes possible.

It reminds me of an old Lisp joke, though:

    f x   -- too mathematical!
    (f x) -- too many parenthesis!
    f(x)  -- just right!

For the same reason you'd make 1 + 2 the same as 1 + (2). Parentheses can be used to group arbitrary subexpressions.

1 and (1) are isomorphic. A single term tuple can be converted to the single term, and vice versa. Having an implicit conversion doesn't seem too crazy.

The biggest issue I suspect would be confusion about the most idiomatic way, or a mix of styles in real-world code bases, that causes confusion or inconsistencies (increases cognitive load for the reader).

A good number of "functional programmers" only have experience with JavaScript these days.

This expression matches on the effect flip() and handles it with the code on the right hand side of -> which becomes the value of the function invoking the effect. In this case the handler runs the continuation for both possible values (resume true and resume false, i.e. the function was called once, but it will return twice, with true and false substituted in the place of flip() in the place which used this effect) and returns their mean as the average.

I.e. each time calculation calls flip(), the effect handler will continue the function for both true and false and then take the mean of those two results. Comments explain that flip() should simulate a coin flip, which generally gives equal probability (1/2) to true and false. Each flip() in calculation was simulated with equal number of true and false values, so it fits the expected distribution. Each time taking the mean of those values is just an expansion of the integral calculating the expected value, as per definition of expected value.

Note that there is some recursion here. While the flip() handler is executing for the first invokation of flip(), another instance of the handler will execute for second and third invokations (inside resume true). I.e. it calculates the expected value by taking the mean of the expected values of each branch created by a flip. When a branch doesn't have any more flips inside, its expected value is taken to be the constant value that this branch returns.

the `| flip ()` is pattern matching on that effect term, I believe. So essentially: when you see `flip ()` inside anything in the argument of `expected_value`, capture the continuation there, run that argument once with `true` and once with `false`, add the results, divide by two.

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.

Your concern on refinement types is definitely valid and is something I've been thinking about. They are certainly useful in some cases like array indices or passing around certain predicates but whether these are useful enough to offset the implementation cost and brain tax is an open question.

I'll avoid posting it here but if you do want to follow ante's development the best place is on its discord which is linked on the github page.

Might be my 2 cents, but i think Rust can hit a very sweet spot for functionally-leaning low-level effective programming.

For example, ATS is ostensibly an ML-like language; but its "low level" examples look more like "C with stricter types" (e.g. its Cairo examples)

https://en.wikipedia.org/wiki/ATS_(programming_language)

That is how Lisp Machines and Xerox PARC workstation OSes used to be built, or Mirage OS for a more recent example.

And I do consider Lisp functional, since when I reached university, the options were Lisp dialects, Mirada was fresh, Standard ML and Caml Light were rather new.

There was yet to appear the mentality that OCaml / Haskell === FP.

Generally I think FP has a bit of a misguided bad rep when it comes to performance. What makes code slow is indirection that a compiler cannot reason about and work that doesn't need to be done. There are FP techniques that can help a compiler or CPU to generate/transform efficient code and ones that can confuse them so to speak. Needless mutation can sometimes lead to bad code as well (from a compiler or CPU perspective), because it solidifies control. Functional programming is fundamentally a constraint, computers, interpreters and so on like constraints, because they can then go about shuffling around stuff without breaking those constraints if that makes sense.

[0] https://www.roc-lang.org/

[1] https://en.wikipedia.org/wiki/Tim_Sweeney_(game_developer)

I'd like to remove iterators in favor of Generators (implemented with Algebraic effects) in the future though since they're much easier to define. Actually switching over is on hold until effects are implemented and speed tests are done to ensure they're compareable speed to iterators (which they should hopefully be due to monomorphisation of effects + handlers).

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)).

> In general, ante is low-level (no GC, values aren't boxed by default) while also trying to be as readable as possible by encouraging high-level approaches that can be optimized with low-level details later on.

IMO the only low level language is assembly. Everything else is some form of abstraction. C/C++ and the likes I tend to call lower, since in 2022 it is closer to the hardware, and then sugar languages like python, c#, js, and the likes I call high level.

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.

(2): Thanks for the resource, I'll look it over :). I remember seeing a vaguely related note that multicore OCaml used to provide a `Obj.clone_continuation` function but no longer does. Of course, ante's algebraic effects design is rather different so that may not apply anyway. It may depend on the Generator whether it is cloneable or not. Some generators are just functions that can be arbitrarily cloned, but others are closures which may have restrictions in whether their environment is cloneable. Ante's clone story in general needs more work.

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.

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).

Generally, the entire site has a really nice design, at least on desktop. One of the prettiest I've seen.

Also, black text on white background is easier to read.

And don't make your web design to complex for Firefox reader mode to work: if you do, that's a sign you're doing it wrong.

The specific design is still in question though. For one, an effect like Allocate will be almost ubiquitous throughout each function so care is needed to not clog up signatures too much. There's a few potential solutions here if you're interested. From including Allocate within the row-type of a larger effect like `IO = can Allocate, Read, Write, ...` to encouraging effect inference on functions versus manual annotation.

The author said somewhere else in the thread they want to switch to generators implemented with effects eventually.