3 ms·

> 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 a

by 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.
  - lispm 9y ago
    > power to manipulate ASTs easily(with quasi-quotation)? From a point of Lisp code manipulation, quasi-quotation does not reach far and thus the convenience it provides is only shallow. It's useful to have, but its main purpose is to build up code based on some template mechanism. There are other things which are also important, like destructuring of code, which a typical macro mechanism will support in some way. Another point: to have an AST you need to have the code parsed already. The AST is an output of a parser stage. That means you are bound to the syntax this parser implements and this AST can represent - or you need to be able to feed this parser with different syntax definitions and have it runtime extensible. Since Lisp macros see only code as internal data, the input format is much less limited. It can also transform arbitrary data into code. Or you need to be able to deal in some other with code which does not conform to what the parser expects. > Irrelevant to the discussion of "code as data". Every language can read s-expr in language agnostic way. 'can' vs. usually done is a huge practical difference. s-expressions are not a standard input format for C compiler. I have not seen s-expressions or a similar data format in the C language standard used to represent code. I'd would be interested to see a reference to it, if you have one. > I never said that the languages are built on top of a neutral data format, But Lisp is. > 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. Quasi-quotation is only a convenience feature - which is great, but they don't add any power to the language. Lisp can create the same effects without quasi-quotation. The benefits are: * operations on the data format can be supported in an text editor and then can be applied to both data and code * the code structure is not limited to what syntax a programming language parser implements or what an AST can represent * the manipulation of internal code as data is convenient and simple for many cases, since the typical operations can be applied * the internal format used by Lisp has a default external format, but can also be used with different external formats * the programming language implementation exposes this internal data in various stages to the user, which it then can conveniently use it. For example macros see this data and can transform it with the usual tools. Interpreters use it and can expose it to the developer. The compiler can use it as input. The pretty printer takes it as input to create textual representations. The main point is that it is convenient to use. Thus code transformations and code manipulations of s-expressions are both common and simple in Lisp. The effect is that user-written code manipulation is widely used in Lisp - even at runtime, where for example in C it is typically done in external tools in preprocessor stages or hidden from the user at compile time.

by xfer 9y ago

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.
- lispm 9y ago
  > power to manipulate ASTs easily(with quasi-quotation)? From a point of Lisp code manipulation, quasi-quotation does not reach far and thus the convenience it provides is only shallow. It's useful to have, but its main purpose is to build up code based on some template mechanism. There are other things which are also important, like destructuring of code, which a typical macro mechanism will support in some way. Another point: to have an AST you need to have the code parsed already. The AST is an output of a parser stage. That means you are bound to the syntax this parser implements and this AST can represent - or you need to be able to feed this parser with different syntax definitions and have it runtime extensible. Since Lisp macros see only code as internal data, the input format is much less limited. It can also transform arbitrary data into code. Or you need to be able to deal in some other with code which does not conform to what the parser expects. > Irrelevant to the discussion of "code as data". Every language can read s-expr in language agnostic way. 'can' vs. usually done is a huge practical difference. s-expressions are not a standard input format for C compiler. I have not seen s-expressions or a similar data format in the C language standard used to represent code. I'd would be interested to see a reference to it, if you have one. > I never said that the languages are built on top of a neutral data format, But Lisp is. > 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. Quasi-quotation is only a convenience feature - which is great, but they don't add any power to the language. Lisp can create the same effects without quasi-quotation. The benefits are: * operations on the data format can be supported in an text editor and then can be applied to both data and code * the code structure is not limited to what syntax a programming language parser implements or what an AST can represent * the manipulation of internal code as data is convenient and simple for many cases, since the typical operations can be applied * the internal format used by Lisp has a default external format, but can also be used with different external formats * the programming language implementation exposes this internal data in various stages to the user, which it then can conveniently use it. For example macros see this data and can transform it with the usual tools. Interpreters use it and can expose it to the developer. The compiler can use it as input. The pretty printer takes it as input to create textual representations. The main point is that it is convenient to use. Thus code transformations and code manipulations of s-expressions are both common and simple in Lisp. The effect is that user-written code manipulation is widely used in Lisp - even at runtime, where for example in C it is typically done in external tools in preprocessor stages or hidden from the user at compile time.