[Nickle] Mutual tail-recursion

Michel Salim michel.salim at gmail.com
Mon Feb 20 05:37:06 PST 2006

On 19/02/06, Keith Packard <keithp at keithp.com> wrote:
> On Sun, 2006-02-19 at 00:33 -0500, Michel Salim wrote:
> > My questions are, then:
> > - Is tail optimization of mutually-recursive functions planned?
> Planned and implemented; you were hit by run-time typechecking required
> by the use of poly values for oddp and evenp and the declared return
> types for their associated functions. If you use the form suggested by
> bart, or if you declare matching types for oddp and evenp, you get the
> memory usage pattern shown by bart.

Ah, OK. That's rather interesting - so an anonymous function
declaration bound to a variable (oddp = bool func (int n) {return
false;}; ) is not *exactly* identical as a type signature declaration
(bool oddp(int); ) ?

It seems that the run-time typechecking could be optimized (though
it's probably not worth the trouble): since in this case evenp and
oddp are called recursively every other function call, if the virtual
machine could detect that this is the case, then perhaps the type
checking could be deferred to the innermost evenp and oddp call? (this
gets more complicated in case there are >2 functions that call each
other, but for a function f, for every pair of (f, g_n) only the
innermost f needs to typecheck the return value of g_n.

> > Also, I'll probably propose Nickle for submission to Fedora Extras
> > (surprisingly, the original RPM spec was written by none other than
> > Mike Harris, Red Hat's X developer). Is there any runtime dependency
> > on the header files? I'm currently splitting the header files to a
> > -devel package.
> Sensible. These are used by external FFI libraries, like the one for the
> cairo graphics library, and shouldn't ever be needed by 'normal' users
> of nickle.
Thanks. I'll make not of this in the .spec file.

Michel Salim

More information about the Nickle mailing list