2014-01-26 Alex Shinn <[email protected]> > On Sun, Jan 26, 2014 at 6:58 PM, Marc Nieper-Wißkirchen < > [email protected]> wrote: > >> As Michael had brought up, even if you do this you need >>> to make things "work" for parameters, and I'd say also for >>> record types, though this doesn't necessarily imply the >>> values are eq? (much less the bindings being the same). >>> >> >> What do you mean by one *has* to make things work for parameters? If a >> library exporting a parameter is referenced twice and the standard allows >> the library to be loaded twice in this case, we may end up with two unequal >> parameter objects and the standard does not seem to forbid this, does it? >> So, in such an implementation things will simply not work for parameters, >> while such an implementation would be conforming to the standard. >> > > If parameterize didn't work across library boundaries, > it would make parameters _much_ less useful. They > are in fact mostly used for this purpose. > > On the other hand, just because they were not eqv? > would not prevent and implementation from making > the same parameter from different library instantiations > return and shadow the same values. > > Likewise, I think it would simply be broken for > define-record-type to create incompatible types, > even if the rtd were different. This is easier for the > compiler to work around since the rtd may be > syntax and thus not comparable wiht eqv? anyway. >
Yes, I agree with you that parameter objects and record type would be rather limited if they didn't work across library boundaries (when a library is loaded twice -- when it is just loaded once, no problem will ever arise). Maybe one could at least add to the small R7RS that parameter objects and record types work across different loadings of the same library (without, as you say, demanding that the bindings are eq? or eqv?)? Wouldn't this be rather easily to specify and already been implemented by all existing and likely implementations? > > I have come up with another thing that looks like an edge case to me. >> What about the following? >> >> (define-library (macro-library) >> (export macro keyword) >> (import (scheme base)) >> (begin >> (define-syntax macro >> (syntax-rules (keyword) >> ((_ keyword) 42))))) >> > > [I'm assuming you meant to define `keyword' in this library.] > Actually, I meant to define a syntax named `macro', which expects the literal `keyword' when used. > > (define-library (wrapper-library) >> (export wrapper) >> (import (scheme base) (macro-library)) >> (begin >> (define-syntax wrapper >> (syntax-rules () >> ((_) macro))))) >> >> (import (scheme base) (scheme write) (macro-library) (wrapper-library)) >> (display ((wrapper) keyword)) >> (newline) >> >> If I am not mistaken, this program won't portably display 42, will it? >> The identifier `keyword' in the main program is bound to a syntactic >> keyword coming from the loading of `macro-library' due to it being >> referenced by the main program, while the macro resulting from `(wrapper)' >> does expect a syntactic keyword coming from the loading of `macro-library' >> from `wrapper-library'. >> > > Perhaps I'm missing something, but it looks like this should > portably display 42. macro-library was imported by the main > program, so `keyword' refers to that binding. This is passed > through the wrapper to `macro', which sees the `keyword' > binding it expects. > But `wrapper' does not expand into the macro coming from the loading of `macro-library' into the main program, but into the macro coming from loading of `macro-library' into `wrapper-library'. If these two loadings are completely independent (as the standard seems to allow), `keyword' refers to the wrong binding. (As I am only a beginner in Scheme, I might have completely misunderstood something here, of course.) Marc > > -- > Alex > >
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
