Re: [PATCH] Per-module reader, take #2
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
Re: [PATCH] `any' and `every' in `(oop goops util)'
Kevin Ryde <[EMAIL PROTECTED]> writes: > When using (oop goops) ? I'm not sure (oop goops util) is meant to be > used outside the goops implementation. And what difference does/would it make? > (There's a non-tail recursive mapappend which could probably benefit > from srfi-1 append-map too, incidentally.) Right. But this requires modifying all the users of `(oop goops util)'. Thanks, Ludovic. ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: [PATCH] SRFI-34, SRFI-60 and core bindings
Kevin Ryde <[EMAIL PROTECTED]> writes: > I don't really want to silently replace the core bit-count, the > srfi-60 one is completely different. It's pretty annoying to get a > warning or have to use #:renamer, but I don't know a better way. `#:replace' _is_ this better way: it does _not_ override the core binding, unlike `(use-modules (srfi srfi-60))' (with no renamer) in the current state. What it does is that is replaces this binding only within the module user: the binding replacement is confined. guile> (define-module (chbouib)) # guile> (use-modules (srfi srfi-60)) guile> (bit-count 2) 1 guile> (set-current-module (resolve-module '(guile-user))) # guile> (bit-count #f (make-uniform-vector 8 #t #f)) 8 This is exactly the behavior users may expect. > (Incidentally, `current-time' from srfi-19 is also a problem.) Right, it also annoyed me in the past. If we agree that `#:replace' is the right thing, then we can do the same for this one. Ludovic. ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
[PATCH] Augmenting the doc of `define-module'
Hi, It occurred to me that `define-module' is only partially documented, in particular, `#:re-export', `#:replace' and `#:duplicates' are not documented at all. I tried to do my best to document them accurately but note that (i) I'm not a native English speaker and (ii) from the discussion we've had with Kevin, it seems that we disagree on the use of `#:replace'. In particular, I used `(srfi srfi-19)' as an example of when to use `#:replace' and Kevin may disagree with that. But, well, let's debate this question. ;-) Thanks, Ludovic. 2005-10-21 Ludovic Courtès <[EMAIL PROTECTED]> * doc/ref/api-modules.texi (Creating Guile Modules): Documented `#:re-export', `#:export-syntax', `#:re-export-syntax', `#:replace' and `#:duplicates'. --- orig/doc/ref/api-modules.texi +++ mod/doc/ref/api-modules.texi @@ -240,6 +240,7 @@ module to be accessed, but also selects bindings from it and renames them to suit the current module's needs. For example: [EMAIL PROTECTED] binding renamer @smalllisp (use-modules ((ice-9 popen) :select ((open-pipe . pipe-open) close-pipe) @@ -305,6 +306,7 @@ @var{spec} can also be of the form: [EMAIL PROTECTED] binding renamer @smalllisp (MODULE-NAME [:select SELECTION] [:renamer RENAMER]) @end smalllisp @@ -419,9 +421,152 @@ @item #:export @var{list} @cindex export -Export all identifiers in @var{list}, which must be a list of symbols. +Export all identifiers in @var{list} which must be a list of symbols. This is equivalent to @code{(export @var{list})} in the module body. [EMAIL PROTECTED] #:re-export @var{list} [EMAIL PROTECTED] re-export +Re-export all identifiers in @var{list} which must be a list of +symbols. The symbols in @var{list} must be imported by the current +module from other modules. This is equivalent to @code{(re-export [EMAIL PROTECTED])} in the module body. + [EMAIL PROTECTED] #:export-syntax @var{list} [EMAIL PROTECTED] export-syntax +Export all identifiers in @var{list} which must be a list of symbols. +The identifiers in @var{list} must refer to macros (@pxref{Macros}) +defined in the current module. This is equivalent to [EMAIL PROTECTED](export-syntax @var{list})} in the module body. + [EMAIL PROTECTED] #:re-export-syntax @var{list} [EMAIL PROTECTED] re-export-syntax +Re-export all identifiers in @var{list} which must be a list of +symbols. The symbols in @var{list} must refer to macros imported by +the current module from other modules. This is equivalent to [EMAIL PROTECTED](re-export-syntax @var{list})} in the module body. + [EMAIL PROTECTED] #:replace @var{list} [EMAIL PROTECTED] replace [EMAIL PROTECTED] replacing binding [EMAIL PROTECTED] overriding binding [EMAIL PROTECTED] duplicate binding +Export all identifiers in @var{list} (a list of symbols) and mark them +as @dfn{replacing bindings}. In the module user's name space, this +will have the effect of replacing any binding with the same name that +is not ``replacing'' itself. + +This is useful for modules that export bindings that have the same +name as core bindings. @code{#:replace}, in a sense, lets Guile know +that the module @emph{purposefully} replaces a core binding. It is +important to note, however, that this binding replacement is confined +to the name space of the module user. In other words, the value of the +core binding in question remains unchanged for other modules. + [EMAIL PROTECTED] core binding [EMAIL PROTECTED] current-time +One example of this is @code{(srfi srfi-19)} which exports [EMAIL PROTECTED] (@pxref{SRFI-19 Time}), thus overriding the core +binding with the same name (@pxref{Time}). If @code{(srfi srfi-19)} +was defined as follows: + [EMAIL PROTECTED] +(define-module (srfi srfi-19) + #:export (current-time ...)) [EMAIL PROTECTED] smalllisp + +Then, by default, the user module that performs @code{(use-modules +(srfi srfi-19))} will get SRFI-19's version of @code{current-time}. +However, Guile will also issue a warning about the core binding being +replaced potentially unwillingly: + [EMAIL PROTECTED] +guile> (use-modules (srfi srfi-19)) +WARNING: (guile-user): imported module (srfi srfi-19) overrides core binding `current-time' [EMAIL PROTECTED] smallexample + [EMAIL PROTECTED]:replace} is a way to fix this issue by making it explicit that +the binding-providing module does want to override a core binding: + [EMAIL PROTECTED] +(define-module (srfi srfi-19) + #:export (...) + #:replace (current-time)) [EMAIL PROTECTED] smalllisp + [EMAIL PROTECTED] binding renamer +In this case, this can be considered harmless since the user of this +module expects @code{current-time} to refer to SRFI-19's +implementation, and not to the Guile built-in version. However, note +that this does not preclude the use of both versions of the binding +within a given module: this can be done using the @code{#:renamer} +option of @code{use-modules} (@pxref{Using Guile Modules}). + +The @code{#:duplicates} option (bel
Re: [PATCH] SRFI-34, SRFI-60 and core bindings
[EMAIL PROTECTED] (Ludovic Courtès) writes: > > it does _not_ override the core > binding, unlike `(use-modules (srfi srfi-60))' (with no renamer) in the > current state. What it does is that is replaces this binding only > within the module user: the binding replacement is confined. Yes, I'm talking about the module user too, the module user loses some core bindings. > This is exactly the behavior users may expect. If you don't know about the clashes/replacements then you're likely to be unpleasantly surprised to see core stuff suddenly move under your feet. But a way to acknowledge that in the use-modules might be nice. An option for srfi-60 bit-count would be to extend the core, since the argument types are different in the two forms. Such cases have been using #:replace, eg. srfi-17 and srfi-39. ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: [PATCH] `any' and `every' in `(oop goops util)'
[EMAIL PROTECTED] (Ludovic Courtès) writes: > > Kevin Ryde <[EMAIL PROTECTED]> writes: > >> When using (oop goops) ? I'm not sure (oop goops util) is meant to be >> used outside the goops implementation. > > And what difference does/would it make? If you're not supposed to use it then any warnings it provokes when you do aren't a big deal :). Now that srfi-1 has a lot more C code it's probably worth using for performance. ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel