https://www.gitbook.io/book/landersbenjamin/llvm-implementing-a-language

Eduardo Costa writes:

Is there anything in the semantic of Python that makes it much more difficult to
implement a Python compiler than a Racket compiler?

Python is much more dynamic than Racket. As an illustration, look at a simple
operation: addition. In Racket,

(+ a b)

requires dispatching on the types of a and, from a finite (and small)
list of admitted candidates (fixnum, flonum, ...). Anything else is an error.

In Python,

a + b

is just syntactic sugar for

a.__add__(b)

which means (1) Look up the type of a, (2) look up 'add' in the
method dictionary of that type and its supertypes, (3) if not found,
look up 'radd' in the method dictionary of the type of b, (4) call
the resulting method. None of the intermediate lookups can be cached
because everything might be different the next time that operation is
executed: a and b can have different types, and the definition of
add for the types of a and b can have changed.

Konrad.

лан.

а тем временем на emacs-devel продолжаются споры насчет использования clang/llvm
для парсинга сорцов.

даже штульман там оторваную от контекста херню несет.
(кстати он, походу, подотстал от современных технологических событий в опенсорсе)

Палю ультрагодноту по интерпретаторам
The Structure and Performance of Efficient Interpreters
http://www.jilp.org/vol5/v5paper12.pdf