4 ms·

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.

kazinator 7y ago
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 shell variables without worrying about that sort of clash. This is so obvious, you don't see it being spelled out to anyone.
- dreamcompiler 7y ago
  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.
  - kazinator 7y ago
    It happens in C, when you have short function names. In the C internals of TXR, I have to be careful about using variable names like list or cons, because then those functions are not available. A certain list accumulating macro calls the tail function. If I accidentally introduce a variable called tail where this macro is used, oops! In typical C code, you're protected from clashes by using short variable names, and long function names.
ACow_Adonis 7y ago
If you're doing anything involving externally defined/named data and analysis, working with it interactively/exploratory, I find it infinitely better, just because you can BOTH represent data using the same name that external sources are using AND not clobber/shadow any functions, macros or code currently in scope. Its a little thing, but if I designed a language for data munging/science/analysis, it would be a lisp-2... /and yes, i'm well aware that python and julia are not...

kazinator 7y ago

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 shell variables without worrying about that sort of clash. This is so obvious, you don't see it being spelled out to anyone.

dreamcompiler 7y ago
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.
- kazinator 7y ago
  It happens in C, when you have short function names. In the C internals of TXR, I have to be careful about using variable names like list or cons, because then those functions are not available. A certain list accumulating macro calls the tail function. If I accidentally introduce a variable called tail where this macro is used, oops! In typical C code, you're protected from clashes by using short variable names, and long function names.

ACow_Adonis 7y ago

If you're doing anything involving externally defined/named data and analysis, working with it interactively/exploratory, I find it infinitely better, just because you can BOTH represent data using the same name that external sources are using AND not clobber/shadow any functions, macros or code currently in scope. Its a little thing, but if I designed a language for data munging/science/analysis, it would be a lisp-2... /and yes, i'm well aware that python and julia are not...