For those who like Clojure's LISP syntax, there is also Joker, which is similarly written in Go.
Ale – A Lisp Environment Written in Go
21–30 of 44 posts
Re: Ale – A Lisp Environment Written in Go
#22Earlier quoted context omitted.
In a lisp-1, you name your list variables lst. In a lisp-2, they are called list.
Not sure if that's a good example. My lists of foos are usually named "foos", not "list" or "lst".
I come from a scheme tradition where higher order functions are used for many things. I often use the name lst for generic lists.
I am not so sure I think it matters. In the place where it matters the most (macros) scheme has macro hygiene. That discussion is not worth having here though, because it is really just a matter of taste.
I like both ways, but prefer the scheme way where you have to explicitly break hygiene instead of explicitly try to not shadow bindings . I understand that defmacro can be nice sometimes, and for that most schemes provide it (heck, even racket has it!).
Re: Ale – A Lisp Environment Written in Go
#23Earlier quoted context omitted.
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.
Lisp-1 is pretty much the model JavaScript uses. Lisp-2 is what Emacs uses and it requires some extra features/functions to do functional programming.
Re: Ale – A Lisp Environment Written in Go
#24Earlier quoted context omitted.
I'm new to LISPs. What's the difference between LISP-1 and LISP-2?
Common Lisp is a Lisp-2; Scheme is a Lisp-1. Lisp-2 is handier [to me] in many ways but it requires an inelegant syntax when you want to evaluate a function that returns a function and then call said returned function. Assume you have a function foo that when called returns the function '+. To then call that function with args 1 & 2 you'd say in a Lisp-1: ((foo) 1 2) ; 3 while in a Lisp-2 you'd have to say: (funcall…
In what ways is it handier? I've never heard of benefits of Lisp-2. Whereas Lisp-1 is more intuitive to those who know JavaScript/Lua/etc.
Re: Ale – A Lisp Environment Written in Go
#25The 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,…
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.
Re: Ale – A Lisp Environment Written in Go
#26I 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.
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.
Re: Ale – A Lisp Environment Written in Go
#27The 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,…
> The only thing macros can do that functions can't is hide control flow.
Syntactic flexibility is valuable, sometimes. Not often, I'll give you.
Re: Ale – A Lisp Environment Written in Go
#28The 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,…
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! Pat…
Unpopular opinion that doesn't even disagree with you. LOOP is superior to rackets for loops.
The minimizing and maximizing constructs are surprisingly readable.
Re: Ale – A Lisp Environment Written in Go
#29Earlier quoted context omitted.
Common Lisp is a Lisp-2; Scheme is a Lisp-1. Lisp-2 is handier [to me] in many ways but it requires an inelegant syntax when you want to evaluate a function that returns a function and then call said returned function. Assume you have a function foo that when called returns the function '+. To then call that function with args 1 & 2 you'd say in a Lisp-1: ((foo) 1 2) ; 3 while in a Lisp-2 you'd have to say: (funcall…
In what ways is it handier? I've never heard of benefits of Lisp-2. Whereas Lisp-1 is more intuitive to those who know JavaScript/Lua/etc.
Lisp-2 is intuitive to those who know shell.
foo()
{
echo hi
}
$ foo=1
$ foo
hi
$ echo $foo
1
$ var=$(foo)
$ echo $var
hi
$ var=$foo
echo $var
1
This provides a hygiene benefit similar to what we have in a Lisp-2. Specifically, suppose we do this:
$ ls=abc
Re: Ale – A Lisp Environment Written in Go
#30Earlier quoted context omitted.
In what ways is it handier? I've never heard of benefits of Lisp-2. Whereas Lisp-1 is more intuitive to those who know JavaScript/Lua/etc.
Lisp-2 is intuitive to those who know shell. foo() { echo hi } $ foo=1 $ foo hi $ echo $foo 1 $ var=$(foo) $ echo $var hi $ var=$foo echo $var 1 Separate space for variables and functions/commands. Hardly anyone bats an eyelash about this. This provides a hygiene benefit similar to what we have in a Lisp-2. Specifically, suppose we do this: $ ls=abc by doing that, we have not shadowed the ls command. We can name shel…
Exactly this. When I write Scheme code, it trips me up when I have to re-spell variable names to avoid clashes. Experienced Scheme programmers don't find this difficult; they think it's weird to have to use funcall. It's just a function of what you're more used to.