Ante: A low-level functional language

Post by [deleted] » Sun, Jun 19, 2022, 2:49 AM UTC

lptk wrote: post #211

quickthrower2 wrote: post #27

Earlier quoted context omitted.

I have heard that if you count { and ( as parens, a Java program for example has just as many parens as. lisp one. A lisp paren can do both jobs: expression and scopes.

That's obviously nonsense. Java, one pair of parens: int x = 1; int y = x + 1; System.out.println(y); Clojure, six pairs of brackets: (let [x 1 y (+ x 1)] ((. (. System out) println) y))

Post by lptk » Sun, Jun 19, 2022, 3:21 AM UTC

jfecher wrote: post #108

deltaonefour wrote: post #95

Functional is always at odds with low level programming because of heap allocation. You can't control it because of immutability. Just a simple map operation does a heap allocation. How does Ante avoid this problem and give the user control of the heap? The mechanism should be made clear in the introduction as browsing the documentation doesn't make it clear to me.

The plan is to give users control through the Allocate effect which can be handled in any way desired as long as it returns some memory. It is similar, but easier to use since it is an effect, to zig's approach of "pass the allocator everywhere." I say easier to use since effects are automatically passed around where necessary and propagated via function signatures and can be inferred. The specific design is still in…

Post by scns » Sun, Jun 19, 2022, 8:42 AM UTC

Warwolt wrote: post #184

IncRnd wrote: post #180

Earlier quoted context omitted.

The generally accepted definition of a low level language is a language that provides little or no abstraction from a computer's instruction set architecture. In actuality, C is a lower level functional programming language than Ante, because C functions are first-class citizens. I like the lack of GC! What is the method for always incremental compilation? The benefits are obvious, but isn't it problematic to have tw…

Eh, isn't it a bit of a stretch to claim you can program functionally in C? You can mimic it, but without easy closures you can't follow _any_ functional programming patterns that are built on composing functions into new ones in expressions (e.g. binding the operation argument to a fold) C is great, and it would be cool to see something that is similarly close to the instruction set but has functions as values

Post by dan-robertson » Sun, Jun 19, 2022, 9:42 AM UTC

curryhoward wrote: post #31

HelloNurse wrote: post #26

Earlier quoted context omitted.

If fn 1 is an allowed function call syntax then fn (1) should be synonymous because 1 is expected to be the same as (1) except for a slightly different parse tree; but there might be good reasons to make fn 1 not a function call (for example, the implicit operator in a sequence of two expression without parentheses could be string concatenation rather than function application).

> the implicit operator in a sequence of two expression without parentheses could be string concatenation rather than function application You can design a language which uses `e1 e2` to represent any binary operation you like, but I'd argue that function application is more common than string concatenation, so it's more deserving of that syntax. Plus, it plays nicely with currying.

  f g = composition of f then g
  x.f = f applied to x
  x.f g h = in regular notation h(g(f(x))

Post by ncmncm » Sun, Jun 19, 2022, 11:54 AM UTC

zasdffaa wrote: post #206

ncmncm wrote: post #204

Earlier quoted context omitted.

There seems little value in "exposing" crap we would be better off not building in the first place. The more expressive your language is, the less the runtime and hardware needs to guess about.

So what are the $%^&* semantics we're supposed to build into the language to avoid the need for speculation via OOO exec and branch prediction. Because as a guy interested in languages you might have something to teach me, assuming you have any idea what you're talking about.