[EMAIL PROTECTED] (Ludovic Courtès) writes:
> [`current-reader' stuff...]
>
> Neil Jerram <[EMAIL PROTECTED]> writes:
>
>> This is in CVS now.
>
> I think there's another bit that should get in too:
Thanks, applied. In my view this is a bit separate from the use of
current-reader in loading file
[`current-reader' stuff...]
Neil Jerram <[EMAIL PROTECTED]> writes:
> This is in CVS now.
I think there's another bit that should get in too:
--- ../../guile-core--cvs/ice-9/boot-9.scm 2005-12-14 14:58:29.0
+0100
+++ boot-9.scm 2006-01-05 11:19:34.901389352 +0100
@@ -2540,7 +254
Marius Vollmer <[EMAIL PROTECTED]> writes:
> Neil Jerram <[EMAIL PROTECTED]> writes:
>
>> (Sudden confusion: Are fluids part of R5RS? If so, why do we need the
>> parameters SRFI? I guess I need to go and reread it.)
>
> No no no, fluids are not part of R5RS. I think we should implement
> the p
Neil Jerram <[EMAIL PROTECTED]> writes:
> (Sudden confusion: Are fluids part of R5RS? If so, why do we need the
> parameters SRFI? I guess I need to go and reread it.)
No no no, fluids are not part of R5RS. I think we should implement
the parameter SRFI in the core and start using it for thing
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Neil Jerram <[EMAIL PROTECTED]> writes:
>
>> For `current-reader' I think we should stick as we are.
>
> Then, should we go ahead and remove the `current-module' and
> `set-current-module' procedures in favor of `current-module' as a fluid?
> By not ex
On Fri, Dec 16, 2005 at 08:32:02AM +, Neil Jerram wrote:
> [EMAIL PROTECTED] (Tomas Zerolo) writes:
>
> > On Thu, Dec 15, 2005 at 07:47:13PM +, Neil Jerram wrote:
> >> [EMAIL PROTECTED] (Ludovic Courtès) writes:
> >>
> >> > OTOH, http://community.schemewiki.org/?variable-naming-convention
Neil Jerram <[EMAIL PROTECTED]> writes:
> For `current-reader' I think we should stick as we are.
Then, should we go ahead and remove the `current-module' and
`set-current-module' procedures in favor of `current-module' as a fluid?
By not exporting the fluid directly, my original patch kept away
[EMAIL PROTECTED] (Tomas Zerolo) writes:
> On Thu, Dec 15, 2005 at 07:47:13PM +, Neil Jerram wrote:
>> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>>
>> > OTOH, http://community.schemewiki.org/?variable-naming-convention
>> > suggests a different naming convention.
>>
>> Now that really is a
On Thu, Dec 15, 2005 at 07:47:13PM +, Neil Jerram wrote:
> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> > OTOH, http://community.schemewiki.org/?variable-naming-convention
> > suggests a different naming convention.
>
> Now that really is a horrible convention. Hmm, how can we best
> conf
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> OTOH, http://community.schemewiki.org/?variable-naming-convention
> suggests a different naming convention.
Now that really is a horrible convention. Hmm, how can we best
confuse someone coming to Scheme from another language for the first
time?
For
Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
> What other *star* names do we have? I can only think of *features*.
We don't have any other star name, but so far we did not export any
fluid, only getters and setters (e.g., `current-module'). The most
important thing is to be consistent with the
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Hi,
>
> Neil Jerram <[EMAIL PROTECTED]> writes:
>
>> This is in CVS now.
>
> Thanks Neil! BTW, what do you think of `*current-reader*' instead of
> `current-reader' as a fluid name?
What other *star* names do we have? I can only think of *features*.
Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
> This is in CVS now.
Thanks Neil! BTW, what do you think of `*current-reader*' instead of
`current-reader' as a fluid name? It would be more conventional and
consistent with the rest of Guile (e.g., `current-module' names a
procedure, not the fluid
Marius Vollmer <[EMAIL PROTECTED]> writes:
> Neil Jerram <[EMAIL PROTECTED]> writes:
>
>>> However, making the read procedure used by 'load' configurable can't
>>> hurt, I think.
>>
>> OK, thanks. I'll just wait a few days in case you or anyone else have
>> further comments. If not I'll commit t
Neil Jerram <[EMAIL PROTECTED]> writes:
>> However, making the read procedure used by 'load' configurable can't
>> hurt, I think.
>
> OK, thanks. I'll just wait a few days in case you or anyone else have
> further comments. If not I'll commit the patch as proposed.
Yes, please do. I still don'
Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
> Finally, although we might in theory be able to accommodate all
> possible reading variants as configurable options to the default read,
> in practice (i) this would be a pain for anyone wanting a variant that
> hasn't yet been incorporated into Guile
Marius Vollmer <[EMAIL PROTECTED]> writes:
> Neil Jerram <[EMAIL PROTECTED]> writes:
>
>> To be completely concrete about what I mean, here is a version of
>> your patch which I prefer (untested except by make check).
>
> Hmm. Your approach make 'load' configurable so that it can use
> different
Hi Marius,
Marius Vollmer <[EMAIL PROTECTED]> writes:
> Hmm. Your approach make 'load' configurable so that it can use
> different 'read' procedures. Wouldn't it be more natural to make
> 'read' configurable to parse different syntaxes?
[...]
> However, making the read procedure used by 'load
Neil Jerram <[EMAIL PROTECTED]> writes:
> To be completely concrete about what I mean, here is a version of
> your patch which I prefer (untested except by make check).
Hmm. Your approach make 'load' configurable so that it can use
different 'read' procedures. Wouldn't it be more natural to mak
Neil Jerram <[EMAIL PROTECTED]> writes:
> I still don't like the module option (no surprise there), and I think
> that the other parts of the patch could be made a bit simpler (which
> to my mind is a Good Thing). To be completely concrete about what I
> mean, here is a version of your patch whic
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Agreed, this approach is consistent with the current `load' stack.
>
> The patch below does what you described. I left the `#:reader' option
> to `define-module' as an alternative, higher-level approach to choosing
> an alternate reader.
>
> Please le
Hi Neil,
Thanks for your detailed analysis of the `load' procedure stack.
Neil Jerram <[EMAIL PROTECTED]> writes:
> So one possibility for adding custom reader support to all this is...
>
> - Don't put any current-reader framing code in primitive-load. In
> other words, don't reset current-re
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
Ludovic,
Just one remaining loose end from your previous email ...
> As for circular dependencies, I think there's nothing special here: the
> problem is the same as for any other binding.
Strictly no, there's nothing special, but in practice there is. This
is because modules normally consist m
[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
Neil Jerram <[EMAIL PROTECTED]> writes:
> If I'm understanding correctly, your argument rests on wanting to
> allow people to write a module like this:
>
> (define-module (shell utils)
> #:reader shell-reader
> #:use-module (shell reader)
> #:export (for))
>
> for () {
> beg=$1
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Hi,
>
> Let's not forget this thread (see <[EMAIL PROTECTED]>), it's s
> interesting! Was my message so convincing that you don't know what to
> answer? ;-)
I'll reply separately to some of the details in your other message,
but overall I don't
Hi,
Let's not forget this thread (see <[EMAIL PROTECTED]>), it's s
interesting! Was my message so convincing that you don't know what to
answer? ;-)
Thanks,
Ludovic.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/l
Hi,
Kevin Ryde <[EMAIL PROTECTED]> writes:
> I have doubts. Can you give more examples of when it might be used?
> Elisp syntax is probably not a good example, since elisp code wouldn't
> start with "define-module".
There are really two questions in your message. One is "do we really
need synt
Hi Neil,
Thanks for this detailed analysis!
Neil Jerram <[EMAIL PROTECTED]> writes:
> This is nice; but concerns about whether it fits with transformer are:
>
> - Transformer is specified with #:use-syntax followed by module name,
> which is a lot different from your syntax. I prefer your syn
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Could someone comment on this patch? (see <[EMAIL PROTECTED]>)
> It's actually quite trivial. :-)
I have doubts. Can you give more examples of when it might be used?
Elisp syntax is probably not a good example, since elisp code wouldn't
start with
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Hi,
>
> The patch below adds a `#:reader' keyword to `define-module' that allows
> modules to specify the reader that should be used to interpret them:
>
> (define-module (the-module)
> #:reader the-reader-for-my-favorite-syntax)
All looks good,
Hello,
Could someone comment on this patch? (see <[EMAIL PROTECTED]>)
It's actually quite trivial. :-)
Thanks in advance,
Ludovic.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
49 matches
Mail list logo
