Hacker News Reader

Comment by School-Cotton | Hacker News Reader

I still don’t understand what advising has to do with homoiconicity. When you advise a function in emacs you’re not traversing its code as data, you’re adding some code to run at a predefined hook like :before, :after, etc., and I don’t see any reason why you couldn’t write a python interpreter that also lets you do the same thing. You could also have a repl implemented on top of this interpreter in python itself and advise and modify the running repl — just like you can with emacs.

So I’m again asking for a specific, concrete example of something you can do in emacs lisp that you couldn’t make a python interpreter do — not just waxing lyrical about how great lisp is.

View on HN

Right, advising itself on the surface doesn't seem to be inherently tied to homoiconicity, here's the concrete example in Elisp, this would print how long it took to evaluate a form.

     (defun add-timing-advice (orig-fun &rest args)
       (let ((start-time (current-time)))
         (prog1 (apply orig-fun args)
           (message "Evaluation took %f seconds" 
                    (float-time (time-subtract (current-time) start-time))))))

     (advice-add 'eval-print-last-sexp :around #'add-timing-advice)

While advising isn't inherently tied to homoiconicity, it is significantly easier to implement and more powerful in a homoiconic language.

Here's a different (not related to advising) example of redefining core macro, introducing code that "writes code":

    (defmacro lambda (args &rest body)
      `(function (lambda ,args 
                   (print "Lambda called!")
                   ,@body)))

Now every lambda expression will print a message when called.

To implement something like that in Python, you'd have to modify the parser and complier, alter the runtime, reimplement core language constructs, but most importantly, you will have to change Python's syntax to make all code easily representable as data structures. Which then will become not Python but entirely different language.

Your lambda example is a fair point, but will that apply to things that have already been byte-compiled?

I'm not exactly sure what you mean, tbh.

I mean, if a function that uses lambda has already been parsed and compiled, I’m guessing it won’t magically be updated to use the new definition of lambda. Not sure if I’m correct about that.

In this case it would't care. Since it's basically redefining what (lambda) means to the Reader. That is where that notorious distinction of Read-Eval-Print-Loop comes to play.

1. Read:

- In Python, the read phase must parse text into an intermediate representation (AST) that is distinct from Python's data structures. During the read phase, Python using built-in tokenizer and parser, parses its infamous indent-based syntax, handles literals, identifiers, keywords, operators, decorators, docstrings, comments, etc. Finally, it builds an AST.

- In Lisp, the read phase produces a data structure (s-expressions) that is directly usable as code. The syntax and the abstract syntax tree are essentially the same thing. Lisp uses built-in Reader - parses s-expressions while handling special syntax elements - quotes, backticks, commas, hash-quotes, handles reader macros, parses numbers strings, other literals, comments. But! No need to build an AST - the code already is.

2. Eval:

- Lisp can evaluate the s-expressions directly. The code is data, and data is code. That's where macros get expanded before the evaluation, function calls are resolved, symbols are looked up, tail calls optimized, byte-code compilation is available but not mandatory.

- Python must compile its AST into bytecode before execution. Python uses stack-based VM, figures out scoping and class namespaces, special forms (if, for, def) handled by specific bytecode instructions. Decorators are applied, reference counting and GC, tail call optimization (if runtime has it, standard CPython doesn't). It always has to compile bytecode before execution.

- Lisp macros operate on the code structure directly, allowing for powerful metaprogramming. Python's metaclasses and decorators are more limited in comparison.

3. Print:

- Elisp's printed representation of data is often directly readable as code. What you see is what you can evaluate. Eisp has built-in circular structure handling, Python doesn't. Elisp's printing is more focused on producing readable/evaluable Lisp expressions

- Python's printed representation, especially for complex objects, is often not directly executable code. Python's object-oriented approach allows for more customization through methods

4. Loop:

The Loop phase in both cases ensures that the REPL continues to accept and process input, making interactive development and experimentation possible.

- In Lisp, you can easily manipulate the environment, even the REPL itself, using the same language constructs.

- Python's REPL is more of a black box from the language's perspective.

> Lisp can evaluate the s-expressions directly.

Not generally: in compiler-only implementations this is not provided.

I think you're mixing up other Lisps with Elisp. In this particular thread I'm specifically talking about Elisp, even though, in retrospect, I should've been more explicit about it and not dropped the 'E'.

AFAIK, Elisp is an interpreted language by design and always has the ability to evaluate s-expressions directly at runtime, there's no compiler-only implementation of Elisp. There's native compilation introduced in Emacs 28, but it just adds a layer of optimization, the interpreter still exists and can evaluate s-expressions directly, it doesn't turn Elisp into a "compiler-only" implementation.

But yes, there are other Lisps that compile code to machine lang, without an interpreter.

Good catch and a fine note, thank you!

Especially since many compiler-only implementations can evaluate Lisp code at runtime, just fine, even though they don't execute s-expressions in an Interpreter. Thus an compiler-only Lisp can be used to implement Emacs just fine. I used for many years an Emacs on top of a compiler-only Common Lisp.

Reply on news.ycombinator.com