4 ms·

Now cue all the LISP guys talking about how the code as the compiler represents it and the way they think about it is the same...

taeric 10y ago
To be fair, the easy way to learn LISP is to learn to think about it the way the compiler represents it. :) That is, there is a bit of a forcing function.
qwertyuiop924 10y ago
No, not if they know ANYTHING about Lisp compiler internals. In any lisp compiler/interpreter suited for the Real World, the sexpr tree you see in your code isn't the datastructure the compiler uses. Why? Because that sexpr tree doesn't account for information like line numbers, which are needed by the compiler for error messages, and other data. The sexpr tree that macros are given is an abstraction. As for error messages, macros make it hard to give good ones C programmers who think their preprocessor macros cause bad problems with error messages, get this: If there's an error inside a macro expansion, the compiler/interpreter is getting errors in code that litterally didn't exist in the source code in any form. Furthermore, there are the standard problems of line numbering and giving the programmer information about where the error was in the actual source, all caused by macros. And Lisp macros are far more pervasive in Lisp than preprocessor macros are in C. Racket tries to solve this with syntax-case, but syntax-case is awkward and breaks the standard macro abstraction in a lot of ways. So the problem remains, and is fairly nasty. Although Lisps and Schemes HAVE gotten better about macro errors over the years...
- dill_day 10y ago
  Check out Racket's syntax-parse and the "Fortifying Macros" paper for macros with better error reporting: http://docs.racket-lang.org/syntax/stxparse.html http://docs.racket-lang.org/syntax/stxparse.html http://www.ccs.neu.edu/racket/pubs/icfp10-cf.pdf http://www.ccs.neu.edu/racket/pubs/icfp10-cf.pdf
TeMPOraL 10y ago
Well, there's similarity, but I'd call it a ladder of representation. Your compiler represents your code as AST with some metadata and stuff. Lisp compilers do that too. Lisp source is an executable AST without that metadata, and it being executable gives you shortcuts to make the tree smaller (e.g. macros). Want to see that in action? Look at e.g. the intermediate language between Erlang source and BEAM bytecode - it reads like macroexpanded Lisp code with square brackets instead of parentheses.

taeric 10y ago

To be fair, the easy way to learn LISP is to learn to think about it the way the compiler represents it. :) That is, there is a bit of a forcing function.

qwertyuiop924 10y ago

No, not if they know ANYTHING about Lisp compiler internals. In any lisp compiler/interpreter suited for the Real World, the sexpr tree you see in your code isn't the datastructure the compiler uses. Why? Because that sexpr tree doesn't account for information like line numbers, which are needed by the compiler for error messages, and other data. The sexpr tree that macros are given is an abstraction. As for error messages, macros make it hard to give good ones C programmers who think their preprocessor macros cause bad problems with error messages, get this: If there's an error inside a macro expansion, the compiler/interpreter is getting errors in code that litterally didn't exist in the source code in any form. Furthermore, there are the standard problems of line numbering and giving the programmer information about where the error was in the actual source, all caused by macros. And Lisp macros are far more pervasive in Lisp than preprocessor macros are in C. Racket tries to solve this with syntax-case, but syntax-case is awkward and breaks the standard macro abstraction in a lot of ways. So the problem remains, and is fairly nasty. Although Lisps and Schemes HAVE gotten better about macro errors over the years...

dill_day 10y ago
Check out Racket's syntax-parse and the "Fortifying Macros" paper for macros with better error reporting: http://docs.racket-lang.org/syntax/stxparse.html http://docs.racket-lang.org/syntax/stxparse.html http://www.ccs.neu.edu/racket/pubs/icfp10-cf.pdf http://www.ccs.neu.edu/racket/pubs/icfp10-cf.pdf

TeMPOraL 10y ago

Well, there's similarity, but I'd call it a ladder of representation. Your compiler represents your code as AST with some metadata and stuff. Lisp compilers do that too. Lisp source is an executable AST without that metadata, and it being executable gives you shortcuts to make the tree smaller (e.g. macros). Want to see that in action? Look at e.g. the intermediate language between Erlang source and BEAM bytecode - it reads like macroexpanded Lisp code with square brackets instead of parentheses.