Hacker News Reader

Comment by aap_ | Hacker News Reader

This exactly matches my thoughts. It seems that machine language and LISP are the only two languages (that i know anyway) where code and data are fundamentally the same kind of thing.

View on HN

There are many languages that are dynamic and let you generate code and run it inside the program. For instance in Java you can generate bytecode for a class and run one of the methods. In FORTH you can write new "words" (roughly functions) that are the same as the built-in words.

It is mainly languages built around AOT compilation like C, Pascal, FORTRAN and such that completely separate code and data. (I guess though you can make a C program that writes a C program, runs "cc" on it, makes a shared object file, loads the library dynamically, and calls a function from it.)

Code is data isn't just about emitting and running code. It's also traversing your code as the data structure it is and changing it as you see fit.

Even "languages built around AOT compilation" are increasingly blurring the phase distinction between "ahead-of-time" and "at runtime", via increased use of metaprogramming and constant evaluation facilities. We may end up with a state of things where even some "AOT-language" programs are written to do much of their work at compile time, perhaps adding more and more of those facilities that were formerly allowed only at "runtime".

"Metaprogramming" is a very broad term. Templates etc. might be nice, but it's hardly anything compared to what you can do with Lisp macros (there's an orthogonal issue that this power leads to unreadable code; see "Lisp Curse", but ignore it for now.).

There is this project

https://github.com/paulhoule/ferocity/

which I might finish up when I'm done with the report I'm writing. It is possible to create Java expression trees with trees of static method calls that look a lot like S-expressions and stick them together into statements, methods and classes.

You should be able to do the same tricks people do with LISP macros and it could work code generation miracles but it would have that "LISP curse" problem in spades.

The plan is to generate a code generator that is sufficient to generate the full DSL implementation (ferocity0) and use that to generate the full implementation (ferocity.)

I have some tests for ferocity0 writing .java files to get fed to javac and for ferocity0 running expression trees with a primitive interpreter. Already the type system is enriched over the type system because interpreted ferocity0 can handle Java expressions as a type at run time so you get issues like quoting and unquoting in LISP.

How does this compare to Common Lisp or Scheme macros in in terms of amount of code needed to generate things? How does it compare in terms of what kind of functions and instructions are used? Can one use standard Java language to use it? Could one for example throw a for loop in there or directly write something like "class Point { ..."?

As a sibling post said, code is data is a different thing. https://taeric.github.io/CodeAsData.html is a fun blog I wrote on this once.

I'm aware of a discussion about what homoiconicity should be defined as after Julia claimed to be a homoiconic language. It (and many others) have ways to manipulate the AST with its own language, but requires basically a different set of functions and tools to manipulate it that is different from those that manipulate the data, so that claim was eventually withdrawn.

No one's said the magic word yet: homoiconicity

Forth is the exact same thing.

I’m a Lisper but I love Forth and Forth people. The only computer subculture as devoted to their weird little secret ancient Jedi art as we parenthesis shufflers.

Prolog and Clojure (effectively a LISP dialect) probably also qualify, and more modern: I think that in a way JSON also qualifies.

JSON is not a programming language.

And would have been way cleaner had they just left it as sexprs.

Reply on news.ycombinator.com