
Ale – A Lisp Environment Written in Go - andrenth
https://www.ale-lang.org/
======
qwerty456127
I 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.

~~~
neilv
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/"](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".

~~~
kode4food
[https://twitter.com/kode4food/status/1137335122330566657](https://twitter.com/kode4food/status/1137335122330566657)

~~~
neilv
Excellent. You might also like R5RS or R7RS, plus `syntax-case` (though
`syntax-rules` is very nice, when the problem fits it). For work that builds
upon Scheme's syntax extension mechanisms, see Racket for ideas, including its
syntax objects, very powerful `syntax-parse`, a very simple template-based
syntax transformer, and the `#lang` feature.

------
andrenth
I 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.

~~~
nemo1618
It's weird to me that there aren't more compile-to-Go languages. The ecosystem
of Go packages is great, and the runtime is undergoing continuous refinement
by a team of really smart people.

------
nanomonkey
For those who like Clojure's LISP syntax, there is also Joker, which is
similarly written in Go.

~~~
abc_lisper
And Ferret too. [https://nakkaya.com/2016/06/10/ferret-a-hard-real-time-
cloju...](https://nakkaya.com/2016/06/10/ferret-a-hard-real-time-clojure-for-
lisp-machines/)

------
nathancahill
For a similar concept in Python: [http://hylang.org/](http://hylang.org/)

------
scottlocklin
Here's another one:

[https://github.com/glycerine/zygomys](https://github.com/glycerine/zygomys)

I think he wrote it with a TSDB in mind.

------
minieggs
Looks great. I want a compile to Go lisp 2, though. Just putting it out there.
:-) My efforts are likely to take a while...

------
musicale
I'd prefer the reverse probably.

Or forget go and just write lisp in lisp, as McCarthy intended. ;-)

------
sdegutis
The 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.

~~~
bjoli
Nah man,macros are the bee's knees! Being able to add new constructs to a
language is neat. My favourite examples are match.scm - a pattern matcher that
produces zero overhead code - and racket's for loops, which are just regular
macros.

Being able to add features like that is amazing. Clojure'sarrow syntax? No
problem. Python's list comprehensions? Can be done! A library for Pattern
matching? Many to chose from!

Pattern matchers that were added to other languages as libraries are often
weird to use. Match.scm has the same syntax as cond or case.

~~~
Yxven
Lisp always sounds cool to me until someone starts talking about macros.
What's it like inheriting a lisp code base, finding out its full of homemade
macros like list comprehensions, and that they're not documented? Inheriting a
code base is always scary, but I feel like it kicks it up a notch when your
predecessors can customize the language itself. Are my fears justified?

~~~
kazinator
> _What 's it like inheriting a lisp code base, finding out its full of
> homemade macros like list comprehensions, and that they're not documented?_

If such a macro is used in more than two places, it's generally a relief that
the author did _that_ instead of doing copy and paste by hand.

The author had some coding idea, and formalized it into a little robot that
writes that idea, which has a name.

Even if that thing isn't accompanied by documentation, it can serve as a kind
of documentation to what it's doing.

Code is going to be full of homemade functions that are not documented;
whether they are functions that write code at compile time, or whether they
are run-time functions, is kind of a minor concern.

