Ale – A Lisp Environment Written in Go
ale-lang.org
Ale – A Lisp Environment Written in Go
1–10 of 44 posts
Re: Ale – A Lisp Environment Written in Go
#2I believe every new LISP author should begin their presentation with how does their language compare to other LISPs (CommonLisp, Racket and Clojure in particular). Mentioning it's a LISP-1 in the beginning is nice but not really enough.
Re: Ale – A Lisp Environment Written in Go
#3The main feature Go was missing that took away most of the usefulness of writing a Lisp in it was FFI. If you can't dynamically get identifiers (constants, functions, variables) by a string at runtime, you lose most of the interesting desktop possibilities. It's probably still useful as a server-side language but Lisps seem the most useful in the GUI space.
Also it says this in the author's latest blog post:
> "Yes, there are a lot of parens, but that is a small price to pay for a language that is capable of morphing itself into nearly anything you need it to be. And the way that Lisp does that is with a macro system that puts #define to shame!"
I'm convinced this is not the real benefit of a Lisp. The only thing macros can do that functions can't is hide control flow. And 99% of the time that's a bad thing that library authors should not use. It could be used to make other language features such as concurrency, but that's a slippery slope.
The real benefit of macros in my opinion is a balanced syntax that makes things like Emacs + paredit possible, which increases your productivity like 5x-10x. It's on another level, definitely worth trying for a few months if you work with a Lisp already. But I don't see any other real value in Lisp's syntax or in macros.
Re: Ale – A Lisp Environment Written in Go
#4I think this has a lot of potential if it's able to call Go functions, like Clojure can call Java functions. The language would have a healthy ecosystem of libraries to boot.
Re: Ale – A Lisp Environment Written in Go
#5I believe every new LISP author should begin their presentation with how does their language compare to other LISPs (CommonLisp, Racket and Clojure in particular). Mentioning it's a LISP-1 in the beginning is nice but not really enough.
Make it a Lisp-2 then I’m keen.
But I don’t mean to dismiss. Lisp persists because of its elegance. It’s a thing of beauty and who doesn’t want to work with a human friendly AST?
Re: Ale – A Lisp Environment Written in Go
#6Looks great. I want a compile to Go lisp 2, though. Just putting it out there. :-) My efforts are likely to take a while...
Re: Ale – A Lisp Environment Written in Go
#7I believe every new LISP author should begin their presentation with how does their language compare to other LISPs (CommonLisp, Racket and Clojure in particular). Mentioning it's a LISP-1 in the beginning is nice but not really enough.
Make it a Lisp-2 then I’m keen. But I don’t mean to dismiss. Lisp persists because of its elegance. It’s a thing of beauty and who doesn’t want to work with a human friendly AST?
I'm new to LISPs. What's the difference between LISP-1 and LISP-2?
Re: Ale – A Lisp Environment Written in Go
#8I believe every new LISP author should begin their presentation with how does their language compare to other LISPs (CommonLisp, Racket and Clojure in particular). Mentioning it's a LISP-1 in the beginning is nice but not really enough.
I agree, though they did put some of the first-questions-that-come-to-mind on the second page, "https://www.ale-lang.org/intro/":
> What is Ale?
> Ale is a Lisp-1. In this way it is more like Scheme than like Common Lisp. Unlike many Lisps, Ale does not support both interpreted and compiled operation. Instead, when the programmer performs an (eval), Ale immediately compiles the form and invokes its virtual machine. And unlike nearly all Lisps, bindings in Ale are immutable, even in namespaces.
> Ale borrows from Clojure where syntax is concerned, but it diverges in many ways. It is designed to be hosted in a Go process. It is also designed to allow multiple hosted instances within that process, each one being completely isolated from the other.
Most new Lisp implementations are hobby/educational, and/or driven by a particular corner of implementation or language design (e.g., target the JVM or some other language backend, fit on a microcontroller, support a million threads, support STM or some unusual evaluation model, new terse syntax).
Would be nice if new Lisps that were focused only on implementation (rather than language design) used R7RS Scheme or CL as their language design. Then they'd have a better chance of uptake, compared to a new "generic Lisp".
Re: Ale – A Lisp Environment Written in Go
#9I believe every new LISP author should begin their presentation with how does their language compare to other LISPs (CommonLisp, Racket and Clojure in particular). Mentioning it's a LISP-1 in the beginning is nice but not really enough.
These languages are all looking like crafted , so that they run no existing code. If the language is 'more' like Scheme, as the author says, there is enough difference built in, so that no Scheme program runs.
Imagine being directly able to use one of the countless Scheme books/libraries/... to experiment with it. To work with something like SICP one really needs only a tiny Scheme...
Re: Ale – A Lisp Environment Written in Go
#10Earlier quoted context omitted.
Make it a Lisp-2 then I’m keen. But I don’t mean to dismiss. Lisp persists because of its elegance. It’s a thing of beauty and who doesn’t want to work with a human friendly AST?
I'm new to LISPs. What's the difference between LISP-1 and LISP-2?
I believe it has to do with namespaces for naming functions vs variables. A lisp-1 has one namespace that encompasses variables and functions. In a lisp-2 they are separate and so it is possible to have a variable with the same name as a function.