optimization.  I included the second letter F.Y.I.
> >   But in order to achieve this, we need to support tail-recursion!
> >   Otherwise, we'll not have Scheme semantics.
> I don't understand how Guile handles tail-recursion.
Essentially by a jump back to `loop:' in SCM_CEVAL.
else which is properly tail-recursive makes use of this.
where @apply is a tail-recursive form.
(BTW, it is essential that the call/cc in your VM is tail-recursive.
> Why do applicable smobs suffer from it?
object layout (prurprprur etc, where "p" means protected word).
<program> which itself should be a subclass of <operator-class>.
> Do they optimize tail-recursion?
tail-recursive, then the operator itself is tail-recursive.
type of applicable GOOPS object for this.
lightweight.  We don't want an inefficient implementation at all.
> If Guile is supporting applicable smobs, I'll optimize them.
nice that the applicable smobs are so lightweight.
while, just replacing the internals of smobs.
potential no-trampoline direct call cases).
whether it was a good decision or not to add applicability to smobs.
- It is not a good solution to your problem, Keisuke.
But in order to achieve this, we need to support tail-recursion!
Otherwise, we'll not have Scheme semantics.
generally the case for applicable objects.
- Same goes for pwses (procedure-with-setters).
the current use of cclo.
+ Maybe, after all, applicability is a natural thing to support.
installed in the smob type.
call such a form a "trampoline".
performed once and for all in scm_set_smob_apply.
implement them as separate C functions.
appropriate for the function stored in the `apply' field.
the appropriate trampolines at type creation time.
`trampoline2', and we have eliminated one level of indirection.
Previous by thread: Making guardians a module?