It is now available here:
https://racket.discourse.group/t/extending-the-reader-to-support-kawa-like-treatment-of-colons/3676
sobota, 5 kwietnia 2025 o 11:55:55 UTC+2 [email protected] napisał(a):
> I just read that this is no longer a place for Racket discussions, so I'm
> moving the question to https://racket.discourse.group/
>
> sobota, 5 kwietnia 2025 o 11:53:06 UTC+2 [email protected] napisał(a):
>
>> I've had an idea to implement a #lang that would provide some syntactic
>> extensions akin to those provided by the Kawa Scheme, particularly with
>> regard to the usage of a colon.
>>
>> In particular, in Kawa:
>> - the sequence "x:" will be read as a keyword equivalent to #:x
>> - the sequence "a:b" will be read as ($lookup$ a `b)
>> - likewise, the sequence "a:b:c" will be read as ($lookup$ ($lookup$ a
>> `b) `c) and so on
>> - if two colons appear in a row, as in, say "a::b", they will be treated
>> as a separate token, i.e.
>>
>> (call-with-input-string "a::b" read)
>> will return the symbol a
>>
>> and
>> (call-with-input-string "(a::b)" read)
>> will return the list of three tokens, (a :: b)
>>
>> Kawa treats each pair of colons as a separate token, so
>>
>> (call-with-input-string "(:::)" read)
>> returns the list (:: :: :: :)
>> but I would actually prefer to treat a sequence of two or more colons as
>> a single token.
>>
>> In either case, I wonder if someone could guide me how to do this,
>> preferably using Racket's internal machinery that's already out there.
>>
>> I found that atoms in Racket are being read by the
>> "read-symbol-or-number?" procedure from expander/read/symbol-or-number.rkt,
>> but I don't think it is sufficiently tweakable - in particular because if I
>> read a colon, I might have to unread it if I can peek another colon.
>>
>> Is there any simple way out of this situation, or do I have to actually
>> implement a Lisp reader from scratch? (I'd be OK with that, because I
>> already wrote a reader in Kawa that I think I could adapt, but then I'd
>> probably have some questions about dealing with syntax objects. The
>> alternative would be to modify Racket's sources to make the reader API more
>> flexible, e.g. allowing to parameterize expander's "read" with the
>> "read-symbol-or-number" function, which I think would be more in the spirit
>> of Racket, but it would probably also take more time to downstream)
>>
>> Thanks in advance,
>> Panicz
>>
>
--
This group is deprecated and retained as an archive.
Racket discussions have moved to the Racket Discourse at
https://racket.discourse.group/ .
---
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 [email protected].
---
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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/racket-users/bb163934-0bbe-42c7-8776-f9d60f8ac4ecn%40googlegroups.com.
