Or another hack: put the parameter's value in teh filesystem and use
parameter guards to fish it out of there.
This would be useful only if you consider it temporary tho. :)
Robby
On Wed, Dec 7, 2016 at 2:09 PM, Matthew Flatt wrote:
> At Wed, 7 Dec 2016 12:01:24 -0800 (PST), Dan Liebgold wrote
At Wed, 7 Dec 2016 12:01:24 -0800 (PST), Dan Liebgold wrote:
> On Tuesday, December 6, 2016 at 5:00:47 PM UTC-8, Robby Findler wrote:
> >
> > Perhaps there is another way to achieve the effect you want in a way
> > that is more friendly to creating .zo files?
> >
>
> Yes, this is the crux of the
On Tuesday, December 6, 2016 at 5:00:47 PM UTC-8, Robby Findler wrote:
>
> Perhaps there is another way to achieve the effect you want in a way
> that is more friendly to creating .zo files?
>
Yes, this is the crux of the issue. In my case I have a system that deals with
modules that may or may
My initial reaction would be to explicitly split “module.rkt” into two pieces:
— its compile-time code especially an exported parameter a
— its run-time code, which uses the same parameter
Your client module could then require each piece at the correct phase.
This also ought to work with the
My initial reaction is that that's a bad idea because it means that
you're not cooperating separate compilation when you do things like
that. That is, if module.rkt's compilation were affected by the
parameter `a`, then if there were a .zo file (because someone did
'raco setup' or 'raco make' or th
5 matches
Mail list logo
