Neil Jerram <[EMAIL PROTECTED]> writes:
> Another detail that needs thought is whether any of the stack of load
> procedures defined in r4rs.scm and boot-9.scm (load-from-path, load
> and load-module) need enhancing to take a reader arg.
The stack of load procedures is...
primitive-load, define
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Adding an arg to scm_primitive_load (if that's the question here),
> would be very bad, since that function is described in the manual.
Good point. I think my statement stands that binary compatibility is
not required, but adding an arg to scm_primitive_l
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> Is binary compatibility a requirement? I presume this is aimed for
> 1.8, and presumably for 1.8 we'd bump libguile's major version,
> wouldn't we? (Getting into territory I don't really understand ...)
Adding an arg to scm_primitive_load (if that's th
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>> (`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 a
Hi,
Recently, Neil and I agreed that the reader setting should be thought of
as per-file instead of per-module. Happily, the second patch I sent
implements per-file readers (which may be set via `set-current-reader')
while maintaining the per-module reader mechanism (via `(define-module
(m) :read
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
>
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Hi Neil,
>
> Neil Jerram <[EMAIL PROTECTED]> writes:
>
>> 1. A way to say "change the reader to XXX for the rest of this file".
>
> I believe `set-current-reader' (introduced in the second patch) can do
> this job pretty well. What do you think?
Yes
Kevin Ryde <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>>
>> And what exactly would happen to
>> `primitive-load' (which is the one that triggered the call to
>> `my-zany-reader') when `my-zany-reader' returns?
>
> It sees eof, and stops. Or it sees the rest of the f
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> And what exactly would happen to
> `primitive-load' (which is the one that triggered the call to
> `my-zany-reader') when `my-zany-reader' returns?
It sees eof, and stops. Or it sees the rest of the file if the new
reader only takes an inlined middl
Hi,
[EMAIL PROTECTED] (Tomas Zerolo) writes:
> But don't we loose the possibility then to have ``embedded goo´´ (say,
> for example, something like a snippet of SQL in an otherwise Scheme
> file)? This would be, I think, one of the nifty uses for pluggable
> readers...
[It looks like something
On Thu, Oct 20, 2005 at 09:48:50AM +0200, Ludovic Court?s wrote:
> Hi Neil,
>
> Neil Jerram <[EMAIL PROTECTED]> writes:
>
> > I don't think it should be connected with modules, though. In my
> > view:
> >
> > - modules should be about identifier access and visibility (including
> > issues such
Hi,
Kevin Ryde <[EMAIL PROTECTED]> writes:
> I think that may be possible already using current-load-port.
> Something like
>
> (define-module (foo bar)
> ...)
> (my-zany-reader)
>
> where `my-zany-reader' reads and parses from current-load-port and
> does whatever with the re
Hi Neil,
Neil Jerram <[EMAIL PROTECTED]> writes:
> I don't think it should be connected with modules, though. In my
> view:
>
> - modules should be about identifier access and visibility (including
> issues such as possible separate compilation in future), and nothing
> else (and yes, this
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> 1. A way to say "change the reader to XXX for the rest of this file".
I think that may be possible already using current-load-port.
Something like
(define-module (foo bar)
...)
(my-zany-reader)
where `my-zany-reader' reads and
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Neil Jerram <[EMAIL PROTECTED]> writes:
>
>> Thanks for taking my considerations into account and producing this
>> update. My gut feel is that I do like this new patch better, but I'd
>> like to think about it more. I also need to go back and finish
Hi Neil,
Neil Jerram <[EMAIL PROTECTED]> writes:
> Thanks for taking my considerations into account and producing this
> update. My gut feel is that I do like this new patch better, but I'd
> like to think about it more. I also need to go back and finish my
> draft reply to your previous email
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Following your concern (I mean the performance concern, not the
> "marginal benefit" concern), I thought of another way to achieve the
> same thing, a bit more generic and slightly better performance-wise
> (patch attached). [...]
Thanks for taking my
Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
> And to get this marginal benefit we have to add a module option and
> some code which will slow down normal operation. Not noticeably
> perhaps, but it all adds up.
Following your concern (I mean the performance concern, not the
"marginal benefit" c
18 matches
Mail list logo
