5 ms·

Aren't s-expressions all one really needs?

by lsh 8y ago

krapp 8y ago
No. Any Lisp you can name has more to it than just s-expressions.
- cellularmitosis 8y ago
  His point still stands. The ruby parser has 10x the number of lines of code as the clojure parser. https://github.com/ruby/ruby/blob/trunk/parse.y https://github.com/ruby/ruby/blob/trunk/parse.y https://github.com/clojure/tools.reader/blob/master/src/main/clojure/clojure/tools/reader.clj https://github.com/clojure/tools.reader/blob/master/src/main...
  - lispm 8y ago
    Because one parses a data format and the other one an actual programming language...
    - cellularmitosis 8y ago
      Sorry, I linked to the wrong edn reader https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/EdnReader.java https://github.com/clojure/clojure/blob/master/src/jvm/cloju...
      - lispm 8y ago
        That's still only an s-expression reader, not a programming language parser.
        cellularmitosis 8y ago
        Can you help me understand the distinction you are making? My understanding is that this is the reader used by the repl, and at least for clojure, an edn parser is the same thing as a programming language parser, because clojure programs are written in edn.
        victorNicollet 8y ago
        In most programming languages, a fact like "Foreach loops have a variable binding, a collection to iterate through, and a body" is guaranteed by the parser, and the rest of the language implementation can assume that the foreach loops are well-formed and concentrate on lexical and type checks. An S-Expression parser will accept (loop for in do), and the rest of the language implementation has to deal with detecting that there is no variable, no collection and no action.
        lispm 8y ago
        They are written on top, but not in. It's like claiming Ruby programs are written in characters. S-expressions know nothing and represent nothing about concepts like functions, variables, argument lists, operators, bindings, type declarations, function defintions, variable defintions, class definitions, ... Even syntactic (3 4 +) is READ successfully, but it is not a valid Clojure form. Basically a READER is on the level of a TOKENIZER, but not a parser.
- appleflaxen 8y ago
  can you elaborate? i'm not a lisper, so I don't understand what else would be present. I am guessing you mean things like switch statements?
  - lsh 8y ago
    I thought maybe he meant Lisps whose compiler isn't another Lisp, or maybe macros at a stretch ..
    - disconcision 8y ago
      Virtually every lisp uses some non s-expression syntax which must be dealt with at the reader level. For example, using ' for quotation.
      - lispm 8y ago
        (3 4 +) (2 + 3) (- 3 4) All are valid s-expressions. Only one is a valid Lisp expression.
        kazinator 8y ago
        Or, in ANSI CL terms, only one is a valid form (S-expression suitable for or subject to evaluation).
        lispm 8y ago
        A form is already 'read' - it's an object. When we parse an expression, we usually parse a textual representation into an object. If the object is meant / subject to evaluation -> then we call this a form.
      - kazinator 8y ago
        '(a b c) is considered an S-expression in Lisp dialects which support the 'X <-> (quote X) shorthand. It's just a shorthand, and it is read-print consistent, like other such shorthands. If '(a b c) isn't a S-exp, then we have backed into uncomfortable corners in which #(a b c) isn't an S-exp. Every character in a S-expression must be "dealt with at the reader level" (and produced at the printer level). The term "S-expression" was originally in contrast with "M-expression", but that's a historic usage.
cellularmitosis 8y ago
After realizing how easy it is to parse sexps, and how complex some language syntax rules have become [1], i’ve wondered why we tolerate such complexity. I’ve realized it’s because we are still stuck in a text-file-oriented way of writing programs. We are hand-editing the serialization format of our programs. All of these languages with complex syntax is an attempt to optimize around that use-case. If we had better tools which allowed us to leave behind text-file-oriented programming, there would be no need for all of this complex syntax. There would be a few other benefits as well. No one cares whether photoshop .psd files use tabs or spaces, or whether the curly brace should go at end-of-line or next-line, etc. [1] https://github.com/ruby/ruby/blob/trunk/parse.y https://github.com/ruby/ruby/blob/trunk/parse.y
- munificent 8y ago
  > After realizing how easy it is to parse sexps Why should "easy for the machine" ever be a consideration for software used by humans? Surely "easy for the human" is the metric that matters. The entire point of having computers is so that can do hard things to make our lives easier. If rich syntax is easier for us to read and feasible for computers to parse, that's the right trade-off.
  - cellularmitosis 8y ago
    I think the primary drawback of languages with complex syntax is the additional barrier to entry it creates for developers to write more tools for the language. Many more people have started a Scheme interpreter than their own C++ compiler. If we had better tools, we wouldn’t necessarily be limited to just one user-facing syntax for a language. The syntax could simply be a preference in the tools. My point is that as long as we are stuck in text-file-oriented thinking, no one is even thinking about these possibilities.
    - munificent 8y ago
      > Many more people have started a Scheme interpreter than their own C++ compiler. And yet many more people are writing C++ code. Toolability definitely matters, but the empirical observation is that a relatively small number of tools for complex languages used by a large number of people seems to provide a lot of benefit. > My point is that as long as we are stuck in text-file-oriented thinking, no one is even thinking about these possibilities. Thousands of people are thinking about this. I've been reading blog posts and manifestos about the death of text-based syntax literally since the 90s. What I think most of those people overlook is that if you think programmers struggle to write text, you're really underestimating how much they would struggle to layout boxes and lines or do whatever other spatial/visual user experience you have in mind instead.
lispm 8y ago
s-expressions only give you a data format - just like XMl, JSON, ... One then maps a programming language to s-expressions. You could easily map a complex infix/mixfix language to s-expressions. This is a valid s-expression: (foo = x ^ 3 * 4 / sin x) You can imagine variants with more parenthesis, too.

Aren't s-expressions all one really needs?

by lsh 8y ago

Aren't s-expressions all one really needs?

krapp 8y ago

No. Any Lisp you can name has more to it than just s-expressions.

cellularmitosis 8y ago
His point still stands. The ruby parser has 10x the number of lines of code as the clojure parser. https://github.com/ruby/ruby/blob/trunk/parse.y https://github.com/ruby/ruby/blob/trunk/parse.y https://github.com/clojure/tools.reader/blob/master/src/main/clojure/clojure/tools/reader.clj https://github.com/clojure/tools.reader/blob/master/src/main...
- lispm 8y ago
  Because one parses a data format and the other one an actual programming language...
  - cellularmitosis 8y ago
    Sorry, I linked to the wrong edn reader https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/EdnReader.java https://github.com/clojure/clojure/blob/master/src/jvm/cloju...
    - lispm 8y ago
      That's still only an s-expression reader, not a programming language parser.
      - cellularmitosis 8y ago
        Can you help me understand the distinction you are making? My understanding is that this is the reader used by the repl, and at least for clojure, an edn parser is the same thing as a programming language parser, because clojure programs are written in edn.
        victorNicollet 8y ago
        In most programming languages, a fact like "Foreach loops have a variable binding, a collection to iterate through, and a body" is guaranteed by the parser, and the rest of the language implementation can assume that the foreach loops are well-formed and concentrate on lexical and type checks. An S-Expression parser will accept (loop for in do), and the rest of the language implementation has to deal with detecting that there is no variable, no collection and no action.
        lispm 8y ago
        They are written on top, but not in. It's like claiming Ruby programs are written in characters. S-expressions know nothing and represent nothing about concepts like functions, variables, argument lists, operators, bindings, type declarations, function defintions, variable defintions, class definitions, ... Even syntactic (3 4 +) is READ successfully, but it is not a valid Clojure form. Basically a READER is on the level of a TOKENIZER, but not a parser.
appleflaxen 8y ago
can you elaborate? i'm not a lisper, so I don't understand what else would be present. I am guessing you mean things like switch statements?
- lsh 8y ago
  I thought maybe he meant Lisps whose compiler isn't another Lisp, or maybe macros at a stretch ..
  - disconcision 8y ago
    Virtually every lisp uses some non s-expression syntax which must be dealt with at the reader level. For example, using ' for quotation.
    - lispm 8y ago
      (3 4 +) (2 + 3) (- 3 4) All are valid s-expressions. Only one is a valid Lisp expression.
      - kazinator 8y ago
        Or, in ANSI CL terms, only one is a valid form (S-expression suitable for or subject to evaluation).
        lispm 8y ago
        A form is already 'read' - it's an object. When we parse an expression, we usually parse a textual representation into an object. If the object is meant / subject to evaluation -> then we call this a form.
    - kazinator 8y ago
      '(a b c) is considered an S-expression in Lisp dialects which support the 'X <-> (quote X) shorthand. It's just a shorthand, and it is read-print consistent, like other such shorthands. If '(a b c) isn't a S-exp, then we have backed into uncomfortable corners in which #(a b c) isn't an S-exp. Every character in a S-expression must be "dealt with at the reader level" (and produced at the printer level). The term "S-expression" was originally in contrast with "M-expression", but that's a historic usage.

cellularmitosis 8y ago

After realizing how easy it is to parse sexps, and how complex some language syntax rules have become [1], i’ve wondered why we tolerate such complexity. I’ve realized it’s because we are still stuck in a text-file-oriented way of writing programs. We are hand-editing the serialization format of our programs. All of these languages with complex syntax is an attempt to optimize around that use-case. If we had better tools which allowed us to leave behind text-file-oriented programming, there would be no need for all of this complex syntax. There would be a few other benefits as well. No one cares whether photoshop .psd files use tabs or spaces, or whether the curly brace should go at end-of-line or next-line, etc. [1] https://github.com/ruby/ruby/blob/trunk/parse.y https://github.com/ruby/ruby/blob/trunk/parse.y

munificent 8y ago
> After realizing how easy it is to parse sexps Why should "easy for the machine" ever be a consideration for software used by humans? Surely "easy for the human" is the metric that matters. The entire point of having computers is so that can do hard things to make our lives easier. If rich syntax is easier for us to read and feasible for computers to parse, that's the right trade-off.
- cellularmitosis 8y ago
  I think the primary drawback of languages with complex syntax is the additional barrier to entry it creates for developers to write more tools for the language. Many more people have started a Scheme interpreter than their own C++ compiler. If we had better tools, we wouldn’t necessarily be limited to just one user-facing syntax for a language. The syntax could simply be a preference in the tools. My point is that as long as we are stuck in text-file-oriented thinking, no one is even thinking about these possibilities.
  - munificent 8y ago
    > Many more people have started a Scheme interpreter than their own C++ compiler. And yet many more people are writing C++ code. Toolability definitely matters, but the empirical observation is that a relatively small number of tools for complex languages used by a large number of people seems to provide a lot of benefit. > My point is that as long as we are stuck in text-file-oriented thinking, no one is even thinking about these possibilities. Thousands of people are thinking about this. I've been reading blog posts and manifestos about the death of text-based syntax literally since the 90s. What I think most of those people overlook is that if you think programmers struggle to write text, you're really underestimating how much they would struggle to layout boxes and lines or do whatever other spatial/visual user experience you have in mind instead.

lispm 8y ago

s-expressions only give you a data format - just like XMl, JSON, ... One then maps a programming language to s-expressions. You could easily map a complex infix/mixfix language to s-expressions. This is a valid s-expression: (foo = x ^ 3 * 4 / sin x) You can imagine variants with more parenthesis, too.