Re: pure simple-closures

[Joe Neeman]

On Sat, 2006-10-21 at 00:02 +0200, Han-Wen Nienhuys wrote:
> Joe Neeman schreef:
> > Here is an attempt at making simple-closures pure-evaluatable. A
> > summary:
> > 
> > 1) move the conversion of non-pure-to-pure callbacks into C++ where it
> > is a bit easier to access and generalise it to support functions other
> > than just grob callbacks. The convention is that if a non-pure function
> 
> I'm not sure about this ; why not in Scheme?  (In general, we've had a 
> movement of stuff out of C++, not back to C++).

Mostly because at the time that I wrote it, I couldn't figure out how to
handle arbitrary length argument lists in scheme (the only way I
currently know is to build the list of arguments, cons in the function
and primitive-eval). On the other hand, guile's C API handles it easily.
Another advantage is that the function is a bit easier to call from C++
(and it is designed to be called entirely from C++). But I can rewrite
it in scheme if you prefer.

> 
> > takes (arg1 arg2 arg3) as arguments then the pure version will take
> > (arg1 start end arg2 arg3) as arguments. This order is so that we can
> > have arg3, for example, as an optional argument.
> 
> 
> > 2) adopt the convention that if any argument in a simple-closure is
> > UNDEFINED, the entire closure is UNDEFINED. This allows us to abort the
> > evaluation of a pure closure when there is an unpure function with no
> > pure equivalent. This requires changing the SCM_UNDEFINED in
> > grob-closure.cc to scm_from_int(0).
> 
> Isn't there another value you could use for that?
> 
> SCM_UNDEFINED is also used for callbacks with optional arguments (grep 
> for OPTARGS).

It seems that in every OPTARGS callback, the optional argument defaults
to zero. The only difference in changing grob-closure.cc is that
outside_slur_callback will now return zero instead of SCM_UNDEFINED in a
few cases. But then Grob::get_offset will interpret the SCM_UNDEFINED as
zero anyway.

In the context of [XY]-offset, a non-procedure, non-number value is
interpreted as zero. So I don't think there is any confusion in
interpreting them as zero in chain_offset_callback.