This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: difficulty of writing translators


> > However, it would please me (if it's not too deadly to implement) to
> > see functions allowed to return set!-able references:
> 
> >    (set! (my-prop) 17)
> >    (my-prop)             => 17
> 
> Kawa supports this (for some primitive functions - I haven't decided
> yet how to define such functions in Scheme).
> 
> Note that having functions "return set!-able references" is
> probably not the way to do it, since we want a normal call (not in a
> set! context) to return plain value, not a reference.  Instead,
> we allow functions to have "attributes", and one attribute is a
> functions setter function.  Then we define:
> 	(set! (f . args) value)
> as being syntactic sugar for:
> 	((setter f) value . args)

Maybe I've been using perl too long :-) but I prefer to introduce an
"lvalue" object type and provide automatic lvalue->rvalue conversion
as the context demands.  Of course, this is all at the conceptual
level; real, compiled code wouldn't have to change for normal (rvalue)
calls.  (I guess we'd need a way to discover or assert the context our
function is/may be called in, to allow optimization.)

The function-attribute approach strikes me as less flexible and more
kludgey, especially if it adds runtime overhead.  But, maybe that's
because I don't understand.

-John

> 
> > (While I'm at it, I'd argue for (set! (array-ref a 6) 'zork) etc. as a
> > clean alternative to setf.)
> 
> The advantage of this design is that it is procedural, while
> setf is macro-based.  Hence setf only works for setter functions
> explicitly known (by name) at compile time, but setter works on
> procedure *values* at run-time, and is therefore much more in
> the spirit of Scheme.
> 
> 	--Per Bothner