Re: named-let

[Stefan Monnier]

>> With the advent of the native-compiler, "all implementations" is even
>> harder to reach, since it means, interpreter, byte-code, and native code.
> Well as I mentioned the native compiler is already capable of that if
> asked, but in general whichever optimization is done by the
> byte-compiler is picked by the native compiler cause currently the
> compilation input is LAP.  So I'm not really sure this is adding much
> complexity from this POV.

All the patches I've seen so far do it in the bytecode interpreter,
without changing the bytecode itself.

Note that it also depends on what we mean by TCO.
To me, the "real TCO" is like what Scheme does (so it's not limited to
recursive functions).  I don't know how easy it is to implement for
native-comp.  Maybe GCC magically does it for us?

[ TCO has also undesirable interactions with debugging/tracing, but
  I think that would be a secondary concern which should be
  manageable somehow.  ]

> As a side note I'd be surprised if interpreters in CL implementation are
> supporting TRE, I guess the interpreter is typically used only for debug
> or bootstrap therefore should be not very important.  Am I wrong?

I wouldn't know.  But at least for ELisp , it was perceived that
the plain interpreter is important enough that if it doesn't support TCO
then we can't write code which relies on TCO, in which case implementing
TCO in the bytecode interpreter is not very useful.

[ That's part of the reason why I implemented this limited TCO as
  a macro: it works the same for bytecode as for any other mode of
  execution so it can really be considered part of the guaranteed
  semantics rather than a mere optimization.  ]


-- Stefan