6 ms·

> I have to admit, that at the beginning using brackets was not easy for me. Once I’ve realized that the brackets are just on the other side of the function nam

> I have to admit, that at the beginning using brackets was not easy for me. Once I’ve realized that the brackets are just on the other side of the function name, everything was simple and I could code very fast. A question to fellow Lispers: is there a good reason why LISPs do not put parenthesis they way we know from math? Why `(f foo bar)` and not `f(foo bar)`?

pdonis 7y ago
> is there a good reason why LISPs do not put parenthesis they way we know from math? Why `(f foo bar)` and not `f(foo bar)`? Because the first is a list and the second isn't. The whole point of LISP is to represent code as data, and the fundamental data structure it uses is a list.
- MadWombat 7y ago
  well... (1 2 3) is syntactic sugar for (cons 1 (cons 2 (cons 3 nil))). What prevents someone from adding syntactic sugar f (x y) for (f x y)?
  - dunefox 7y ago
    The fact that one of these is a list of symbols and the other one isn't. They mean different things.
    - MadWombat 7y ago
      > "They mean different things" For fuck's sake, these things don't mean anything by themselves. The only reason they mean different things is because the syntax is defined this way. So back to the original question, why is the syntax defined this way?
      - deleted 7y ago
        [deleted]
      - gsk22 7y ago
        Your proposed syntax becomes ambiguous when you are more than one level deep. What would be the meaning of an expression like f (g (x y)) ? Is it (f (g x y)) or (f g (x y))?
        MadWombat 7y ago
        Hmm... I see. (x y) is a list, g (x y) is a function call, f (...) is another function call, so f (g (x y)) is (f (g x y)) in regular LISP syntax. The syntax is parsed from innermost to outermost, so where is the ambiguity?
        filoeleven 7y ago
        (x y) is also a function call, because lisp always interprets the first position of a list as such unless you quote it: f (g ‘(x y)) But that changes the meaning of g from “a fn with two args” to “a fn with one arg that is a list.” If your meaning is instead that function-outside notation cannot be mixed with s-exps, I.e. you have to choose one mode or the other, then I think you’re right that there’s no ambiguity here (and no need to quote the args above). I suspect you would lose the power of macros, and may not be able to use existing ones, but I don’t write them so I’m not sure. Below are some Clojure expressions with standard and then function-outside versions. I quickly found that I wanted to go back to attached() parens() for those, because that seems more readable to my eyes than having () them () spaced out. I’d never choose this option though, it took all of an afternoon to get used to lisp syntax, and I find it to be more readable now than c-style languages. (let [a 1 b 2] (+ a b)) let ([a 1 b 2] + (a b)) let( [a 1 b 2] +(a b)) (apply + (range 10)) apply(+ range(10)) (defn my-fn [x] (* x x)) defn (my-fn [x] *(x x))
        MadWombat 7y ago
        Eh... you are still stuck with LISP. We are talking about an alternate syntax where (x y) is not a function call.
      - lispm 7y ago
        > why is the syntax defined this way? Because Lisp has two syntax levels: one of s-expressions and one for the programming language on top of s-expressions. S-expression examples (berlin madrid london) (john (age 21) (weight 65)) Lisp code examples: (if (> a b) a b) Non Lisp code, but a valid S-expression: (if (> a b) then a else b) You can define a new syntax for Lisp - like it has been done before - where you traditional syntax to define a programming language. You then just need a grammar and a parser. Originally s-expressions were only thought for data and programs would have a different syntax. A conditional might be written like that. cond a > b -> a ; t -> b Lisp code with lists might then look like: append[ (a,b,c) , car[list] ] Where (a,b,c) is a literal list of three symbols. But the Lisp system was internally defined using lists and the compiler&interpreter were using Lisp code as lists. Thus it was seemed more practical to just work with s-expressions (nested lists, ...) and defer the question of syntax to a later time. Later multiple attempts had been made to define a Lisp with a more traditional syntax: the Lisp 2 effort in the 60s, various syntactic front ends, RLISP, LOGO, ML, Dylan, ... . But for Lisp programmers it was more practical to keep the s-expression syntax, because the internal machineries of Lisp are using s-expressions anyway
    - int_19h 7y ago
      We're talking about syntax, not abstractions. There's no reason why f(x y) can't be a representation of a list that is represented by (f x y) in most Lisps.
  - Sharlin 7y ago
    Because `f (a b)` already means something else: two separate expressions that just happen to be adjacent.
    - pdonis 7y ago
      > `f (a b)` already means something else If it's inside a list already, yes. But if it's just an expression all by itself, it's not even well-formed in LISP, since it's not a list.
      - klez 7y ago
        Depending on what `a` is, it certainly could mean something. Those are two expressions, where `f` by itself does nothing and, if `a` is a function, it will be applied to `b`. If `a` is a macro it will be transformed, and then depends on what it will be transformed into. If `a` is neither, then it's an error.
  - pdonis 7y ago
    > What prevents someone from adding syntactic sugar f (x y) for (f x y)? Because (cons 1 (cons 2 (cons 3 nil))) is a list and f (x y) isn't. You could put parens around the latter to make it (f (x y)), but then you might as well save a pair of parens and just write (f x y).
  - samatman 7y ago
    Absolutely nothing. What you're describing is called in Lisp circles "m-expressions". s-expressions were supposed to be an implementation detail, and programmers were expected to use m-expressions in the day-to-day. No one ever got around to implementing them, though, and if you spend enough time working with Lisp, you'll most likely understand why.
  - kazinator 7y ago
    No it isn't; and your definition is infinitely regressive because it further implies that (cons 1 (cons 2 ...)) is syntactic sugar for (cons 'cons 1 (cons 'cons 2 ...)) and so on.
  - lispm 7y ago
    > (1 2 3) is syntactic sugar for (cons 1 (cons 2 (cons 3 nil))) Not really. (1 2 3) is a list in Lisp. (cons 1 (cons 2 (cons 3 nil))) is code to produce a list. if we have (append '(1 2 3) (cond 1 (cons 2 (cons 3 nil)))) The first is a literal list and the second one is code, which produces a list at some point in time - maybe at runtime.
mdparker89 7y ago
Code is data. `(f foo bar)` is both a list of symbols and a function call.
grayclhn 7y ago
In my (very limited) experience, the benefit's not from representing functions this way, it's from representing everything this way -- including things that would be special syntax in other languages. It makes it easier to write and debug things like macros if the input is already represented as essentially an AST and the output doesn't need to be converted back into special syntax before it can be run.
edflsafoiewq 7y ago
def(fact(n acc) if(=(n 0) acc fact(-(n 1) *(acc n)))) I'm not a fan.
bencw 7y ago
I find this statement from Paul Graham's Revenge of the Nerds enlightening: > Lisp looks strange not so much because it has a strange syntax as because it has no syntax; you express programs directly in the parse trees that get built behind the scenes when other languages are parsed, and these trees are made of lists, which are Lisp data structures.
tpfour 7y ago
You can modify the reader to do that but then you can also just write Python.
abjKT26nO8 7y ago
If you wrote function applications as `f(foo bar)`, then spaces between identifiers and parentheses would be semantically-significant. Putting a space between `f` and the first parenthesis in the aforementioned expression would produce an invalid expression. Similarly, doing the same with `g(baz f(foo bar))` would result in `g(baz f (foo bar))` which is an application of g to 3 arguments, second of which is the procedure bound to f, whereas in the original expression it was an application of g to 2 arguments, second of which was the result of application of f to two arguments. I don't think such sensitivity to whitespace would result in comfortable code editing when you move code around.
agumonkey 7y ago
there are UIs hacking around the idea sweet expression .. I forgot the name, made the top level forms parens-less define fact(n) (if ... ) some other hacks include back-shifting any parens by one symbol to turn <fn>(...) into (<fn> ...) honestly I'm 'astonished' that the sexp debate never dies, no lisper cringes at sexp for more than a week (especially with a structural editing mode)
int_19h 7y ago
Contrary to many of the responses you've got, the real answer is that it's just a convention with no particular reason other than historical cultural preference. For evidence, I present R: it looks like C syntactically, but all constructs actually desugar into function calls (even assignments!). And function calls themselves are also C-style - f(x, y) - but once it's parsed, the result is a "pairlist", which is exactly what it sounds like to any Lisper. So any R program is represented as nested lists, with constants and symbols as leaf nodes, exactly as in Lisp.
TeMPOraL 7y ago
'pdonis gave you the correct answer, but another way of thinking about it: because Lisp way is more consistent. It also makes it more powerful. The math notation we commonly use is mostly a legacy notation, invented before we had computers and could do (or conceive of) symbolic processing. We write `f(foo, bar)` instead of `(f foo bar)` not because the former is better, but because it's been established before we invented trees (data structures) and figured out why they're important.

pdonis 7y ago

> is there a good reason why LISPs do not put parenthesis they way we know from math? Why `(f foo bar)` and not `f(foo bar)`? Because the first is a list and the second isn't. The whole point of LISP is to represent code as data, and the fundamental data structure it uses is a list.

MadWombat 7y ago
well... (1 2 3) is syntactic sugar for (cons 1 (cons 2 (cons 3 nil))). What prevents someone from adding syntactic sugar f (x y) for (f x y)?
- dunefox 7y ago
  The fact that one of these is a list of symbols and the other one isn't. They mean different things.
  - MadWombat 7y ago
    > "They mean different things" For fuck's sake, these things don't mean anything by themselves. The only reason they mean different things is because the syntax is defined this way. So back to the original question, why is the syntax defined this way?
    - deleted 7y ago
      [deleted]
    - gsk22 7y ago
      Your proposed syntax becomes ambiguous when you are more than one level deep. What would be the meaning of an expression like f (g (x y)) ? Is it (f (g x y)) or (f g (x y))?
      - MadWombat 7y ago
        Hmm... I see. (x y) is a list, g (x y) is a function call, f (...) is another function call, so f (g (x y)) is (f (g x y)) in regular LISP syntax. The syntax is parsed from innermost to outermost, so where is the ambiguity?
        filoeleven 7y ago
        (x y) is also a function call, because lisp always interprets the first position of a list as such unless you quote it: f (g ‘(x y)) But that changes the meaning of g from “a fn with two args” to “a fn with one arg that is a list.” If your meaning is instead that function-outside notation cannot be mixed with s-exps, I.e. you have to choose one mode or the other, then I think you’re right that there’s no ambiguity here (and no need to quote the args above). I suspect you would lose the power of macros, and may not be able to use existing ones, but I don’t write them so I’m not sure. Below are some Clojure expressions with standard and then function-outside versions. I quickly found that I wanted to go back to attached() parens() for those, because that seems more readable to my eyes than having () them () spaced out. I’d never choose this option though, it took all of an afternoon to get used to lisp syntax, and I find it to be more readable now than c-style languages. (let [a 1 b 2] (+ a b)) let ([a 1 b 2] + (a b)) let( [a 1 b 2] +(a b)) (apply + (range 10)) apply(+ range(10)) (defn my-fn [x] (* x x)) defn (my-fn [x] *(x x))
        MadWombat 7y ago
        Eh... you are still stuck with LISP. We are talking about an alternate syntax where (x y) is not a function call.
    - lispm 7y ago
      > why is the syntax defined this way? Because Lisp has two syntax levels: one of s-expressions and one for the programming language on top of s-expressions. S-expression examples (berlin madrid london) (john (age 21) (weight 65)) Lisp code examples: (if (> a b) a b) Non Lisp code, but a valid S-expression: (if (> a b) then a else b) You can define a new syntax for Lisp - like it has been done before - where you traditional syntax to define a programming language. You then just need a grammar and a parser. Originally s-expressions were only thought for data and programs would have a different syntax. A conditional might be written like that. cond a > b -> a ; t -> b Lisp code with lists might then look like: append[ (a,b,c) , car[list] ] Where (a,b,c) is a literal list of three symbols. But the Lisp system was internally defined using lists and the compiler&interpreter were using Lisp code as lists. Thus it was seemed more practical to just work with s-expressions (nested lists, ...) and defer the question of syntax to a later time. Later multiple attempts had been made to define a Lisp with a more traditional syntax: the Lisp 2 effort in the 60s, various syntactic front ends, RLISP, LOGO, ML, Dylan, ... . But for Lisp programmers it was more practical to keep the s-expression syntax, because the internal machineries of Lisp are using s-expressions anyway
  - int_19h 7y ago
    We're talking about syntax, not abstractions. There's no reason why f(x y) can't be a representation of a list that is represented by (f x y) in most Lisps.
- Sharlin 7y ago
  Because `f (a b)` already means something else: two separate expressions that just happen to be adjacent.
  - pdonis 7y ago
    > `f (a b)` already means something else If it's inside a list already, yes. But if it's just an expression all by itself, it's not even well-formed in LISP, since it's not a list.
    - klez 7y ago
      Depending on what `a` is, it certainly could mean something. Those are two expressions, where `f` by itself does nothing and, if `a` is a function, it will be applied to `b`. If `a` is a macro it will be transformed, and then depends on what it will be transformed into. If `a` is neither, then it's an error.
- pdonis 7y ago
  > What prevents someone from adding syntactic sugar f (x y) for (f x y)? Because (cons 1 (cons 2 (cons 3 nil))) is a list and f (x y) isn't. You could put parens around the latter to make it (f (x y)), but then you might as well save a pair of parens and just write (f x y).
- samatman 7y ago
  Absolutely nothing. What you're describing is called in Lisp circles "m-expressions". s-expressions were supposed to be an implementation detail, and programmers were expected to use m-expressions in the day-to-day. No one ever got around to implementing them, though, and if you spend enough time working with Lisp, you'll most likely understand why.
- kazinator 7y ago
  No it isn't; and your definition is infinitely regressive because it further implies that (cons 1 (cons 2 ...)) is syntactic sugar for (cons 'cons 1 (cons 'cons 2 ...)) and so on.
- lispm 7y ago
  > (1 2 3) is syntactic sugar for (cons 1 (cons 2 (cons 3 nil))) Not really. (1 2 3) is a list in Lisp. (cons 1 (cons 2 (cons 3 nil))) is code to produce a list. if we have (append '(1 2 3) (cond 1 (cons 2 (cons 3 nil)))) The first is a literal list and the second one is code, which produces a list at some point in time - maybe at runtime.

mdparker89 7y ago

Code is data. `(f foo bar)` is both a list of symbols and a function call.

grayclhn 7y ago

In my (very limited) experience, the benefit's not from representing functions this way, it's from representing everything this way -- including things that would be special syntax in other languages. It makes it easier to write and debug things like macros if the input is already represented as essentially an AST and the output doesn't need to be converted back into special syntax before it can be run.

edflsafoiewq 7y ago

def(fact(n acc) if(=(n 0) acc fact(-(n 1) *(acc n)))) I'm not a fan.

bencw 7y ago

I find this statement from Paul Graham's Revenge of the Nerds enlightening: > Lisp looks strange not so much because it has a strange syntax as because it has no syntax; you express programs directly in the parse trees that get built behind the scenes when other languages are parsed, and these trees are made of lists, which are Lisp data structures.

tpfour 7y ago

You can modify the reader to do that but then you can also just write Python.

abjKT26nO8 7y ago

If you wrote function applications as `f(foo bar)`, then spaces between identifiers and parentheses would be semantically-significant. Putting a space between `f` and the first parenthesis in the aforementioned expression would produce an invalid expression. Similarly, doing the same with `g(baz f(foo bar))` would result in `g(baz f (foo bar))` which is an application of g to 3 arguments, second of which is the procedure bound to f, whereas in the original expression it was an application of g to 2 arguments, second of which was the result of application of f to two arguments. I don't think such sensitivity to whitespace would result in comfortable code editing when you move code around.

agumonkey 7y ago

there are UIs hacking around the idea sweet expression .. I forgot the name, made the top level forms parens-less define fact(n) (if ... ) some other hacks include back-shifting any parens by one symbol to turn <fn>(...) into (<fn> ...) honestly I'm 'astonished' that the sexp debate never dies, no lisper cringes at sexp for more than a week (especially with a structural editing mode)

int_19h 7y ago

Contrary to many of the responses you've got, the real answer is that it's just a convention with no particular reason other than historical cultural preference. For evidence, I present R: it looks like C syntactically, but all constructs actually desugar into function calls (even assignments!). And function calls themselves are also C-style - f(x, y) - but once it's parsed, the result is a "pairlist", which is exactly what it sounds like to any Lisper. So any R program is represented as nested lists, with constants and symbols as leaf nodes, exactly as in Lisp.

TeMPOraL 7y ago

'pdonis gave you the correct answer, but another way of thinking about it: because Lisp way is more consistent. It also makes it more powerful. The math notation we commonly use is mostly a legacy notation, invented before we had computers and could do (or conceive of) symbolic processing. We write `f(foo, bar)` instead of `(f foo bar)` not because the former is better, but because it's been established before we invented trees (data structures) and figured out why they're important.