Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ante: A low-level functional language

antelang.org

Post reply on HN
Print view View original

11–20 of 226 posts

Re: Ante: A low-level functional language

#11

Post by dthul »

Looks very cool! Can somebody enlighten me what's happening in the Algebraic Effects example? Specifically this part:

    handle f ()
    | flip () -> (resume true + resume false) / 2.0
Does `handle f ()` call `calculation` and the `| ...` part "injects" the `flip` effect? I am also quite confused by the part following `| flip ()`. It somehow returns true or false with a probability of 50%? And why does this give you the expected value of the whole calculation function in the end?

Re: Ante: A low-level functional language

#12

Post by mellavora »

tazjin wrote: post #5
Escapado wrote: post #3

The syntax looks a little funky to me but it's still quite interesting. Is there a reason why you would make fn(1) and fn 1 equivalent? For me personally it makes readability worse and looks strange when chaining functions like in their last example on their landing page. On mobile horizontal scrolling through the code snippets will trigger switching to the next snippet on my phone.

> Is there a reason why you would make fn(1) and fn 1 equivalent? 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!

As an old lisp fan, I never got this. (f x) and f(x) have the same number of parenthesis.

and the nice thing about (f x) is that the parenthesis group f with x; so you have the whole call inside the (). Consistent and simple to understand.

vs i.e. print(f"a string"), where it isn't even clear that the "f" is a function call.

Re: Ante: A low-level functional language

#13

Post by HelloNurse »

How does string interpolation work? In what context, exactly, are the placeholders checked and/or evaluated? How are missing or incompatible placeholder values handled? The semantics aren't obvious (for instance, how do you deal with string inputs, which would contain placeholders that cannot be checked in advance?).

Re: Ante: A low-level functional language

#15

Post by junon »

mellavora wrote: post #12
tazjin wrote: post #5

Earlier quoted context omitted.

> Is there a reason why you would make fn(1) and fn 1 equivalent? 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!

As an old lisp fan, I never got this. (f x) and f(x) have the same number of parenthesis. and the nice thing about (f x) is that the parenthesis group f with x; so you have the whole call inside the (). Consistent and simple to understand. vs i.e. print(f"a string"), where it isn't even clear that the "f" is a function call.

That's the joke. The number of terms doesn't change, and the last two have the same number of parens. The statements relate quantities of those things as though they're a problem, when in reality the "just right one" only changes the order slightly.

Hence the joke. It's one of those jokes that earns a loud sigh from me, rather than a chuckle.

Re: Ante: A low-level functional language

#16

Post by YetAnotherNick »

mellavora wrote: post #12
tazjin wrote: post #5

Earlier quoted context omitted.

> Is there a reason why you would make fn(1) and fn 1 equivalent? 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!

As an old lisp fan, I never got this. (f x) and f(x) have the same number of parenthesis. and the nice thing about (f x) is that the parenthesis group f with x; so you have the whole call inside the (). Consistent and simple to understand. vs i.e. print(f"a string"), where it isn't even clear that the "f" is a function call.

> (f x) and f(x) have the same number of parenthesis.

That's the joke

Re: Ante: A low-level functional language

#17

Post by roelschroeven »

markoutso wrote: post #14

How is this low level exactly?

It's not, or only partially. "To try to bridge the gap between high and low level languages, ante adapts a high-level approach by default, maintaining the ability to drop into low-level code when needed." says the website.

Re: Ante: A low-level functional language

#19

Post by chriswarbo »

epolanski wrote: post #8
DeathArrow wrote: post #2

Very interesting stuff! I didn't even thought is possible to implement a low level functional languages, I always thought a functional language requires a ton of abstractions.

At the end of the day what prevents functional languages from being a good fit for low-level programming is that effective low-level programming cannot be referentially transparent. Might be my 2 cents, but i think Rust can hit a very sweet spot for functionally-leaning low-level effective programming.

> At the end of the day what prevents functional languages from being a good fit for low-level programming is that effective low-level programming cannot be referentially transparent.

I'm not sure I agree. "Straightforward" FP, e.g. a bunch of functions defining local vars and calling other functions, can be pretty hard to make low-level (it pretty much assumes a GC, and indirected closures; although tech like linear types can help).

However, the more abstract, point-free, pattern-heavy FP seems like a reasonable fit (e.g. pipes/conduit)

Re: Ante: A low-level functional language

#20

Post by GrumpySloth »

dthul wrote: post #11

Looks very cool! Can somebody enlighten me what's happening in the Algebraic Effects example? Specifically this part: handle f () | flip () -> (resume true + resume false) / 2.0 Does `handle f ()` call `calculation` and the `| ...` part "injects" the `flip` effect? I am also quite confused by the part following `| flip ()`. It somehow returns true or false with a probability of 50%? And why does this give you the exp…

Explanation based on my familiarity with Koka:

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.

Post reply on HN