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

[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

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

[`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

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

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

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

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

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

[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

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

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

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

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

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

[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

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

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

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

[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

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

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

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

[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*.

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

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

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

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

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

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'

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

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

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

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

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

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

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

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

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

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

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

[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

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

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