chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Functions with lots of parameters


From: Alejandro Forero Cuervo
Subject: Re: [Chicken-users] Functions with lots of parameters
Date: Sat, 21 Oct 2006 13:11:09 -0400
User-agent: Mutt/1.5.11

> > Fortunately, SRFI-39, Parameter objects, gets you what you want.
> 
> You are right, they seem to be a very good solution to the problem I
> described.  I had looked at them but I missed the parameterize macro,
> without which they didn't look very useful.
> 
> Thanks for pointing them out.  I will take a better look at them soon.

After looking parameter objects, I found two problems.  I don't think
they really "get me what I want".  They look like a very good
mechanism for a different situation.

The first is that they don't work well with lazy evaluation.  Suppose
you do "(define i (make-parameter 0))".  For what I want (which I
described in my previous mail), I would expect the following
expression to evaluate to 1:

    (force (parameterize ((i 1)) (delay (i))))

This matters a lot to me because I generate a lot of content in a lazy
fashion (eg. using srfi-40 streams with the functionality in the
html-stream or stream-ext eggs).  The moment you start using lazy
evaluation is the moment the parameterize form loses its effect.

The other, less important, thing I don't like for this usage of
parameter objects is that I have to reserve (ie. define) the name I
want for my parameters globally.  What if I just want to pass a
certain parameter to a set of 10 functions but all my other 990
functions don't use it?  I dislike that.  I should be able to just
locally bind the parameter to its value without having to use a
define.

That said, parameter objects do look very useful for a certain kind of
problem.  I just don't think the problem I'm tackling is the same.

I still think that an API similar to the one I proposed in my previous
message would be better.  I will probably implement it using a-lists
for the time being and experiment with it (obviously, a better
implementation would use "environments").  This wouldn't have the two
above problems.

I need to use something like this for my API for svnwiki extensions,
so (1) when I need to pass more information to some functions in the
extensions, I won't have to update all the currently existing
extensions to receive it; and (2) when one of the functions in svnwiki
that the extensions call starts requiring a new argument, the code in
currently existing extensions won't have to be updated.

Thanks for the suggestion, though.

Alejo.
http://azul.freaks-unidos.net/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]