4 ms·

Lambdas are just functions. Delaying functionality is just one use of functions. > that wording somehow implies that they somehow retain the semantics of the d

by lispm 8y ago

Lambdas are just functions. Delaying functionality is just one use of functions. > that wording somehow implies that they somehow retain the semantics of the data passed to them Since they can do arbitrary transformations, retaining semantics is not in focus. Since the input may not have any semantics defined, the semantics is actually provided via the macro implementation. > S-Expressions are just a serialisation format for the m-expression AST. S-expressions know nothing about 'syntax'. Thus they can't be an 'abstract syntax tree'. (3 4 +) is a valid s-expression, but carries no information about any syntax (what is the + ? in an s-expression it's just a symbol) and is also an invalid Lisp expression. An abstract syntax tree would be the result of parsing a program according to some grammar and it would represent the syntactic categories. The parsing stage would already eliminate invalid programs of that programming language. https://upload.wikimedia.org/wikipedia/commons/thumb/c/c7/Abstract_syntax_tree_for_Euclidean_algorithm.svg/800px-Abstract_syntax_tree_for_Euclidean_algorithm.svg.png https://upload.wikimedia.org/wikipedia/commons/thumb/c/c7/Ab... In Lisp it is important that the s-expression is NOT a syntax tree. Otherwise it would be difficult to write macros which violate Lisp syntax.

agumonkey 8y ago
I know you're rigorous and mostly right, but you forget to admit that for most practical uses s-exps encode trees and are used as ad-hoc AST's. People just make implicit grammars based on spec like predicate patterns.
- j-pb 8y ago
  He's not even right. He's pseudo rigorous to support is CL zealot trolling. He made it far enough into the wikipedia article to find a graphic that pseudo supports his claim, but not far enough to actually read the definition of an Abstract Syntax Tree (the thing we talk about) vs Concrete Syntax Tree (the thing he talks about). > This distinguishes abstract syntax trees from concrete syntax trees, traditionally designated parse trees, which are typically built by a parser during the source code translation and compiling process.
  - lispm 8y ago
    You might want to reread the Wikipedia article and tone down a bit: Check out the abstract syntax tree on the right: https://en.wikipedia.org/wiki/Abstract_syntax_tree It has a node which is a BRANCH and which has three relations CONDITION, IF-BODY, ELSE-BODY. In an s-expression this is just (if (> a b) (setq a (- a b)) (setq b (- b a)) Thus there is no representation that IF is a branching expression, there is no representation that A and B are variables. There is no representation that > is a compare op. And so on. The s-expressions are just nested lists of tokens without any idea what the tokens refers to or what language construct it stands for. All we know is what the tokens are and a hierarchy. A is a symbol, but what kind we don't know: it could be a data object, a variable name, a function name, a goto tag, a name of a class, a name of a type, ...). In the abstract syntax tree the > is identified as a compare op, IF is identified as a branch, A is identified as a variable identifier, ... The Lisp reader also does not create that information. It just creates a data structure, which could be anything, any kind of data.
j-pb 8y ago
> Delaying functionality is just one use of functions. This is why explicitly said Lambdas. Name one use of lambdas not covered by functions that is not delayed evaluation. If you want to be pedantic please be so consistently. > S-expressions know nothing about 'syntax'. Thus they can't be an AST. You seem to be confusing what the CL Hyperspec calls syntax, which is actually the semantics of evaluating a certain expression list, with the actual parse tree that can be generated from M-Expressions. And you seem to confuse Abstract Syntax Trees which can contain pretty much anything with Concrete Syntax Trees generated by parsing (it's explained on the very wiki page you linked). And even IF they were the same, M-Exps themselves are so flexible that they can express everything as function calls and arguments, and since the original Lisp only had a single symbol type your (3 4 +) argument itself is flawed. You're way to focused on how CL does things, maybe it's your CL background that actually causes you to miss the bigger picture of lisp, something you accuse the people of that come from Java.
- lispm 8y ago
  > This is why explicitly said Lambdas A lambda is a function. There is nothing special about them. There is nothing which makes them less or more functional than other functions. ((lambda (x) (* x 10)) 30) FYI: above is valid Scheme code. BiwaScheme Interpreter version 0.6.4 Copyright (C) 2007-2014 Yutaka HARA and the BiwaScheme team ((lambda (x) (* x 10)) 30) => 300 Above is lambda expression applied to an argument. There is nothing 'delaying' about it. > You seem to be confusing what the CL Hyperspec calls syntax, No, I'm looking at the Racket documentation. https://docs.racket-lang.org/reference/syntax-model.html https://docs.racket-lang.org/reference/syntax-model.html The reader in Racket reads expressions into syntax objects. In a second pass it then creates a complete parse. In an Interpreter based Lisp one reads the s-expression into an internal representation of lists, symbols, numbers. The interpreter then has the syntax encoded into its code and walks these lists keeping track of functions, variables, built-in operators, bindings, ... etc. That's pretty much what a Lisp interpreter did since the dawn of time. Two decades before CL even existed. Clojure even doesn't use an interpreter.
  - j-pb 8y ago

by lispm 8y ago

agumonkey 8y ago

I know you're rigorous and mostly right, but you forget to admit that for most practical uses s-exps encode trees and are used as ad-hoc AST's. People just make implicit grammars based on spec like predicate patterns.

j-pb 8y ago
He's not even right. He's pseudo rigorous to support is CL zealot trolling. He made it far enough into the wikipedia article to find a graphic that pseudo supports his claim, but not far enough to actually read the definition of an Abstract Syntax Tree (the thing we talk about) vs Concrete Syntax Tree (the thing he talks about). > This distinguishes abstract syntax trees from concrete syntax trees, traditionally designated parse trees, which are typically built by a parser during the source code translation and compiling process.
- lispm 8y ago
  You might want to reread the Wikipedia article and tone down a bit: Check out the abstract syntax tree on the right: https://en.wikipedia.org/wiki/Abstract_syntax_tree It has a node which is a BRANCH and which has three relations CONDITION, IF-BODY, ELSE-BODY. In an s-expression this is just (if (> a b) (setq a (- a b)) (setq b (- b a)) Thus there is no representation that IF is a branching expression, there is no representation that A and B are variables. There is no representation that > is a compare op. And so on. The s-expressions are just nested lists of tokens without any idea what the tokens refers to or what language construct it stands for. All we know is what the tokens are and a hierarchy. A is a symbol, but what kind we don't know: it could be a data object, a variable name, a function name, a goto tag, a name of a class, a name of a type, ...). In the abstract syntax tree the > is identified as a compare op, IF is identified as a branch, A is identified as a variable identifier, ... The Lisp reader also does not create that information. It just creates a data structure, which could be anything, any kind of data.

j-pb 8y ago

> Delaying functionality is just one use of functions. This is why explicitly said Lambdas. Name one use of lambdas not covered by functions that is not delayed evaluation. If you want to be pedantic please be so consistently. > S-expressions know nothing about 'syntax'. Thus they can't be an AST. You seem to be confusing what the CL Hyperspec calls syntax, which is actually the semantics of evaluating a certain expression list, with the actual parse tree that can be generated from M-Expressions. And you seem to confuse Abstract Syntax Trees which can contain pretty much anything with Concrete Syntax Trees generated by parsing (it's explained on the very wiki page you linked). And even IF they were the same, M-Exps themselves are so flexible that they can express everything as function calls and arguments, and since the original Lisp only had a single symbol type your (3 4 +) argument itself is flawed. You're way to focused on how CL does things, maybe it's your CL background that actually causes you to miss the bigger picture of lisp, something you accuse the people of that come from Java.

lispm 8y ago
> This is why explicitly said Lambdas A lambda is a function. There is nothing special about them. There is nothing which makes them less or more functional than other functions. ((lambda (x) (* x 10)) 30) FYI: above is valid Scheme code. BiwaScheme Interpreter version 0.6.4 Copyright (C) 2007-2014 Yutaka HARA and the BiwaScheme team ((lambda (x) (* x 10)) 30) => 300 Above is lambda expression applied to an argument. There is nothing 'delaying' about it. > You seem to be confusing what the CL Hyperspec calls syntax, No, I'm looking at the Racket documentation. https://docs.racket-lang.org/reference/syntax-model.html https://docs.racket-lang.org/reference/syntax-model.html The reader in Racket reads expressions into syntax objects. In a second pass it then creates a complete parse. In an Interpreter based Lisp one reads the s-expression into an internal representation of lists, symbols, numbers. The interpreter then has the syntax encoded into its code and walks these lists keeping track of functions, variables, built-in operators, bindings, ... etc. That's pretty much what a Lisp interpreter did since the dawn of time. Two decades before CL even existed. Clojure even doesn't use an interpreter.
- j-pb 8y ago