[Top][All Lists]

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

Re: [Chicken-hackers] [PATCH] Moving some things from library.scm and ev

From: Peter Bex
Subject: Re: [Chicken-hackers] [PATCH] Moving some things from library.scm and eval.scm to internal.scm
Date: Mon, 5 Jun 2017 12:11:05 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

On Mon, Jun 05, 2017 at 05:53:32PM +1200, Evan Hanson wrote:
> Hey Peter,
> On 2017-06-04 13:53, Peter Bex wrote:
> > Regarding time specifically, there are not many stand-alone programs
> > that will use this macro, I think.  It's more a thing for benchmarks
> > and such, so I'm not even sure it must be part of library.  It probably
> > was in there because the macro was in the "chicken" module.  There's a
> > lot of stuff that's much less optional than "time" (as in, used by day
> > to day programs) that lives in other units like file.scm.
> True. I do think the support code for `time` would be good to move, if
> we can sort out the dependency issues.

What exactly are the dependency issues you're concerned about?  AFAIK
there's a simple rule: if you use the "time" macro, you'll need to
include internal.scm into your program.  That's pretty straightforward,
IMHO.  Besides, you also need to know that you need to include, say,
extras.scm when using "randomize" from (chicken random).

The only difference here is that it's the _expansion_ that requires the
unit rather than the direct call.  Is that the issue?

Maybe we can fix the situation by adding something to the manual to
indicate which units map to which modules.  This would solve this
problem more generally, including the "randomize" example I gave above.

We still haven't decided on which module "time" should go into, so maybe
that's part of the problem (it's missing completely from c-l-r).

> It's also probably possible to
> make the compiler generate code to load units as they're required by
> macro expansions, but that's sure to have other implications so I'm not
> super keen to go there right now.

I agree that would be nice but is a bit too complex right now.  Maybe
we'll take a look at this for 5.1 or 5.2.


Attachment: signature.asc
Description: Digital signature

reply via email to

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