Relaxed sharp reader, arbitrary multi-char dispatch macros

[tgbugs]

In brief, this is a suggestion to modify the reader to read all forms starting with # like symbols and then dispatch.

For example this would make it possible to read #hash ((1 . a)) as we currently read #hash((1 . a)).

There are a number of benefits including reducing the complexity of the reader and making the syntax more regular and predictable. In fact, I can't see any obvious drawbacks to this since aside from #% all forms that start with # dispatch or are a syntax error.

Given that I can't see any drawbacks I wanted to float the idea to see if there was something obvious that I am missing.

In a bit more detail.

The Racket reader makes extensive use of multi-char dispatch macros, macros that start with # and that must be followed by more than one subsequent character. Currently these are hardcoded in the reader and are not extensible. Further, they significantly increase the complexity of implementing new strict readers (that produces all the same errors at the same time) for the Racket language.

The change would simplify the reader and the syntax by converting the myriad of special cases in the reader into a single regular pattern by making # a multi-character dispatch macro by default instead of only a single character dispatch macro with special cases to handle specific additional forms.

Those familiar with Common Lisp may recognize this as similar to feature expressions
#+ asdf 'yes-asdf #- asdf 'no-asdf #+ (and i eat the next form) 'eek
or path syntax #p "/home/user".

Making this change would not immediately open the door to easy user-definable multi-char dispatch macros, but it would at least remove the major barrier that the current reader presents.

There are a number of additional details that can be filled in, but for now it seems like it might be more effective to implement a first pass and see what happens.

Thoughts?

[sorawee]

Multichar dispatch macro can be written as a library. See make-readtable++ as an example (but there's no documentation yet). I agree though that it would be nice to support that in the standard library.