3 ms·
I'm not disagreeing with you, but I think it's important not to conflate the concepts of Lisp's ease of reading/writing arbitrary data and Lisp's ability to rea
by brlewis 19y ago
I'm not disagreeing with you, but I think it's important not to conflate the concepts of Lisp's ease of reading/writing arbitrary data and Lisp's ability to read/write programs using the same facilities.
Using Lisp to read and write a configuration file means you don't need to worry about lexing and parsing either. If you don't use Lisp, or if you don't use S-expressions, you will need to lex and parse the configuration file just to read it, compiler or no compiler.
Depending what domain you program in, a Lisp programmer may not ever need to think about lexing and parsing. I tried a little googling to make sure I was remembering their definitions right and actually didn't come up with anything. From memory, lexing is splitting the input stream up into tokens, and parsing is structuring those tokens into a parse tree. If I'm remembering wrong, re-read the prior paragraph temporarily using those definitions and it will make sense.
- koolmoe 19y ago>Using Lisp to read and write a configuration file means you don't need to worry about lexing and parsing either. That was the point I was trying to make, apparently unsuccessfully. >If you don't use Lisp, or if you don't use S-expressions, you will need to lex and parse the configuration file just to read it, compiler or no compiler. Any time you build a lexer and a parser, you are building a compiler (I'm using a broader meaning of compiler - not necessarily one that outputs bytecode). There are many XML-to-HTML compilers, for example. Lisp macros compile DSL's to Lisp. That's why a Lisp programmer rarely needs to think about lexing and parsing. It is automatic and implied if you address the problem in the right way. It's also why the concepts of data and programs are necessarily conflated in Lisp.