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.
