Live data from Hacker News

Ante: A low-level functional language

antelang.org

111–120 of 226 posts

Re: Ante: A low-level functional language

#111

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.

In the case of map operations, Ante is using Rust style iterators over collections. In Rust, iterators are just as fast as loops.

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

Re: Ante: A low-level functional language

#112
post #103

Earlier quoted context omitted.

What creates that distinction ? in the lisp / fp world you quickly stop considering functions as separate entities.

The function represents the operation or computation you want to perform. The arguments represent inputs or parameters for that operation or computation. Of course, theoretically you could also view the function as a parameter of the computation and/or the arguments as specifying an operation (in particular if those are also functions), but for most concrete function invocation that's not generally the mental model.…

But even in high school topics start to talk about functional equations (calculus, e/ln). I'm not sure the vs doesn't come from the mainstream imperative paradigms and only that.

Re: Ante: A low-level functional language

#113
post #106

Looks great! A few questions (hopefully the author still reads it): * Any plan for support of arrow/monad comprehensions? * Semi-related: When it comes to generators it might be worth to consider making them clonable (see https://github.com/pelotom/burrido )

(1): No support, some monad or early-error-return sugar used to be considered but effects cover most of the usecases of monads and are easier to use so I plan on emphasizing them. As for arrows, I have to say here that I've actually never used them in haskell so I don't know how useful they'd be.

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

Re: Ante: A low-level functional language

#114
post #61
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?

No functional languages do that.

OCaml parses a b c as ((a b) c). In case the compiler can determine that a is a function taking 2 arguments, it will optimise the code, so that it’s effectively a(b, c). But in general, that’s not possible, especially in the case where the compiler determines that a is a function with a single argument (in which case, it’s return value must be another function, which is in turn called with c) or when a is a first-class function (e.g. passed as an argument)

Re: Ante: A low-level functional language

#115

Earlier quoted context omitted.

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.

I had the same feeling when I first started using a lisp (which was Scheme to work through SICP and the Ableman&Sussman MIT course). I was utterly entranced by the simplicity and uniformity. It was absolutely a factor in the way syntax works in my personal language (which I use for almost everything in my day to day). I really do agree that learning a lisp can truly expand the way in which a dev views and thinks about code.

Re: Ante: A low-level functional language

#116
post #103

Earlier quoted context omitted.

The function represents the operation or computation you want to perform. The arguments represent inputs or parameters for that operation or computation. Of course, theoretically you could also view the function as a parameter of the computation and/or the arguments as specifying an operation (in particular if those are also functions), but for most concrete function invocation that's not generally the mental model.…

But even in high school topics start to talk about functional equations (calculus, e/ln). I'm not sure the vs doesn't come from the mainstream imperative paradigms and only that.

The distinction isn't between functions and values in general, it's between the function being called and the arguments passed to the function being called. The difference isn't in the things themselves, it's in the role that they play in the specific expression we're reading.

Re: Ante: A low-level functional language

#117
post #58

Hello, author here! As the website says, the compiler itself is still in a very early state where basic things like functions, types, traits, inference, monomorphisation, and codegen are implemented. The fun stuff of algebraic effects, lifetime inference, and refinement types are not however. Though I can elaborate on implementation strategies of these for anyone curious. For example, algebraic effects in existing la…

Looks like a great start! Your attention to programmer ergonomics is admirable. Added to my weekend hacking reading list.

Re: Ante: A low-level functional language

#118

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.

I disagree, the reason almost all ‘functional’ programming can not be said to be referentially transparent is because of the level of abstract the designers take as a base. The work Greg Morrisette did (which include Robert Harper for some branches) on Typed and Dependently-Typed Assembly could be used as the basis for a ‘C-level’ programming language that is ‘functional’.

At a slightly higher level, if memory is explicit, and that would include input and output buffers and the like, then it is possible to make functions exist inside a ‘memory monad’, similar to Haskell’s state monad. Then any and all operations involving the memory used can be made referentially transparent.

Now, the real question is would anyone want to program in such a style? I know I wouldn’t mind, it’s while I broke down and designed a personal programming language for my daily use. But it’s a matter of taste and tolerance.

Re: Ante: A low-level functional language

#119
post #58

Hello, author here! As the website says, the compiler itself is still in a very early state where basic things like functions, types, traits, inference, monomorphisation, and codegen are implemented. The fun stuff of algebraic effects, lifetime inference, and refinement types are not however. Though I can elaborate on implementation strategies of these for anyone curious. For example, algebraic effects in existing la…

I'd really like to find "the low-level functional language" without "the fun stuff". Or at least it should have simple and boring subset that is usable without "the fun stuff".

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.

Re: Ante: A low-level functional language

#120

Interesting, well have to see how it develops in the future. Although, I normally dislike languages without {}, but I suppose that is just preference.

I hate having to press Shift to get braces. Let's use square brackets which require no modifier key.

Just a question: but are you considering the frequency of usage for a particular symbol in that suggestion? If {} is for opening/closing functions or code blocks/scope AND [] is for making arrays, lists, or some other data structure: do you only want them switched where, idiomatically, where there are less function definitions vs instances of the data structure? Or is it an overall objection to any shift+key operator in a basic syntax?
Post reply on HN