5 ms·

I get that, but I can't help but view them as visual noise.

by m0zg 7y ago

capableweb 7y ago
On the other hand, other languages use bunch of different characters and they all have different meanings and have to be in different places depending on lots of things. In Lisp, you just have () and they are always in the same place, meaning the same thing.
- breck 7y ago
  This is a good point, in that Lisp is better than the other languages. But why not go all the way, and drop the parens? If the goal of Bel is to be a "good language", with shorter programs, why oh why not also strive for shorter syntax? I love Lisp and have gotten more good constructive feedback from the Lisp community than anywhere else (with the Haskell community being a close second), but I don't understand why there's only been a dozen or so serious attempts to do Lisp without parens (I-Expressions being the best so far, better than the subsequent Wisp, etc). There should be 1,000x attempts. This should be the top priority of most Lisp researchers. I of course think my Tree Notation is the solution, but I could easily be wrong, and there could be a better way, but the () need to go!
  - capableweb 7y ago
    "why not go all the way, and drop the parens?" because no one found something that is simpler and shorter than just using parens. I-expressions are made up of invisible characters and my feeling is that not a lot of people who write lisp likes any sort of invisibility in their software. For me, using parens is not a deal-breaker, as it's a relatively simple to use for dividing up things. Beats using invisible characters or many different characters.
  - sooheon 7y ago
    At bottom something is necessary to delimit expressions. Going from () to semantic indentation is trading one delimiter for another, isn't it? Not exactly dropping the parens for free.
    - breck 7y ago
      Break or fixed width delimiters are different than enclosing delimiters. There's no longer any parens matching. And not 2 things to keep track of (notice how Bel is both using parens but also following a whitespace convention for readability--that is then stripped and ignored by the compiler). And also, your program is never in a syntactic error state--such things no longer exist. Semantic errors are still there, of course, but a whole class of errors goes puff.
  - lispm 7y ago
    > But why not go all the way, and drop the parens? Because Lisp is not about 'parens', but that code is written in a serialized form of Lisp data and that it can be both written as externalized textual data and as actual data (by calling functions which work directly over this data). > dozen or so serious attempts to do Lisp without parens MLISP, Lisp2, Logo, ML, Clisp, Dylan, RLISP, SKILL, CGOL, Julia, ... > This should be the top priority of most Lisp researchers. There are many more interesting areas for progress. A Lisp without s-expression-based syntax is not a main Lisp and will form a new language group - which has happened multiple times in the past - but it won't replace the main core Lisp languages.
    - breck 7y ago
      Good references, thanks. I took a fresh look at CGOL and was again impressed. > Because Lisp is not about 'parens', Exactly, so why keep them around? When you ditch the parens, things become easier. You no longer start your programs with a syntax error. You no longer even have syntax errors. Program concatenation is easier. Dictation of programs is easier: you speak "add 2 3" instead of "open parens add 2 3 close parens". Program synthesis is easier.... > A Lisp without s-expression-based syntax is not a main Lisp and will form a new language group All I'm saying is put S-Expressions into normalized form (indented cleanly), drop the parens, and voila, everything can still work, and you've reduced things to their simplest form.
      - lispm 7y ago
        > Exactly, so why keep them around? Because Lisp source code is written in a data-structure using nested lists and nested lists are written as s-expressions with parentheses. The same Lisp code can be executed by an s-expression-based interpreter. > When you ditch the parens Again, the parens are not what Lisp is about, it is the nested lists as source code: internally and externally. It just happens that the lists are written with ( and ). What you propose is essentially not just getting rid of 'parens', but dropping the source code idea based on explicit list representation. > , things become easier. Code generation, manipulation and transformation becomes harder. > You no longer even have syntax errors. How so? > Program concatenation is easier. How so? Lisp actually makes many forms of source code transformations easy. > All I'm saying is put S-Expressions into normalized form (indented cleanly), drop the parens, and voila, everything can still work, and you've reduced things to their simplest form. But then we no longer have the 'Lisp code is explicitly written in a list-based data structure' idea, which is very powerful and still relatively simple. Language with syntax based on textual representations already exist many and there is a place for a programming language which works slightly differently. It's possible to drop the explicit s-expression syntax, as has been demonstrated many times over history, but then the has a different look and feel. It becomes something different then and loses basic Lisp features or makes them considerable harder to use. One can say 'why keep the wheels around'? We can do that, but either the car won't drive very well or one would transform it into something else: a boat, a plane, a sled, .. It would lose its 'car nature'.
firepoet 7y ago
With familiarity that goes away. :-)
breck 7y ago
Ignore the downvoters, you are 100% correct. They are visual noise. Completely superfluous. The biggest Lisp of all will have no parens.

I get that, but I can't help but view them as visual noise.

by m0zg 7y ago

I get that, but I can't help but view them as visual noise.

On the other hand, other languages use bunch of different characters and they all have different meanings and have to be in different places depending on lots of things. In Lisp, you just have () and they are always in the same place, meaning the same thing.

breck 7y ago
This is a good point, in that Lisp is better than the other languages. But why not go all the way, and drop the parens? If the goal of Bel is to be a "good language", with shorter programs, why oh why not also strive for shorter syntax? I love Lisp and have gotten more good constructive feedback from the Lisp community than anywhere else (with the Haskell community being a close second), but I don't understand why there's only been a dozen or so serious attempts to do Lisp without parens (I-Expressions being the best so far, better than the subsequent Wisp, etc). There should be 1,000x attempts. This should be the top priority of most Lisp researchers. I of course think my Tree Notation is the solution, but I could easily be wrong, and there could be a better way, but the () need to go!
- capableweb 7y ago
  "why not go all the way, and drop the parens?" because no one found something that is simpler and shorter than just using parens. I-expressions are made up of invisible characters and my feeling is that not a lot of people who write lisp likes any sort of invisibility in their software. For me, using parens is not a deal-breaker, as it's a relatively simple to use for dividing up things. Beats using invisible characters or many different characters.
- sooheon 7y ago
  At bottom something is necessary to delimit expressions. Going from () to semantic indentation is trading one delimiter for another, isn't it? Not exactly dropping the parens for free.
  - breck 7y ago
    Break or fixed width delimiters are different than enclosing delimiters. There's no longer any parens matching. And not 2 things to keep track of (notice how Bel is both using parens but also following a whitespace convention for readability--that is then stripped and ignored by the compiler). And also, your program is never in a syntactic error state--such things no longer exist. Semantic errors are still there, of course, but a whole class of errors goes puff.
- lispm 7y ago
  > But why not go all the way, and drop the parens? Because Lisp is not about 'parens', but that code is written in a serialized form of Lisp data and that it can be both written as externalized textual data and as actual data (by calling functions which work directly over this data). > dozen or so serious attempts to do Lisp without parens MLISP, Lisp2, Logo, ML, Clisp, Dylan, RLISP, SKILL, CGOL, Julia, ... > This should be the top priority of most Lisp researchers. There are many more interesting areas for progress. A Lisp without s-expression-based syntax is not a main Lisp and will form a new language group - which has happened multiple times in the past - but it won't replace the main core Lisp languages.
  - breck 7y ago
    Good references, thanks. I took a fresh look at CGOL and was again impressed. > Because Lisp is not about 'parens', Exactly, so why keep them around? When you ditch the parens, things become easier. You no longer start your programs with a syntax error. You no longer even have syntax errors. Program concatenation is easier. Dictation of programs is easier: you speak "add 2 3" instead of "open parens add 2 3 close parens". Program synthesis is easier.... > A Lisp without s-expression-based syntax is not a main Lisp and will form a new language group All I'm saying is put S-Expressions into normalized form (indented cleanly), drop the parens, and voila, everything can still work, and you've reduced things to their simplest form.
    - lispm 7y ago
      > Exactly, so why keep them around? Because Lisp source code is written in a data-structure using nested lists and nested lists are written as s-expressions with parentheses. The same Lisp code can be executed by an s-expression-based interpreter. > When you ditch the parens Again, the parens are not what Lisp is about, it is the nested lists as source code: internally and externally. It just happens that the lists are written with ( and ). What you propose is essentially not just getting rid of 'parens', but dropping the source code idea based on explicit list representation. > , things become easier. Code generation, manipulation and transformation becomes harder. > You no longer even have syntax errors. How so? > Program concatenation is easier. How so? Lisp actually makes many forms of source code transformations easy. > All I'm saying is put S-Expressions into normalized form (indented cleanly), drop the parens, and voila, everything can still work, and you've reduced things to their simplest form. But then we no longer have the 'Lisp code is explicitly written in a list-based data structure' idea, which is very powerful and still relatively simple. Language with syntax based on textual representations already exist many and there is a place for a programming language which works slightly differently. It's possible to drop the explicit s-expression syntax, as has been demonstrated many times over history, but then the has a different look and feel. It becomes something different then and loses basic Lisp features or makes them considerable harder to use. One can say 'why keep the wheels around'? We can do that, but either the car won't drive very well or one would transform it into something else: a boat, a plane, a sled, .. It would lose its 'car nature'.

firepoet 7y ago

With familiarity that goes away. :-)

breck 7y ago

Ignore the downvoters, you are 100% correct. They are visual noise. Completely superfluous. The biggest Lisp of all will have no parens.