4 ms·

I like the idea, but the mass of `cons` in the pattern matching really turns me off. Would it be possible to introduce some syntactic sugar on this? For exampl

I like the idea, but the mass of `cons` in the pattern matching really turns me off. Would it be possible to introduce some syntactic sugar on this? For example, in Haskell (as you know, but readers may not), `1:2:3:4:5:[]` can be written as `[1,2,3,4,5]` which is much prettier than a lot of cons cells (even if we use the infix (:) for cons).

segmondy 12y ago
The moment you add syntactic sugar to it, you lose the power of sexpressions. You no longer have lists that are easily manipulateable, or can easily be generated via macros or easily worked with a code walker. That's why the L in lisp really means List. Shift away from Lists and you can't even call it lisp at all.
- thurn 12y ago
  Not at all, you can just provide the sugar as an alternative. Much in the same way that '() expands to (quote ...).
- coldtea 12y ago
  Well, I'd rather lose the "power of sexpressions" if I'm to get a nicer syntax. It's not like people have been building more programs in Lisp than in languages without sexpressions.
  - 6d0debc071 12y ago
    Lisp was originally planned to have more syntactic sugar (see M-expressions and MLISP,) but as far as I'm aware it never took off. "The project of defining M-expressions precisely and compiling them or at least translating them into S-expressions was neither finalized nor explicitly abandoned. It just receded into the indefinite future, and a new generation of programmers appeared who preferred internal notation to any FORTRAN-like or ALGOL-like notation that could be devised." - John McCarthy, History of Lisp If you're going to market something as an X then it may not be a good call to remove something that many of the people who use X seem to regard as a desirable attribute of it.
    - coldtea 12y ago
      On the other, couldn't a LISP have a dual syntax? So, you could use the "sugared" syntax, and revert to the isomorphic (that's the world?) sexpression syntax when you want to do s-expressy stuff like macros etc. Of course you'd have to keep in your head the mapping between the sugary and sexpressions version, but it's not that difficult, and you'd only need to do that if you wanted to use sexpressions, not all the time when you don't really need them.
      - 6d0debc071 12y ago
        It's possible that you could create another syntax. But there are some challenges to deal with: 1) The presence of macros. I can extend the language with new syntax however I please. If you just write a parser, the minute I do so, it's going to be very difficult for that parser to determine the order of operations. It has to have some general solution to the problem of precedence. 2) It... I suspect... has to be homoiconic. That is the underlying datastructure that the code corresponds to has to be immediately visible to the human coding. When you write programs that manipulate programs, the lack of this ability cripples you. If new programmers learn ... what I suppose you might call a cleaner syntax ... and then have to switch into sexpressions to see what's going on, I don't much rate their chances of learning Macros - they'd essentially be learning a new language when they got to the point where they'd want to do that. 3) It has to be mappable - and preferably in a reverse compatible way - to, if not all, the vast majority of existing Lisp code, (otherwise people who are already comfortable with Lisp code won't have much incentive to use it.) # I'm not going to say that's not possible. What I will say is that a fair number of people, who I don't think are idiots, have tried to update Lisp syntax in the past. Among others attempts RLisp, Dylan, and IACL2. I'm not aware of any project that's managed to maintain the ability of Lisp to clearly manipulate programs as data and to swap back and forth between interpreted and non-interpreted code. But it's possible they just couldn't see the problem as clearly as we could because they couldn't see that the approaches they tried were going to fail. If you can think of a syntax that solves things, I'd read up on past attempts to see if someone's tried it before and then give it a go. Writing your own reader can be a bit of a pain, but it's probably more doable in Lisp than any other language I can think of. :) Edit: You might find this worth a read - site that goes into considerably more depth on this: http://sourceforge.net/p/readable/wiki/Problem/ http://sourceforge.net/p/readable/wiki/Problem/
magnusjonsson 12y ago
No syntactic sugar needed. In most lisp pattern matching libraries there are higher level matchers such as "list" etc. Just as the first element of a list is a function or special operator in normal context, in a pattern matching context the first element is a matcher. You can even define new matchers if you want, just like you can define new functions. This makes pattern matching libraries in lisp more powerful than the built-in pattern matching of Haskell and other functional languages. I just looked at TFA and yes, it's truly awful. It doesn't have to be that way. See e.g. https://github.com/m2ym/optima https://github.com/m2ym/optima (a pattern matching library for common lisp). I haven't tried it, but I've tried the predecessor of that library.

segmondy 12y ago

The moment you add syntactic sugar to it, you lose the power of sexpressions. You no longer have lists that are easily manipulateable, or can easily be generated via macros or easily worked with a code walker. That's why the L in lisp really means List. Shift away from Lists and you can't even call it lisp at all.

thurn 12y ago
Not at all, you can just provide the sugar as an alternative. Much in the same way that '() expands to (quote ...).
coldtea 12y ago
Well, I'd rather lose the "power of sexpressions" if I'm to get a nicer syntax. It's not like people have been building more programs in Lisp than in languages without sexpressions.
- 6d0debc071 12y ago
  Lisp was originally planned to have more syntactic sugar (see M-expressions and MLISP,) but as far as I'm aware it never took off. "The project of defining M-expressions precisely and compiling them or at least translating them into S-expressions was neither finalized nor explicitly abandoned. It just receded into the indefinite future, and a new generation of programmers appeared who preferred internal notation to any FORTRAN-like or ALGOL-like notation that could be devised." - John McCarthy, History of Lisp If you're going to market something as an X then it may not be a good call to remove something that many of the people who use X seem to regard as a desirable attribute of it.
  - coldtea 12y ago
    On the other, couldn't a LISP have a dual syntax? So, you could use the "sugared" syntax, and revert to the isomorphic (that's the world?) sexpression syntax when you want to do s-expressy stuff like macros etc. Of course you'd have to keep in your head the mapping between the sugary and sexpressions version, but it's not that difficult, and you'd only need to do that if you wanted to use sexpressions, not all the time when you don't really need them.
    - 6d0debc071 12y ago
      It's possible that you could create another syntax. But there are some challenges to deal with: 1) The presence of macros. I can extend the language with new syntax however I please. If you just write a parser, the minute I do so, it's going to be very difficult for that parser to determine the order of operations. It has to have some general solution to the problem of precedence. 2) It... I suspect... has to be homoiconic. That is the underlying datastructure that the code corresponds to has to be immediately visible to the human coding. When you write programs that manipulate programs, the lack of this ability cripples you. If new programmers learn ... what I suppose you might call a cleaner syntax ... and then have to switch into sexpressions to see what's going on, I don't much rate their chances of learning Macros - they'd essentially be learning a new language when they got to the point where they'd want to do that. 3) It has to be mappable - and preferably in a reverse compatible way - to, if not all, the vast majority of existing Lisp code, (otherwise people who are already comfortable with Lisp code won't have much incentive to use it.) # I'm not going to say that's not possible. What I will say is that a fair number of people, who I don't think are idiots, have tried to update Lisp syntax in the past. Among others attempts RLisp, Dylan, and IACL2. I'm not aware of any project that's managed to maintain the ability of Lisp to clearly manipulate programs as data and to swap back and forth between interpreted and non-interpreted code. But it's possible they just couldn't see the problem as clearly as we could because they couldn't see that the approaches they tried were going to fail. If you can think of a syntax that solves things, I'd read up on past attempts to see if someone's tried it before and then give it a go. Writing your own reader can be a bit of a pain, but it's probably more doable in Lisp than any other language I can think of. :) Edit: You might find this worth a read - site that goes into considerably more depth on this: http://sourceforge.net/p/readable/wiki/Problem/ http://sourceforge.net/p/readable/wiki/Problem/

magnusjonsson 12y ago

No syntactic sugar needed. In most lisp pattern matching libraries there are higher level matchers such as "list" etc. Just as the first element of a list is a function or special operator in normal context, in a pattern matching context the first element is a matcher. You can even define new matchers if you want, just like you can define new functions. This makes pattern matching libraries in lisp more powerful than the built-in pattern matching of Haskell and other functional languages. I just looked at TFA and yes, it's truly awful. It doesn't have to be that way. See e.g. https://github.com/m2ym/optima https://github.com/m2ym/optima (a pattern matching library for common lisp). I haven't tried it, but I've tried the predecessor of that library.