3 ms·

I think you're conflating syntax with semantics.

by stray 11y ago

Avshalom 11y ago
I am not. Syntax is the structure, semantics the meaning (I mean more or less). (def (fun x y) (...)) is syntactically different than (def fun (x y) (...)) even if they are semantically equivalent.
- Avshalom 11y ago
  (3) vs 3 is a both really. In say smalltalk you can call 3 and it would return 3 because semantically it's an object where as in lisp it's not callable (even if in CL it may be represented as a CLOS object I don't know) syntactical ( ) isn't actually a procedure call we can see this in (define (id x y) (..)) or (let ((x 3)) ...) in the theoretically pure Lisp semantically it's just a leaf in the tree but as part of an if-block in a real language it gets treated as procedure call even if it makes no sense.
- greydius 11y ago
  The syntax is the same. Both are s-expressions. The difference is how a particular implementation interprets them. In this example, it would depend on the semantics of def.
  - lispm 11y ago
    That's only the syntax of s-expressions - a data format. The Lisp syntax is defined on top of s-expressions. For example Common Lisp has a CASE operator. That's the EBNF syntax: case keyform {normal-clause}* [otherwise-clause] => result* normal-clause::= (keys form*) otherwise-clause::= ({otherwise | t} form*) An example: (case id (10 (foo)) (20 (foo) (bar)) (otherwise (baz))) The expressions are written using s-expressions as data. But still there is structure in those s-expressions, described by the EBNF syntax of CASE. Every special operator and every macro provides syntax. Since users can write macros themselves, everybody can extend the syntax. On top of s-expressions.
    - greydius 11y ago
      That is interesting. I've always considered lisp in terms of denotational semantics. In fact, I wrote a toy lisp in which the complete grammar was basically list -> ({symbol | number | string | list}*) and then it was up to the interpreter to decide the meaning of special forms. (I say "basically" because there was also desugaring of '(...) to (quote ...)).

I think you're conflating syntax with semantics.

by stray 11y ago

I think you're conflating syntax with semantics.

I am not. Syntax is the structure, semantics the meaning (I mean more or less). (def (fun x y) (...)) is syntactically different than (def fun (x y) (...)) even if they are semantically equivalent.

Avshalom 11y ago
(3) vs 3 is a both really. In say smalltalk you can call 3 and it would return 3 because semantically it's an object where as in lisp it's not callable (even if in CL it may be represented as a CLOS object I don't know) syntactical ( ) isn't actually a procedure call we can see this in (define (id x y) (..)) or (let ((x 3)) ...) in the theoretically pure Lisp semantically it's just a leaf in the tree but as part of an if-block in a real language it gets treated as procedure call even if it makes no sense.
greydius 11y ago
The syntax is the same. Both are s-expressions. The difference is how a particular implementation interprets them. In this example, it would depend on the semantics of def.
- lispm 11y ago
  That's only the syntax of s-expressions - a data format. The Lisp syntax is defined on top of s-expressions. For example Common Lisp has a CASE operator. That's the EBNF syntax: case keyform {normal-clause}* [otherwise-clause] => result* normal-clause::= (keys form*) otherwise-clause::= ({otherwise | t} form*) An example: (case id (10 (foo)) (20 (foo) (bar)) (otherwise (baz))) The expressions are written using s-expressions as data. But still there is structure in those s-expressions, described by the EBNF syntax of CASE. Every special operator and every macro provides syntax. Since users can write macros themselves, everybody can extend the syntax. On top of s-expressions.
  - greydius 11y ago
    That is interesting. I've always considered lisp in terms of denotational semantics. In fact, I wrote a toy lisp in which the complete grammar was basically list -> ({symbol | number | string | list}*) and then it was up to the interpreter to decide the meaning of special forms. (I say "basically" because there was also desugaring of '(...) to (quote ...)).