Re: Elisp flet construct

[Daniel Kraft]

Andy Wingo wrote:
> > in the %nil thread a suggestion was brought up to support the `flet'
> > construct (and `flet*' as well, if we choose to do so at all, I favour)
> > in Guile's upcoming elisp implementation that behaves just like a let
> > for function-slot bindings, enabling dynamic scoping for them.
> >
> > It is no "official" elisp construct, but according to what I heard
> > there, can be useful at some times (I guess the use is mainly to locally
> > alter bindings of standard functions for some code executed without a
> > risk of permanently messing things up).  So I don't know how you regard
> > addition of "extensions"...?
>
> Personally? I think what's out there would be the priority, but
> extensions are fun too :)

Ok, so then I'll implement flet :)  It should be nearly trivial, because 
I can just seperate the existing let/let* code out and use it for 
functions, also.

> > * If we do not implement flet, we can implement the function-slots
> > without indirection via fluids but rather use the Guile symbol bindings
> > directly.  This is for sure a simplification especially performance
> > wise, but I can't say how much it really affects.  Most bindings in use
> > are, I guess, variables, so we save the fluid-references only in a
> > fraction of cases.
>
> > From a Guile perspective, I would like to avoid the use of
> symbol-function. It seems that the module and variable hacks we
> discussed before would be sufficiently fast. I could be wrong of course.

Hm... I'm not sure if we understand each other correctly; what do you 
mean with symbol-function here?  My point was that at the moment, we 
store in the respective module under the variable's name a fluid, and 
then use this fluid's value when calling the function:

(define foobar (make-fluid))
(fluid-set! foobar (lambda (a b) (+ a b)))
...
((fluid-ref foobar) 1 2)

If we don't want to have flet and dynamic bindings for functions as a 
consequence, we can get rid of the fluids and do just (as we would in 
Scheme):

(define foobar (lambda (a b) (+ a b)))
...
(foobar 1 2)

Which would be simpler (at runtime at least) and maybe faster, although 
I don't think the difference is significant.  But let's just add flet 
and keep using fluids ;)

Daniel

--
Done:  Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri