8 ms·

Why not reuse Common Lisp macros?

gnulinux 8y ago
Why not use lisp syntax, at all? Why do we have to reinvent syntax every single generation? I'm not an old school engineer (I'm in my early 20s and in my first job, freshly outta college) but I can't see why we don't use lisp, prolog or ML syntax for everything. Seems vastly better than C-like synaxes in all ways I can think of, easier to implement, easier to extend, easier to read (imho) etc... When I program even in a low caliber lisp like elisp (which I do routinely since I use emacs) it feels like syntax gets in my way less frequently compared to python, C, Javascript etc... I just wanna think about my program, and not the syntax. If lisp is not expressive enough, why not just ML? Why do we have to reinvent it so many times when syntax is not an interesting or relevant problem (e.g. Rust syntax)?
- jclulow 8y ago
  Because not everyone agrees (thankfully!) that syntax is uninteresting or irrelevant, or that Lisp is some amazing global aesthetic or ergonomic maximum.
  - AnaniasAnanas 8y ago
    Why thankfully?
    - AnimalMuppet 8y ago
      Because syntax actually does matter, and Lisp is only a local maximum. Thinking otherwise causes pain, as people try to use Lisp in situations where it is not the best answer, and is therefore harder to use than other languages. So, "thankfully", because acknowledging reality here means not having to live with the pain of using a language that is sub-optimal for the problem you're working on.
      - taeric 8y ago
        This is overstating the case for syntax. Without any empirical evidence that syntax is important to anyone other than folks that draft up syntax rules, this is just an assertion. Put another way, do you have evidence that it is important? Has it let people write better programs? How would you prove that? This is akin to saying grammar is important. It is, to an extent; but over adherence to grammar is usually not an effective way to communicate.
        AnimalMuppet 8y ago
        Well, empirically, syntax is important to a large number of programmers who complain about Lisp's (lack of) syntax. That's not a rigorous empirical study, but it's the best I can do at the moment...
        taeric 8y ago
        I assert most programmers have not been exposed to lisp. I further assert most that complain of it's lack of syntax have not used it in any capacity. I would be interested in studies on this. Most I ever see is posturing and assertions with little to no evidence. Frustrating, because I think both sides have valid points. And I fully believe there is a learning curve both ways. I suspect they both converge on total ability. I am genuinely interested in ideas on how that could be explored.
        AnimalMuppet 8y ago
        I think it's going to be really hard to do the study in a rigorous way. Solid data would be nice, though. Then we could stop guessing. My best try at a data point is that Lisp was #4 on the TIOBE index back in the 1980s. Now it's on the fringe. I assert that people had been exposed to Lisp, it was widely used. It became less and less popular. It's not that industry didn't know Lisp; they knew it and turned away from it. Of course, the big flaw in my argument is the growth of the industry. A huge number of new people came in. Did they know Lisp, even at a college level? Maybe, maybe not. My counter-argument to that is that industry knew Lisp, even if the new programmers didn't. If industry wanted them to learn Lisp, it could have made knowing it a job requirement, or trained people.
- evmar 8y ago
  I tinkered a bit (as many others have too!) with a lisp syntax for C, just to see what it'd feel like. That is, exact C semantics (so not inventing anything) but sexpressions. What I remember struggling with is that it was surprisingly kind of hard to remember when parens are necessary where. For example you might define an if statement: (if (> x 3) (printf ...)) Looks nice, but what about if you want multiple things in the body? Your options are (if (> x 2) (progn (printf a) (return b))) Where "progn" means "curly braces" effectively, or instead always requiring a list-shaped argument (if (> x 2) ((printf a) (return b))) which means in even the single-expression case you have to remember to always double-wrap (if (> x 2) ((printf a))) And now throw in handling of 'else' into the above. It gets surprisingly hard to use surprisingly fast. This problem repeats everywhere (function definitions, type declarations, for loops, and so on). What all the above really clarified for me is that sexps work great in languages like lisp/scheme that are designed around them, but they don't solve syntax for free.
  - AnaniasAnanas 8y ago
    Or "if" could be a special form so that you can just write (if (> x 3) (printf a) (printf b))
    - erik_seaberg 8y ago
      WHEN takes an implicit PROGN like that (so does UNLESS). IF can't because it needs to delimit the then-form from the else-form somehow. http://clhs.lisp.se/Body/m_when_.htm http://clhs.lisp.se/Body/m_when_.htm
  - lispm 8y ago
    See the Common Lisp IF* macro: (if* (> 3 2) then (foo) (bar) else (baz)) https://franz.com/~jkf/ifstar.txt https://franz.com/~jkf/ifstar.txt
  - kazinator 8y ago
    (when (> x ) (printf a) (return b)) (cond ((> x 3) (printf a) (return b)) ((< x 2) (printf b) (return a)) (t (return c))) Nobody who works with Lisps thinks in terms of "do I need double parentheses". You just know that if takes two or three expressions, when takes an expression followed by zero or more forms, cond takes a sequence of zero or more clauses which consist of a test followed by a body of zero or more forms. If you're designing an S-exp syntax for something else, it's probably best to keep the familiar things the same; don't make some different if and such. The Lisp if maps naturally to the ?: ternary operator; cond, when and unless can compile to cascaded if/else if/else.
- oblio 8y ago
  The average programmers seem to like different symbols for what they consider different things. I don't know if it is better or not, but it seems to be the status quo...
  - goatlover 8y ago
    But if that's really the case, then why hasn't Perl way of denoting the basic kind of variable with a starting symbol been copied in other languages? My guess is because most languages don't do that, so people are used to variables not having a symbol denoting their basic type. It largely comes down to what sort of syntax people are accustomed to.
    - vgy7ujm 8y ago
      It was copied. Php, Ruby, Powershell...
- pjc50 8y ago
  The ""market"" (including me) overwhelmingly prefers Algol-derived languages. The different types of bracket used in different ways seem to be a benefit. Very few empirical studies of this have been done, and there's also the problem that "easy to read (for newbies)" and "easiest to read (for experienced people familiar with C syntax)" can be completely different.
slavapestov 8y ago
This is not a very useful thing to say. Macros have nothing to do with generics.
- dagss 8y ago
  ...except that both can be applied to solve the same problems. And so they are in fact very related. For instance with a macro you could do (made up syntax) SortIntSlice = mymacros.MakeSorter!(int) ...then at compile time have code for sorting a slice of ints generated. This is again similar to C++ templates (main difference is C++ will implicitly instantiate instead of explicitly). And C++ doesn't need generocs because people use templates instead. They really are in the same problem domain.
  - djur 8y ago
    Using macros to implement generics has the same problem that C++ templates have, which is described in the Go 2 generics proposal: it's difficult to provide clear error messages for developers in many cases. Functions parameterized on a single type are the easy problem to solve. Where things get thorny is when you parameterize on multiple types with various constraints and/or have some kind of interaction in the function body. The goal of the Go 2 generics contracts (and C++ concepts, Haskell typeclasses, Rust traits, etc.) is to make those expectations explicit.
    - slavapestov 8y ago
      Macros and C++ templates are also incompatible with separate compilation which leads to increased compile times and binary bloat.

Why not use lisp syntax, at all? Why do we have to reinvent syntax every single generation? I'm not an old school engineer (I'm in my early 20s and in my first job, freshly outta college) but I can't see why we don't use lisp, prolog or ML syntax for everything. Seems vastly better than C-like synaxes in all ways I can think of, easier to implement, easier to extend, easier to read (imho) etc... When I program even in a low caliber lisp like elisp (which I do routinely since I use emacs) it feels like syntax gets in my way less frequently compared to python, C, Javascript etc... I just wanna think about my program, and not the syntax. If lisp is not expressive enough, why not just ML? Why do we have to reinvent it so many times when syntax is not an interesting or relevant problem (e.g. Rust syntax)?

jclulow 8y ago
Because not everyone agrees (thankfully!) that syntax is uninteresting or irrelevant, or that Lisp is some amazing global aesthetic or ergonomic maximum.
- AnaniasAnanas 8y ago
  Why thankfully?
  - AnimalMuppet 8y ago
    Because syntax actually does matter, and Lisp is only a local maximum. Thinking otherwise causes pain, as people try to use Lisp in situations where it is not the best answer, and is therefore harder to use than other languages. So, "thankfully", because acknowledging reality here means not having to live with the pain of using a language that is sub-optimal for the problem you're working on.
    - taeric 8y ago
      This is overstating the case for syntax. Without any empirical evidence that syntax is important to anyone other than folks that draft up syntax rules, this is just an assertion. Put another way, do you have evidence that it is important? Has it let people write better programs? How would you prove that? This is akin to saying grammar is important. It is, to an extent; but over adherence to grammar is usually not an effective way to communicate.
      - AnimalMuppet 8y ago
        Well, empirically, syntax is important to a large number of programmers who complain about Lisp's (lack of) syntax. That's not a rigorous empirical study, but it's the best I can do at the moment...
        taeric 8y ago
        I assert most programmers have not been exposed to lisp. I further assert most that complain of it's lack of syntax have not used it in any capacity. I would be interested in studies on this. Most I ever see is posturing and assertions with little to no evidence. Frustrating, because I think both sides have valid points. And I fully believe there is a learning curve both ways. I suspect they both converge on total ability. I am genuinely interested in ideas on how that could be explored.
        AnimalMuppet 8y ago
        I think it's going to be really hard to do the study in a rigorous way. Solid data would be nice, though. Then we could stop guessing. My best try at a data point is that Lisp was #4 on the TIOBE index back in the 1980s. Now it's on the fringe. I assert that people had been exposed to Lisp, it was widely used. It became less and less popular. It's not that industry didn't know Lisp; they knew it and turned away from it. Of course, the big flaw in my argument is the growth of the industry. A huge number of new people came in. Did they know Lisp, even at a college level? Maybe, maybe not. My counter-argument to that is that industry knew Lisp, even if the new programmers didn't. If industry wanted them to learn Lisp, it could have made knowing it a job requirement, or trained people.
evmar 8y ago
I tinkered a bit (as many others have too!) with a lisp syntax for C, just to see what it'd feel like. That is, exact C semantics (so not inventing anything) but sexpressions. What I remember struggling with is that it was surprisingly kind of hard to remember when parens are necessary where. For example you might define an if statement: (if (> x 3) (printf ...)) Looks nice, but what about if you want multiple things in the body? Your options are (if (> x 2) (progn (printf a) (return b))) Where "progn" means "curly braces" effectively, or instead always requiring a list-shaped argument (if (> x 2) ((printf a) (return b))) which means in even the single-expression case you have to remember to always double-wrap (if (> x 2) ((printf a))) And now throw in handling of 'else' into the above. It gets surprisingly hard to use surprisingly fast. This problem repeats everywhere (function definitions, type declarations, for loops, and so on). What all the above really clarified for me is that sexps work great in languages like lisp/scheme that are designed around them, but they don't solve syntax for free.
- AnaniasAnanas 8y ago
  Or "if" could be a special form so that you can just write (if (> x 3) (printf a) (printf b))
  - erik_seaberg 8y ago
    WHEN takes an implicit PROGN like that (so does UNLESS). IF can't because it needs to delimit the then-form from the else-form somehow. http://clhs.lisp.se/Body/m_when_.htm http://clhs.lisp.se/Body/m_when_.htm
- lispm 8y ago
  See the Common Lisp IF* macro: (if* (> 3 2) then (foo) (bar) else (baz)) https://franz.com/~jkf/ifstar.txt https://franz.com/~jkf/ifstar.txt
- kazinator 8y ago
  (when (> x ) (printf a) (return b)) (cond ((> x 3) (printf a) (return b)) ((< x 2) (printf b) (return a)) (t (return c))) Nobody who works with Lisps thinks in terms of "do I need double parentheses". You just know that if takes two or three expressions, when takes an expression followed by zero or more forms, cond takes a sequence of zero or more clauses which consist of a test followed by a body of zero or more forms. If you're designing an S-exp syntax for something else, it's probably best to keep the familiar things the same; don't make some different if and such. The Lisp if maps naturally to the ?: ternary operator; cond, when and unless can compile to cascaded if/else if/else.
oblio 8y ago
The average programmers seem to like different symbols for what they consider different things. I don't know if it is better or not, but it seems to be the status quo...
- goatlover 8y ago
  But if that's really the case, then why hasn't Perl way of denoting the basic kind of variable with a starting symbol been copied in other languages? My guess is because most languages don't do that, so people are used to variables not having a symbol denoting their basic type. It largely comes down to what sort of syntax people are accustomed to.
  - vgy7ujm 8y ago
    It was copied. Php, Ruby, Powershell...
pjc50 8y ago
The ""market"" (including me) overwhelmingly prefers Algol-derived languages. The different types of bracket used in different ways seem to be a benefit. Very few empirical studies of this have been done, and there's also the problem that "easy to read (for newbies)" and "easiest to read (for experienced people familiar with C syntax)" can be completely different.

slavapestov 8y ago

This is not a very useful thing to say. Macros have nothing to do with generics.

dagss 8y ago
...except that both can be applied to solve the same problems. And so they are in fact very related. For instance with a macro you could do (made up syntax) SortIntSlice = mymacros.MakeSorter!(int) ...then at compile time have code for sorting a slice of ints generated. This is again similar to C++ templates (main difference is C++ will implicitly instantiate instead of explicitly). And C++ doesn't need generocs because people use templates instead. They really are in the same problem domain.
- djur 8y ago
  Using macros to implement generics has the same problem that C++ templates have, which is described in the Go 2 generics proposal: it's difficult to provide clear error messages for developers in many cases. Functions parameterized on a single type are the easy problem to solve. Where things get thorny is when you parameterize on multiple types with various constraints and/or have some kind of interaction in the function body. The goal of the Go 2 generics contracts (and C++ concepts, Haskell typeclasses, Rust traits, etc.) is to make those expectations explicit.
  - slavapestov 8y ago
    Macros and C++ templates are also incompatible with separate compilation which leads to increased compile times and binary bloat.