I think your initial instinct was right: if you want to change the lexical structure of your language, the right place to start is in the reader. The reader is the part of Racket’s language facilities that interprets the structure of sequences of characters, and your notion of dotted identifiers clearly treats the two components as distinct lexemes. Any attempts to reuse the unmodified Racket reader but treat certain shapes of identifiers in a particular way will likely be hopeless, as those lexemes have been fused.
That said, modifying the reader is usually only part one, a jumping-off point. While the reader interprets the lexical structure of your language, and it weakly collects the results into some sort of tree, it doesn’t say anything about what that tree means. When the Racket reader sees (define x 1), it reads a list containing two symbols and a number, not a definition. It is the module language that determines which bindings are in scope and imbues those identifiers with meaning. In this sense, you likely can’t get away with just modifying the reader: you need to modify both the reader and the module language. It isn’t really clear to me what you want (define a.b 3) to do—whether it should signal an error or do some useful thing—but it seems to me like you may wish to wrap various forms from racket/base in your own macros that handle the dotted expressions produced by your reader. (Theoretically, Racket could do some things differently so that you’d have to do less work to at least render nonsense like the above illegal, such as provide an extensible syntax object language. This would make reader extensions more watertight abstractions. For better or for worse, however, this is not the way Racket currently works, and this shows in various ways even in #lang racket… such as, for example, the fact that (+ 1 . (2 3)) is a totally legal Racket expression that evaluates to 6.) Alexis > On Dec 10, 2018, at 17:31, Ryan Kramer <default.kra...@gmail.com> wrote: > > It turns out expanding the syntax object isn't the right approach. It seems > easy enough for defining values and simple procedures, but as soon as you > consider optional arguments and keyword arguments, the resulting expansion > gets too complicated to analyze. > > I don't see an easy way to do this, unless there is some hook that I am > unaware of. For example, applications get piped through #%app and unbound > identifiers get piped through #%top. If there is #%something that new > identifiers get piped through, that would be what I want. But I don't think > it exists. > > So my next attempt will be to go back to the reader, and make it so that > certain characters (like dot and +) are always treated as individual tokens. > Meaning that (define foo+bar 42) will come out of the reader as (define foo + > bar 42). The resulting error message should be good enough for my purposes, I > think. -- 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.
