reason for "eval" in net-barchart.scm

Robert Graham Merkel rgmerk@mira.net
Thu, 27 Sep 2001 16:47:55 +1000


On Thu, 27 Sep 2001 15:38:34 Rob Browning wrote:
> Robert Graham Merkel <rgmerk@mira.net> writes:
> 
> > The value returned from an option generated by this function is a
> symbol 
> > corresponding to the "deltas" in src/app-utils/date-utilities.scm - not
> the
> > actual delta structure itself.
> >
> > Hence, the use of eval to get the structure from the symbol.
> >
> > I dunno, how do you want to fix this?
> 
> Hmm.  If we need the eval, that's fine, but from what I've seen, I
> think I'd prefer an alist defined after all the delta functions:
> 
> (define foo-deltas
>   `((SecDelta . ,SecDelta)
>     (DayDelta . ,DayDelta)
>     ...))
> 
> and then instead of eval, we can use an assq-ref on the alist.  We
> might also want to put a comment wherever the items are added to the
> multichoice indicating that you need to update the alist too...
> 

That's probably a good solution.

> Note that if we do leave the eval, I'll need to figure out what works
> across the various guiles.  Before 1.6, eval took one arg, but now it
> takes two to conform with r5rs.  I believe that primitive-eval retains
> the old semantics.
> 

Firstly, I think the first solution is better, but if we needed an 
eval that worked across guile versions, couldn't we define a 
"gnc-eval" that tested the guile version number and DTRT (possibly
with some caveats as to what you were allowed to eval)?


-- 
------------------------------------------------------------
Robert Merkel	                           rgmerk@mira.net

Go You Big Red Fire Engine
-- Unknown Audience Member at Adam Hills standup gig
------------------------------------------------------------