Hi, Neil Jerram <[EMAIL PROTECTED]> 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. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
