Hacker News new | ask | show | jobs
by bennofs 2012 days ago
One problem with this is that formatting now becomes a multi-file thing. You have now have to figure out what names actually refer to, which depends on building a project model to correctly resolve imports, etc....

Compare this with traditional formatters, which you can run on each single file individually, this is much more complex and also harder to parallelise.

1 comments

I am not sure if I understand what you mean with multi-file and why it matters. As a lisp, the program is already in memory, I can interact with it through the repl. I am sure I can ask it to format itself?

If the program has syntax errors, nothing can happen, how would it know how to format it self if it is not correct?

Perhaps the approach is very different in lisp (and smalltalk which I have some experience with), there is no parsing of the program from the outside - or - if you take that approach and treat the s-expr as dead text you have to sort of reimplement the parser (or the system) in order to have some understanding of it, which in my mind seems very inefficient.

> I am sure I can ask it to format itself?

You don't want to be doing anything of the sort. That is a misconception. The representation of the Lisp program in memory is not the source code. Lisp is not homoiconic according to the original definition by Douglas McIlroy, which is that programs are stored in memory in the original representation entered by the programmer.

Some Lisps keep only a compiled version of the code in memory.

Even those that keep the structural source code in memory (e.g. in support of the ed function in Common Lisp or something like it), it will not be faithful to the original. For example, semicolon comments are stripped away by the reader, and any read-time processing is performed. For instance, Lisps that process the backquote syntax at read time will not preserve the original.

I've also never heard of a modern Lisp implementation in which a global variable definition like (defvar foo (+ 1 2)) retains the unevaluated (+ 1 2) somewhere.

How integrated Lisp environments work is that there are editing buffers with code, and code is re-read from those buffers when edited, into the same running image. Some of the buffers may contain "throwaway" calculations, like interactive testing, and some contain files that are persisted (and version controlled). The user interface doesn't necessarily run in the same image; it could be connected to a remote image (exemplified by users working with Emacs to interact with an image over Slime).