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

[Evan Hanson]

On 2017-06-05 12:11, Peter Bex wrote:
> On Mon, Jun 05, 2017 at 05:53:32PM +1200, Evan Hanson wrote:
> > 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?

Basically, yes. In this case the compiler won't take care of loading the
internal unit for you, so you're left with an unmet dependency unless
you know to load that unit explicitly, or happen to do so incidentally.

Currently, things are in a good state because: you can't use `time`
until you import "chicken", importing "chicken" loads the library unit,
the library unit provides the support procedures needed by `time`, and
everything's groovy. By moving the support procedures out of library
this fails to be the case, so from my point of view it's a regression.

Additionally, this is a problem that won't even be caught at compile
time. You'll just end up with an unbound value in the expansion of
`time`, resulting in with segfaults and the like.

> 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.

Yeah, I do think we should include that information in the manual. We
can put it in a little note in the corner of each module page or
something, similarly to how rubydoc.info has a "Defined in: foo.rb"
section.

However, if we end up putting macro support code in a different unit
than that loaded by the module exporting the macro itself, do we note
the runtime or compile-time unit? Both? I really think it's simpler to
just keep these things together for now, until we can add some smarts to
the compiler.

> 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).

True... Apparently I put it where it is, though I don't remember doing
that so I probably just did what seemed right at the time (heh). It's
not at all similar to the other procedures in that module, but it is
clearly time-related. Are there any other benchmarking-related things
that could make a happy family together? Doesn't really look like it,
but maybe that's not a problem... Put it in extras? Eggify it? Leave it
where it is? Any other hackers have thoughts about this?

Cheers,

Evan

signature.asc
Description: PGP signature