Re: Emacs rewrite in a maintainable language

[Óscar Fuentes]

Eli Zaretskii <address@hidden> writes:

>> However, it is not absolutely necessary to have a global understanding
>> of the module that it is being translated to the new language. Depending
>> on the target language, a shallow knowledge can be sufficient.
>
> Only where the current code is self-contained, i.e. does not make any
> serious use of system APIs and is not heavily used by other parts of
> Emacs.
>
> If these conditions are false, then a fairly complete understanding is
> in fact necessary, otherwise we will have gobs of subtle bugs on our
> hands.

If the target language is ABI-compatible with C and hence has no
problems calling system APIs, there is no problem with translating a
function to that language and make it available to the
still-untranslated functions. The calling functions would remain
untouched until they get their turn to be translated.

> Also, depending on the target language, simple 1:1 translation might
> make no sense, because it could yield insufficient performance.  In
> those cases, the translator will have to reverse-engineer the (largely
> undocumented) requirements from the code, and then reimplement them
> using more efficient primitives of the target language.  That also
> requires a fairly good understanding of what the code does, and why.

Same as above for the performance and 1:1 translation.

> And these issues are just the tip of the iceberg.

I have experience doing this type of work (from C++) but the target
language was custom-made for making the process as easy as possible
while being advanced enough to warrant the effort. It was (is) a huge
success.

It would be not so easy with one of the stablished languages (Scheme,
for instance, has all the problems you mentioned and some more.)