I think a per-version switch would be reasonable. Another approach is to register a different checksum of the package for v6.2.1 and earlier releases, or create a shim for `make-syntax-introducer` that resides in its own package that has different implementations for different releases. To me, that's a cleaner approach, but it's also much more tedious than a version switch in the code, and I'd probably go with the version switch.
At Sun, 25 Oct 2015 22:23:52 -0400, Philip Blair wrote: > Hello all, > > I was hoping to get some mailing list assistance with this issue > involving adding R7RS's `#u8(...)' bytevector syntax to the readtable: > > The readtable extension culminates with the following: > (with-syntax ([(vals ...) (read-syntax src in)]) > (syntax (bytevector vals ...)) > > (Where `bytevector' is imported from r7rs/base) > > In Racket 6.2, this works fine. When running on 6.3 (HEAD), however, the > following error message is spat out: > r7rs/lang/r7rs-reader.rkt:39:13: bytevector: identifier's binding is > ambiguous > context.: > #(-458352200736611477 module) #(-458352200736611476 module > r7rs-reader 0) > #(1755194 module) #(1755195 module anonymous-module 0) > matching binding.: > #<module-path-index:(r7rs/base)> > #(1755194 module) #(1755195 module anonymous-module 0) > matching binding.: > #<module-path-index:((quote #%kernel))> > #(-458352200736611477 module) #(-458352200736611476 module > r7rs-reader 0) > in: bytevector > > This would seem to be a conflict with 6.3's new macro expander. Alexis > points out that a fix might be playing with a call to > `make-syntax-introducer', but we also realized that in 6.3 we will > likely need to include a #t argument to it. > What's the fix here? Do a per-version switch if we're running 6.3? Or is > there a cleaner solution? > > Regards, > - Philip Blair > > On 10/25/2015 5:18 PM, Alexis King wrote: > > I have built a very small, very incomplete implementation of R7RS in > > Racket. > You can install the “r7rs” package, or you can find it on GitHub here: > > https://github.com/lexi-lambda/racket-r7rs > > > > Most of the standard seems fairly straightforward, but there are two > questions I have. First of all, do there exist any R7RS libraries or programs > out there that could be used as test cases? The standard is not always 100% > clear, so having real code to test against would be ideal. This is probably > more productive than hopelessly guessing at the meaning behind the fuzzier > areas of the spec. > > > > Second of all, the only non-trivial problem is how to handle the R7RS > library system and how to integrate it with Racket’s modules. I’ve been > thinking about how to handle this, and I’m not sure which path I should take. > I think there are two different use-cases to having an R7RS implementation > inside of Racket, and each presents its own needs: > > > > 1. Maintaining full source compatibility with R7RS-compliant programs. > > 2. Implementing R7RS as a module language and requiring “#lang r7rs”. > > > > These are not necessarily mutually exclusive. It seems that Racket’s R5RS > support manages to provide both options by having the “r5rs” lang and module > language while also including a mode that works by evaluating expressions at > the top-level. The question becomes: what is the value behind an R7RS > implementation? I’ve mostly been implementing it as an exercise, and because > it’s irked me a little that we have R{5,6}RS implementations but not R7RS, > but > it probably isn’t very useful within the Racket ecosystem. > > > > With this context in mind, I ask those have been involved in the Racket > > R5RS > or R6RS support to share their experiences regarding these problems. Also, if > anyone is aware of usages of R7RS (or would be interested in R7RS support in > Racket, for whatever reason), I’d appreciate thoughts on that as well. > > > > If interest is low, I’ll probably just take option 2 for now and build a > mostly-compliant implementation that accommodates Racket in a few places, but > I do have some potential ideas for how to handle source compatibility. Still, > I’m sure I’d be tackling many of the same problems other people have already > considered, which is why I ask for information about any prior art. > > > > Thanks, > > Alexis > > > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
