Comment by koolmoe | Hacker News Reader

Comment by koolmoe | Hacker News Reader

Parent Full thread

From the article:

"But Lisp is directly executable, so you could simply make the tag names functions that automatically transform themselves."

I don't think we're talking about taking raw strings and doing evals. You control the function implementations so you have control over any danger. Writing the data as a Lisp program saves you the overhead of writing a parser and lexer and all the other tedium associated with building a compiler.

Anyway, languages that can be interpreted really illustrate that it's a blurry line between code and data. Consider Actionscript. It's a scripting language interpreted by Flash, but it's nothing but XML. You could consider it marked up data describing a specific Flash application rather than code. When the interpreter sees the code, it knows how to use the description to generate the app on the fly.

The thing that's really nice about Lisp in this respect is that it makes defining your own domain-specific language (and Actionscript is really a DSL for flash apps) about as easy as it can be. The only downside - if it is a downside at all - is that you will start creating DSL's for every app you build. Maybe that's as it should be. I think so.

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.

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

Reply on news.ycombinator.com