3 ms·

Or syntax actually matters. Which ironically is where the lisp people went wrong.

by lmm 2y ago

kazinator 2y ago
Syntax does matter. That's one area where the Lisp people went right. Lisp syntax is nice to work with irrespective of everything else, which was quite a discovery, which came as a surprise. The Lisp project itself didn't expect it; Lisp was supposed to be programmed in M-expressions. Furthermore, there was a second generation project, Lisp 2, that provided an Algol-like syntax over top of the Lisp internals. Because syntax matters, M-expressions and Algol syntax for Lisp fell by the wayside. Other subsequent attempts also faced very limited success.
- aredox 2y ago
  What would those M-expressions have looked like?
  - Y_Y 2y ago
    Mathematica. Mathematica is the M-expression language. It's actually very expressive and has nice tricks like multimedia literals and the ability to do some fancy almost-tex rendering in expression, but deep down it's all sexps and lists and symbolic manipulation thereof (and an FFI). (I think they tried to rebrand the language a couple of years back as "Wolfram", lol.)
    - lispm 2y ago
      Technically what Mathematica calls "lists" are one-dimensional arrays (aka vectors in Lisp), but not Lisp-like singly-linked lists. This is an example of an M-Expression in the original definition of Lisp: [eq[third[(A B C (D . E))];C]→cons[D;cdr[((A 1 2 3) B C)]; T→car[x]] which is roughly equivalent to the Lisp S-Expression (COND ((EQ (THIRD (QUOTE (A B C (D . E)))) (QUOTE C)) (CONS (QUOTE D) (CDR (QUOTE ((A 1 2 3) B C))))) (T (CAR X))) Which evaluates to (D B C)
      - Y_Y 2y ago
        Is the underlying implementation a necessary condition? Mathematica is a heap of shit, but it was deliberately based on lisp by sensible people and has astonishingly similar semantics. Afaik the language spec doesn't define anything incompatible with OG lisp and you can treat it like one without inconsistencies.
        lispm 2y ago
        It was more influenced by computer algebra systems written in Lisp, like Macsyma (-> Maxima), REDUCE, and others. > astonishingly similar semantics The "Wolfram language" has at its core a rewrite rule systems. Expressions are being rewritten by applying transformations to it. Lisp does not use anything like that. Lisp has an evaluator mechanism, based on fixed evaluation rules (+ macro transformations, which are again Lisp functions). As a result, code in the Wolfram language is difficult to (fully) compile. Good and extensive Lisp compilers exist since the early 60s. Current examples of complete compilers are SBCL for Lisp and Chez Scheme for Scheme. The Wolfram language also has no formal spec (compare to something like Scheme) and the language itself is not open sourced, including its main implementation. It's basically defined by its main implementation, while its proprietary language documentation looks like written in a such way to prevent implementations of the language.
        Y_Y 2y ago
        I guess I consider term-rewriting to be just a fancy lambda calculus. See, e.g. https://cstheory.stackexchange.com/questions/36090/how-is-lambda-calculus-a-specific-type-of-term-writing-system https://cstheory.stackexchange.com/questions/36090/how-is-la... I can't argue with any of your points, but I'd like to mention that Mathematica's internal compiler is pretty capable and if you do something like Plot[f, xs] it will automatically try to compile f before evaluating it at all the points.
        lispm 2y ago
        Lisp is not an implementation of "lambda calculus". > internal compiler is pretty capable Depends, when reading the documentation, one gets the impression that their compiler is very limited.
  - trealira 2y ago
    There are some examples taken from the Lisp 1.5 manual on Wikipedia: https://en.wikipedia.org/wiki/M-expression https://en.wikipedia.org/wiki/M-expression
  - cmrdporcupine 2y ago
    I think Dylan is maybe the closest the PL world has come to a relatively "mainstream" Common-Lisp-Adjacent language, but with a "normal" infix syntax.
- lmm 2y ago
  > Lisp syntax is nice to work with irrespective of everything else Disagree. Some people find it tolerable for the sake of lisp advantages (mainly macros). Very few find it outright preferable. The existence and popularity of reader macros is proof of this. > Because syntax matters, M-expressions and Algol syntax for Lisp fell by the wayside. Because they were bad syntax. And because syntax isn't the only thing that matters. A good syntax that didn't compromise the ease of writing macros would win out, if such a thing were possible.
  - pjmlp 2y ago
    From print (x); to (print x) From if (cond) { do_a(); } else { do_b(); } to (if cond do_a do_b) Really it is more a mindset than anything else.
  - kazinator 2y ago
    In the computing industry as such, few people find it preferable, because few people know and work with Lisp. In Lisp circles, I would say that the majority of the people find Lisp syntax preferable. Opinions similar "I'm only tolerating this to get to the macros" are hardly ever heard. The opinion, "I wish this non-Lisp language I have to work with were written in S-expressions" is often heard. Lisp syntax is uniform, consistent, easily formatted in different levels of line breaking, easily manipulated by text editors. There is no ambiguity due to associativity of precedence. You never wonder which expressions belong to which operator. I got hooked on Lisp before Lisp macros became a meme; I liked working with it before learning about macros. Lisp-syntax front ends for non-Lisp languages prove that there are communities of people who prefer that syntax. E.g. Hy or Hissp for Python, Fennel for Lua and such. Lisps have a considerable amount of notation in addition to the parentheses. Not everything in the written source code is denoted by an open parenthesis and symbol. That's a strawman view of Lisp syntax. However, the notations are token notations that play along with the rest of the syntax. Not all languages in the Lisp family or Lisp-likes have reader macros. Scheme doesn't have them, except the descendant Racket dialect which has the #lang thing. The Lisp-like functional language Clojure doesn't have reader macros, yet is quite popular. In TXR Lisp, I intentionally didn't provide reader macros. Reader macros are not heavily used in Common Lisp. Not all uses of reader macros in Common Lisp programs and libraries are for the purpose of deviating from the concepts of Lisp syntax. Reader macros have disadvantages: - the Lisp printer doesn't know about the syntax and doesn't use it. - external code tooling doesn't know about reader macros: everything from syntax coloring to identifier cross-referencing and whatnot. That makes reader macros disruptive. - reader macros can clash. (In the Common Lisp FOSS landscape, there is now a "named readtables" module for disciplined use of multiple custom syntaxes).

Or syntax actually matters. Which ironically is where the lisp people went wrong.

by lmm 2y ago

Or syntax actually matters. Which ironically is where the lisp people went wrong.

Syntax does matter. That's one area where the Lisp people went right. Lisp syntax is nice to work with irrespective of everything else, which was quite a discovery, which came as a surprise. The Lisp project itself didn't expect it; Lisp was supposed to be programmed in M-expressions. Furthermore, there was a second generation project, Lisp 2, that provided an Algol-like syntax over top of the Lisp internals. Because syntax matters, M-expressions and Algol syntax for Lisp fell by the wayside. Other subsequent attempts also faced very limited success.

aredox 2y ago
What would those M-expressions have looked like?
- Y_Y 2y ago
  Mathematica. Mathematica is the M-expression language. It's actually very expressive and has nice tricks like multimedia literals and the ability to do some fancy almost-tex rendering in expression, but deep down it's all sexps and lists and symbolic manipulation thereof (and an FFI). (I think they tried to rebrand the language a couple of years back as "Wolfram", lol.)
  - lispm 2y ago
    Technically what Mathematica calls "lists" are one-dimensional arrays (aka vectors in Lisp), but not Lisp-like singly-linked lists. This is an example of an M-Expression in the original definition of Lisp: [eq[third[(A B C (D . E))];C]→cons[D;cdr[((A 1 2 3) B C)]; T→car[x]] which is roughly equivalent to the Lisp S-Expression (COND ((EQ (THIRD (QUOTE (A B C (D . E)))) (QUOTE C)) (CONS (QUOTE D) (CDR (QUOTE ((A 1 2 3) B C))))) (T (CAR X))) Which evaluates to (D B C)
    - Y_Y 2y ago
      Is the underlying implementation a necessary condition? Mathematica is a heap of shit, but it was deliberately based on lisp by sensible people and has astonishingly similar semantics. Afaik the language spec doesn't define anything incompatible with OG lisp and you can treat it like one without inconsistencies.
      - lispm 2y ago
        It was more influenced by computer algebra systems written in Lisp, like Macsyma (-> Maxima), REDUCE, and others. > astonishingly similar semantics The "Wolfram language" has at its core a rewrite rule systems. Expressions are being rewritten by applying transformations to it. Lisp does not use anything like that. Lisp has an evaluator mechanism, based on fixed evaluation rules (+ macro transformations, which are again Lisp functions). As a result, code in the Wolfram language is difficult to (fully) compile. Good and extensive Lisp compilers exist since the early 60s. Current examples of complete compilers are SBCL for Lisp and Chez Scheme for Scheme. The Wolfram language also has no formal spec (compare to something like Scheme) and the language itself is not open sourced, including its main implementation. It's basically defined by its main implementation, while its proprietary language documentation looks like written in a such way to prevent implementations of the language.
        Y_Y 2y ago
        I guess I consider term-rewriting to be just a fancy lambda calculus. See, e.g. https://cstheory.stackexchange.com/questions/36090/how-is-lambda-calculus-a-specific-type-of-term-writing-system https://cstheory.stackexchange.com/questions/36090/how-is-la... I can't argue with any of your points, but I'd like to mention that Mathematica's internal compiler is pretty capable and if you do something like Plot[f, xs] it will automatically try to compile f before evaluating it at all the points.
        lispm 2y ago
        Lisp is not an implementation of "lambda calculus". > internal compiler is pretty capable Depends, when reading the documentation, one gets the impression that their compiler is very limited.
- trealira 2y ago
  There are some examples taken from the Lisp 1.5 manual on Wikipedia: https://en.wikipedia.org/wiki/M-expression https://en.wikipedia.org/wiki/M-expression
- cmrdporcupine 2y ago
  I think Dylan is maybe the closest the PL world has come to a relatively "mainstream" Common-Lisp-Adjacent language, but with a "normal" infix syntax.
lmm 2y ago
> Lisp syntax is nice to work with irrespective of everything else Disagree. Some people find it tolerable for the sake of lisp advantages (mainly macros). Very few find it outright preferable. The existence and popularity of reader macros is proof of this. > Because syntax matters, M-expressions and Algol syntax for Lisp fell by the wayside. Because they were bad syntax. And because syntax isn't the only thing that matters. A good syntax that didn't compromise the ease of writing macros would win out, if such a thing were possible.
- pjmlp 2y ago
  From print (x); to (print x) From if (cond) { do_a(); } else { do_b(); } to (if cond do_a do_b) Really it is more a mindset than anything else.
- kazinator 2y ago
  In the computing industry as such, few people find it preferable, because few people know and work with Lisp. In Lisp circles, I would say that the majority of the people find Lisp syntax preferable. Opinions similar "I'm only tolerating this to get to the macros" are hardly ever heard. The opinion, "I wish this non-Lisp language I have to work with were written in S-expressions" is often heard. Lisp syntax is uniform, consistent, easily formatted in different levels of line breaking, easily manipulated by text editors. There is no ambiguity due to associativity of precedence. You never wonder which expressions belong to which operator. I got hooked on Lisp before Lisp macros became a meme; I liked working with it before learning about macros. Lisp-syntax front ends for non-Lisp languages prove that there are communities of people who prefer that syntax. E.g. Hy or Hissp for Python, Fennel for Lua and such. Lisps have a considerable amount of notation in addition to the parentheses. Not everything in the written source code is denoted by an open parenthesis and symbol. That's a strawman view of Lisp syntax. However, the notations are token notations that play along with the rest of the syntax. Not all languages in the Lisp family or Lisp-likes have reader macros. Scheme doesn't have them, except the descendant Racket dialect which has the #lang thing. The Lisp-like functional language Clojure doesn't have reader macros, yet is quite popular. In TXR Lisp, I intentionally didn't provide reader macros. Reader macros are not heavily used in Common Lisp. Not all uses of reader macros in Common Lisp programs and libraries are for the purpose of deviating from the concepts of Lisp syntax. Reader macros have disadvantages: - the Lisp printer doesn't know about the syntax and doesn't use it. - external code tooling doesn't know about reader macros: everything from syntax coloring to identifier cross-referencing and whatnot. That makes reader macros disruptive. - reader macros can clash. (In the Common Lisp FOSS landscape, there is now a "named readtables" module for disciplined use of multiple custom syntaxes).