[racket] Why isn't at-exp the default?

Although the `#lang` mechanism doesn't have a built-in mechanism for
options, a particular language can support them. For example, you might
define `pollen` so that

 #lang pollen [char]

sets the command character when [char] appears after `pollen` and
exactly one space.

The `scribble/sigplan` language support options in a similar way. Its
options must be specified on the `#lang` line, but they're implemented
more in the expansion level than the reader level.

It would be good to have conventions for parsing options --- and a
library to implement those conventions --- but I'm not sure we have
enough examples to know the right conventions.

Meanwhile, building a syntax for options into `#lang` would mean
inventing a sublanguage that we're stuck with forever, because the
syntax of `#lang` itself is the one thing we can't change. Also, we
want that syntax to look as natural as possible for any language that
we build now or in the future, and we've tried to achieve that by
keeping `#lang` minimal.

At Sat, 16 Nov 2013 18:17:29 -0800, Matthew Butterick wrote:
> Somewhat relatedly, have you ever considered making it possible for #lang 
> languages to expose configuration parameters in the #lang line?
> 
> For instance, at-expressions can be marked with any unicode character. To use 
> this functionality, however, one needs to set up a baby #lang that uses 
> make-at-reader with the #:command-char parameter. This is what I did with my 
> Pollen language so I could use the ◊ character for at-expressions by saying
> 
> #lang pollen
> 
> But someone who uses Pollen may not want that character. So in the interests 
> of making easy language customizations easy, they might prefer to be able to 
> do something like
> 
> #lang (pollen #:command-char [char])
> 
> 
> 
> 
> 	
> On Nov 16, 2013, at 5:27 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> 
> > Back when we introduced `#lang racket`, we could have included
> > @-notation by default, but I think we were focused on making `#lang
> > racket` a small shift from `#lang scheme`. And `#lang scheme` was too
> > long ago.
> > 
> > Backward compatibility rules out adding @-notation to `#lang racket`,
> > but I agree that it would be better to include @-notation in future
> > languages.
> > 
> > At Wed, 13 Nov 2013 22:06:11 -0500, Greg Hendershott wrote:
> >> Lately my appreciation for `#lang at-exp ...` has grown. I've even
> >> started to write things like:
> >> 
> >> (printf "The ~a and the ~a and the ~a\n" x y z)
> >> 
> >> instead as:
> >> 
> >> (displayln @~a{The @x and the @y and the @z})
> >> 
> >> When there's more than one or two items, this is a lot easier to write
> >> (and change later). No more need to keep two lists in the same order.
> >> 
> >> Although I'm aware Ruby has something similar, I haven't pined for it.
> >> It's just one example. Another is multi-line text fragments. In
> >> general:
> >> 
> >> (define x @~a{One
> >>              Two
> >>              Three})
> >> 
> >> is waaaay nicer -- and editor indent friendly -- than reader "here"
> >> strings like:
> >> 
> >> (define x #<<EOF
> >> One
> >> Two
> >> Three
> >> EOF
> >> )
> >> 
> >> And there are more examples.
> >> 
> >> I'm not complaining about the need to type "at-exp".
> >> 
> >> But my question is, why hasn't at-exp at some point been made the
> >> default reader for Racket?
> >> 
> >> Is it solely due to backward compatibility, the risk that existing
> >> programs use @ in identifiers, like `(define @var)`?
> >> 
> >> Or is there some hidden cost or additional gotcha I should keep in mind?
> >> ____________________
> >>  Racket Users list:
> >>  http://lists.racket-lang.org/users
> > ____________________
> >  Racket Users list:
> >  http://lists.racket-lang.org/users
> 
> 
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users