Ante: A low-level functional language • Hacker News Board

Re: Ante: A low-level functional language

#61

Post by nemaar » Fri, Jun 17, 2022, 12:22 PM UTC

georgyo wrote: post #56

gpderetta wrote: post #10

Earlier quoted context omitted.

> f x -- too mathematical! :) yet we are very happy to use the same syntax in shell scripts or the shell itself.

I've heard this argument before, but this isn't true. In shell, f x y z, x y z are all augments to f. Doesn't matter if f takes one argument, all are passed to the function. With many functional languages this gets very confusing. IE what ie what does `f f x` do? In shell I know for sure. In the example f f x, it might be easy to parse. But in f x y z, any of x y z might be functions.

Most functional languages parse a b c d e f as a(b, c, d, e, f), it does not matter what b, c, d, e, f are. Do you know any language where this is different?

Re: Ante: A low-level functional language

#62

Post by jfecher » Fri, Jun 17, 2022, 12:25 PM UTC

HelloNurse wrote: post #13

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

String interpolation works by expanding to the concatenation of several strings. So a string like "the ${foo}." is expanded to "the " ++ foo ++ ".". There are some things I'd like to change about the current design. Namely it should probably defer to a StringBuilder of sorts, and it should possibly do it lazily so that interpolation can be used in log calls without worry of whether logging is enabled.

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

Re: Ante: A low-level functional language

#63

Post by jfecher » Fri, Jun 17, 2022, 12:30 PM UTC

qwertox wrote: post #34

I'm left wondering if the CSV-example considers commas inside a string field which is surrounded by quotes. The other examples are way too confusing for me, except the first one.

It does not! It was meant to be a rather simple example showing what using iterators look like. Perhaps interesting to note that I'll likely be removing iterators in favor of generators which are easier to use. With monomorphisation of effects it is my hope that they'll be just as efficient, but Iterators will remain until tests prove that is the case.

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

Re: Ante: A low-level functional language

#64

Post by georgyo » Fri, Jun 17, 2022, 12:33 PM UTC

nemaar wrote: post #61

georgyo wrote: post #56

Earlier quoted context omitted.

I've heard this argument before, but this isn't true. In shell, f x y z, x y z are all augments to f. Doesn't matter if f takes one argument, all are passed to the function. With many functional languages this gets very confusing. IE what ie what does `f f x` do? In shell I know for sure. In the example f f x, it might be easy to parse. But in f x y z, any of x y z might be functions.

Most functional languages parse a b c d e f as a(b, c, d, e, f), it does not matter what b, c, d, e, f are. Do you know any language where this is different?

I thought more languages did this but at least nix and ocaml do not actually behave like I thought.

In Ruby however it is a bit more ugly

  def f x
    x + 1
  end

  puts f f 1

> 3

Re: Ante: A low-level functional language

#65

Post by jfecher » Fri, Jun 17, 2022, 12:33 PM UTC

whoomp12342 wrote: post #54

shirogane86x wrote: post #30

Earlier quoted context omitted.

quoting the github readme: > 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.

with no GC, is there compile time segfault checking like rust?

Author here, that is the purpose lifetime inference is meant to serve. It automatically extends lifetimes of `ref`s so that they are long enough. A key advantage of these is avoiding lifetime annotations in code, at the cost of some lack of control since the lifetime is increasingly handled for you. You can also opt out by using raw pointer types though and easily segfault with those.

Re: Ante: A low-level functional language

#66

Post by zeckalpha » Fri, Jun 17, 2022, 12:33 PM UTC

georgyo wrote: post #56

gpderetta wrote: post #10

Earlier quoted context omitted.

> f x -- too mathematical! :) yet we are very happy to use the same syntax in shell scripts or the shell itself.

I've heard this argument before, but this isn't true. In shell, f x y z, x y z are all augments to f. Doesn't matter if f takes one argument, all are passed to the function. With many functional languages this gets very confusing. IE what ie what does `f f x` do? In shell I know for sure. In the example f f x, it might be easy to parse. But in f x y z, any of x y z might be functions.

Many counter examples to this, xargs for one.

Re: Ante: A low-level functional language

#67

Post by jfecher » Fri, Jun 17, 2022, 12:35 PM UTC

roelschroeven wrote: post #17

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.

Author here, to me the lack of a pervasive tracing GC and values not being boxed by default are important for low level languages. That and maintaining the ability to drop down and use low level constructs like raw pointers for optimization or primitives for new abstractions are essential.

Re: Ante: A low-level functional language

#68

Post by agumonkey » Fri, Jun 17, 2022, 12:37 PM UTC

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.

I wish we had stats about sexps (we shall call it the kinthey scale). As a kid what you said was the first thing my brain caught on. It compresses the number of things I had to remember it's ~always (idea arguments...). We can now discuss interesting problems.

Re: Ante: A low-level functional language

#69

Post by georgyo » Fri, Jun 17, 2022, 12:37 PM UTC

zeckalpha wrote: post #66

georgyo wrote: post #56

Earlier quoted context omitted.

I've heard this argument before, but this isn't true. In shell, f x y z, x y z are all augments to f. Doesn't matter if f takes one argument, all are passed to the function. With many functional languages this gets very confusing. IE what ie what does `f f x` do? In shell I know for sure. In the example f f x, it might be easy to parse. But in f x y z, any of x y z might be functions.

Many counter examples to this, xargs for one.

xargs is not a counter example. It is not a shell builtin, it is a program that takes a bunch of string arguments like every other program a shell would call.

xargs -0 -n1 bash -c 'mv $1 ${1//.js/.ts}' --

Everything to the right of xargs is a string argument passed to xargs.

Re: Ante: A low-level functional language

#70

Post by dgb23 » Fri, Jun 17, 2022, 12:39 PM UTC

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.

Aside from Lisps being yet again an example of "Simpsons already did it.", there are also other examples and projects that go roughly into this direction. Like Roc[0]. Tim Sweeney[1] seems to be working on integrating functional programming into games development, which is highly competitive and very performance sensitive. John Carmack also has been advocating for using functional programming techniques in game development (partially).

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)