4 ms·

I don't think programs are usually strings. Most programs I see are text files. If I edit them in an editor, I don't know what data structure represents them,

by lispm 9y ago

I don't think programs are usually strings. Most programs I see are text files. If I edit them in an editor, I don't know what data structure represents them, but it might be a doubly linked list of strings, or some other data structure. If a compiler reads a program, it uses typically a stream of characters. A string would be something like this: a delimiter, some characters, the delimiter. Example: "a + b". It could also be a string data object in some program. But programs are not always represented as strings and many are not. Sometimes they are. For example an EVAL procedure may take a string as an argument - then code is represented as a string or passed at runtime as a string object. When we say in Lisp code is data, we actually mean code is data, but not in the trivial form of text representation formats (text files, strings, ...). It's an abbreviation. We expect usually not to mention, that it is not of the trivial version. Like when we speak of a picture with lots of color, we don't mention that this excludes pictures with only black, white and shades of grey. Generally, if I see a + b then it says nothing about a data structure and its syntax to represent that. All I know that it must be a syntactical legal expression in some programming language. If I see Lisp code in the form of (+ a b) I know that this uses the data syntax for s-expressions to represent that code. I then would require that this is syntactical legal Lisp - THIS requires that in an s-expression, the + operator comes first - that it uses prefix syntax. Wien we mean code as data, we mean that Lisp uaes an actual and explicit data format to encode its programs: s-expressions. The data format is similar to JSON or XML, in that it has an explicit external representation. It's also similar to JSON, because both have an internal representation in a programming language. If we would use JSON as a format to encode programs, we would also be able to say, code is data. S-expressions are slightly more effective as data encoding for programs than JSON, because it uses less delimiters and encodes a rich set of data structures. So, yes. Code with a non-trivial and simple data-representation makes Lisp cool.

xfer 9y ago
> Wien we mean code as data, we mean that Lisp uaes an actual and explicit data format to encode its programs: s-expressions. Every programming language uses an "actual" and explicit data format to encode its programs, the valid programs all parse to the corresponding AST. The only thing unique about Lisp here is a construct to parse the serialization format(s-expressions) and perform actions on it i.e. macros. The fact that parsing s-expressions is so trivial makes it seem like manipulating code as data is somehow unique to Lisp.
- lispm 9y ago
  > Every programming language uses an "actual" and explicit data format to encode its programs where? Show me the data format which is used by C programmers to encode programs. A data format with an external and internal representation, and both used by the programmer. An AST of a C compiler isn't it, since the programmer isn't using it. Neither externally as text, nor internally as data. It's only used internally by a compiler - if it does use one. The C programmer does not write code with ASTs, nor does he even manipulate code via ASTs operations. It's not that some languages have ASTs -> they are simply no neutral data format and the programmer isn't using this to write/read programs. In some languages or implementations ASTs are available to the programmer, but this is after a tool (the compiler) has parsed the program according to the language syntax rules. But that is not what Lisp does, s-expressions are more like a general data format which by the Lisp reader (a tool) is used to translate into a token tree. But the Lisp reader is not a compiler internal stage. It's a general tool, which turns externalized data into internalized data. ASTs are also a different thing from s-expressions, since s-expressions don't represent abstract syntax of Lisp programs. S-expressions are language agnostic: it does know nothing about the syntax of Lisp constructs and doesn't represent no syntactic information. On the s-expression level (a b c) is no different from (+ 1 2) or (defun foo ()). The C syntax isn't layered on top of a neutral data format, like Lisp is.
  - xfer 9y ago
    > In some languages or implementations ASTs are available to the programmer, but this is after a tool (the compiler) has parsed the program according to the language syntax rules. But that is not what Lisp does, s-expressions are more like a general data format which by the Lisp reader (a tool) is used to translate into a token tree. But the Lisp reader is not a compiler internal stage. It's a general tool, which turns externalized data into internalized data. So, what additional power Lisp has as "code as data" vs the language that gives power to manipulate ASTs easily(with quasi-quotation)? >ASTs are also a different thing from s-expressions, since s-expressions don't represent abstract syntax of Lisp programs. S-expressions are language agnostic: it does know nothing about the syntax of Lisp constructs and doesn't represent no syntactic information. Irrelevant to the discussion of "code as data". Every language can read s-expr in language agnostic way. > The C syntax isn't layered on top of a neutral data format, like Lisp is. I never said that the languages are built on top of a neutral data format, but asking the benefits of being so. Unless i am mistaken, the only benefit is being easy to parse by tools(editors, compilers etc) and with quasi-quotation the power of macros.

by lispm 9y ago

xfer 9y ago

> Wien we mean code as data, we mean that Lisp uaes an actual and explicit data format to encode its programs: s-expressions. Every programming language uses an "actual" and explicit data format to encode its programs, the valid programs all parse to the corresponding AST. The only thing unique about Lisp here is a construct to parse the serialization format(s-expressions) and perform actions on it i.e. macros. The fact that parsing s-expressions is so trivial makes it seem like manipulating code as data is somehow unique to Lisp.

lispm 9y ago
> Every programming language uses an "actual" and explicit data format to encode its programs where? Show me the data format which is used by C programmers to encode programs. A data format with an external and internal representation, and both used by the programmer. An AST of a C compiler isn't it, since the programmer isn't using it. Neither externally as text, nor internally as data. It's only used internally by a compiler - if it does use one. The C programmer does not write code with ASTs, nor does he even manipulate code via ASTs operations. It's not that some languages have ASTs -> they are simply no neutral data format and the programmer isn't using this to write/read programs. In some languages or implementations ASTs are available to the programmer, but this is after a tool (the compiler) has parsed the program according to the language syntax rules. But that is not what Lisp does, s-expressions are more like a general data format which by the Lisp reader (a tool) is used to translate into a token tree. But the Lisp reader is not a compiler internal stage. It's a general tool, which turns externalized data into internalized data. ASTs are also a different thing from s-expressions, since s-expressions don't represent abstract syntax of Lisp programs. S-expressions are language agnostic: it does know nothing about the syntax of Lisp constructs and doesn't represent no syntactic information. On the s-expression level (a b c) is no different from (+ 1 2) or (defun foo ()). The C syntax isn't layered on top of a neutral data format, like Lisp is.
- xfer 9y ago
  > In some languages or implementations ASTs are available to the programmer, but this is after a tool (the compiler) has parsed the program according to the language syntax rules. But that is not what Lisp does, s-expressions are more like a general data format which by the Lisp reader (a tool) is used to translate into a token tree. But the Lisp reader is not a compiler internal stage. It's a general tool, which turns externalized data into internalized data. So, what additional power Lisp has as "code as data" vs the language that gives power to manipulate ASTs easily(with quasi-quotation)? >ASTs are also a different thing from s-expressions, since s-expressions don't represent abstract syntax of Lisp programs. S-expressions are language agnostic: it does know nothing about the syntax of Lisp constructs and doesn't represent no syntactic information. Irrelevant to the discussion of "code as data". Every language can read s-expr in language agnostic way. > The C syntax isn't layered on top of a neutral data format, like Lisp is. I never said that the languages are built on top of a neutral data format, but asking the benefits of being so. Unless i am mistaken, the only benefit is being easy to parse by tools(editors, compilers etc) and with quasi-quotation the power of macros.