Yes, a global table of all existing keywords are needed.
I would do something along the lines of:
#lang racket
(struct Keyword (string))
(define global-keyword-hash (make-hash))
; keyword : string -> keyword
(define (keyword s)
(define k (hash-ref global-keyword-hash s #f))
(or k
(let ()
(define k (Keyword s))
(hash-set! global-keyword-hash s k)
k)))
(eq? (keyword "a") (keyword "a"))
(eq? (keyword "a") (keyword "b"))
(eq? (keyword "b") (keyword "b"))
Den tir. 23. apr. 2019 kl. 15.22 skrev zeRusski <vladilen.ko...@gmail.com>:
> One thought that only just occurred to me is that we certainly want to
> allow creating kws dynamically, so a piece of code may generate some. IIUC
> this means it can no longer be a purely reader-based feature. Either reader
> and runtime have to communicate the global table somehow or the entire
> thing belongs at runtime save for actually parsing text. I wonder how
> taxing such implementation becomes. I feel like Racket keywords and
> interned symbols may have some lower language support that I can't access?
>
> --
> 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.
>
--
--
Jens Axel Søgaard
--
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.
