Live data from Hacker News

Ante: A low-level functional language

antelang.org

161–170 of 226 posts

Re: Ante: A low-level functional language

#161
post #151

Earlier quoted context omitted.

Natural language isn’t precise and a lot is inferred from context. Exact order does often not really matter. In formal languages, however, you want to be as unambiguous and exact as possible, so it makes sense to use syntax and symbols to emphasize when elements differ in kind. Incidentally, that’s also why we use syntax highlighting. One could, of course, use syntax highlighting instead of symbols to indicate the di…

We also alternate between various positions in programming languages, so it's not a matter of formal precision.

Not sure what you mean by “alternate between various positions”.

Re: Ante: A low-level functional language

#162

Earlier quoted context omitted.

Okay, but now you have to look at more things. Also, the ending paren doesn't have anything to help you see what it is on its own.

You're not supposed to look for ending parentheses in Lisp; getting the right number of them is more or less your editor's job, and they are maximally stacked together like this: )))), as much as the given nesting and indentation permit. Given some (let ..., the closing parenthesis could be the third one in some ))))) sequence; you rarely care which one. If it's not matched in that specific ))))) sequence where you e…

That doesn’t seem very user-friendly. ;) Or at least that’s always my perception when programming Lisp.

As a side note, I believe that different people fundamentally have different programming languages that objectively suit them best, due to differences in their respective psychology and way of thinking and perceiving. It’s interesting to discuss trade-offs, but in the end there is no single truth about which language is better overall — it depends on the task and on the person. There’s no “one size fits all”. What’s valuable is to understand why a certain syntax or language might work better for certain people.

Re: Ante: A low-level functional language

#163

Earlier quoted context omitted.

I don't see a LICENSE file anywhere in the repo or the website. Nobody is allowed to use Ante?

> Nobody is allowed to use Ante? :eyeroll:

https://docs.github.com/en/repositories/managing-your-reposi...

>However, without a license, the default copyright laws apply, meaning that you retain all rights to your source code and no one may reproduce, distribute, or create derivative works from your work.

Re: Ante: A low-level functional language

#164
This looks like it could become a very interesting language. Unusually for a new language, I spotted zero red flags.

I did do a quick ^f for "destructor" and "drop"...

The intro mentions memory management, and inferring lifetimes. How do I make something happen at end of lifetime?

Re: Ante: A low-level functional language

#165

Earlier quoted context omitted.

Very neat project! I noticed that Ante doesn’t have explicit region type declarations. As I recall, existing algorithms implemented for ML can sometimes infer very large regions which causes memory usage to balloon. It looks like smart pointers are part of the plan to address that possibility, but I’d love to hear more about your thoughts on memory management.

Correct, a key goal is to have no explicit region/lifetime annotations. There have been several papers on region inference after the originals by Tofte & Taplin, all attempting to refine the original analysis by inferring shorter lifetimes. First by analyzing when a region can be safely emptied and re-used, then by abandoning the stack discipline, etc. Unfortunately, none of these are viable in a real program in my o…

Hey, thanks for calling my work "not viable!" (Co-author of "Better Static Memory Management" here)

Seriously, this looks promising and I'm very interested to see where it goes.

Re: Ante: A low-level functional language

#166

Earlier quoted context omitted.

> fun stuff of algebraic effects, lifetime inference, and refinement types > I'd really like to find "the low-level functional language" without "the fun stuff" But current stable Ocaml has neither of the "fun stuff" mentioned and compiles to native code. So isn't that exactly what you want? It doesn't even need lifetime analysis because automatic garbage collection be praised. And algebraic effects are awesome. Sure…

Ocaml doesn't compile to C. Sometimes having translated C source is major gain. I'm not Ocaml implementation expert, but I suppose Ocaml exception handling and garbage collector could be tricky to aware about when one extend or embed Ocaml. To be honestly, my fellow did Ocaml embedding once. He made able to load natively-compiled plugins written in Ocaml into C based software. And it worked. I didn't dig into details…

`ocaml-ctypes` currently supports "reverse-bindings" (making OCaml functions available from C) out-of-the-box and mostly takes care of the intersection you are talking about, so this already works quite well.

The only gain from emiting C code is portability to weird architecture that would be covered by C compilers but not the OCaml one; which is arguably a pretty niche use-case.

Re: Ante: A low-level functional language

#167
post #49

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.

> A lisp paren can do both jobs: expression and scopes. Using different symbols for different purposes makes sense, it helps humans to parse correctly faster.

It does, but there are still many different purposes. In JS:

( can mean: function call, part of an expression to be evaluated first, regex capture group

{ can mean: scope [of ... loop, if, lambda, function etc.], object definition, string interpolation code i.e. ${..}, class definition

There are probably other things I am not thinking of.

The one that trips me in JS is code like x.map(v => {...v, v2}) breaks because the compiler sees the { as the beginning of a scope, not the object definition I intended.

The working solution is x.map(v => ({...v, v2}))

But x.map(v => v+1) is allowed.

I don't think the compiler could figure out what you meant because an object definition might be a lambda function body. For example { myvar } can be both an object definition, and a function that returns myvar.

Re: Ante: A low-level functional language

#168

Earlier quoted context omitted.

Correct, a key goal is to have no explicit region/lifetime annotations. There have been several papers on region inference after the originals by Tofte & Taplin, all attempting to refine the original analysis by inferring shorter lifetimes. First by analyzing when a region can be safely emptied and re-used, then by abandoning the stack discipline, etc. Unfortunately, none of these are viable in a real program in my o…

Hey, thanks for calling my work "not viable!" (Co-author of "Better Static Memory Management" here) Seriously, this looks promising and I'm very interested to see where it goes.

I’m curious what the rationale is for not making regions explicit in the source code. It seems like a downside of region inference for a systems language is the unpredictability of the inferred regions.

Re: Ante: A low-level functional language

#169

Earlier quoted context omitted.

> Nobody is allowed to use Ante? :eyeroll:

https://docs.github.com/en/repositories/managing-your-reposi... >However, without a license, the default copyright laws apply, meaning that you retain all rights to your source code and no one may reproduce, distribute, or create derivative works from your work.

What do you think is more likely, that the author forgot to add a LICENSE file or that he actually doesn't intend for ANYONE to use the language he created? Give me a break
Post reply on HN