Re: [PATCH] Per-module reader, take #2

[Ludovic Courtès]

Hi,

Neil Jerram <address@hidden> writes:

> Yes, indeed.  Just one detail: I suspect that
>
>   scm_frame_fluid(the_reader, SCM_BOOL_F);
>
> might be less surprising than
>
>   scm_frame_fluid(the_reader, CURRENT_READER());
>
> at the start of primitive-load.  Given how Guile works already, I
> think it's more natural for files to be independent of each other,
> reader-wise, and that we add something new that people can use to get
> reader inheritance when they want that.

Right.  I did hesitate between the two solutions in fact.  I was
thinking that one might want to purposefully call `set-current-reader'
just before invoking `primitive-load'.  But in fact, for that purpose,
we'd better provide a `load-with-reader' procedure as you said.  And it
is true that having `current-reader' default to `#f' would keep away
users from experiencing weird unexpected behavior.

> (`include' feels like a nice name to me.  It could be implemented
> using an optional reader arg to load/primitive-load, something like:
>
>   (include FILE) -> (load FILE (current-reader))

Maybe `load-with-reader' is more explicit, while not as nice?  ;-)

> And then primitive-load would call scm_frame_fluid with the optional
> arg if supplied, SCM_BOOL_F otherwise.)

In fact, in order to retain binary compatibility, we'd have to provide
another function which would essentially contain the same code as
`primitive-load' except for the optional reader argument and the default
value of the `current-reader' fluid.

I'll try to have an attempt at implementing it today.

Thanks,
Ludovic.