[racket-dev] literal strings and numbers are now interned

Based on the docs, I think the idea was to support functions and syntax
forms that treat reader-introduced newline strings differently from
other strings. I can't come up with a good example myself.

It may also have been that the reader needed the distinction
internally, and so it made sense to expose it. (The internal
distinction can be implemented with a syntax property, though.)

I've removed the test and documentation for this feature.

At Tue, 22 Nov 2011 14:09:10 -0600, Robby Findler wrote:
> Why did the reader make this promise?
> 
> Robby
> 
> On Tue, Nov 22, 2011 at 1:50 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> > At Tue, 22 Nov 2011 09:18:30 -0700, Matthew Flatt wrote:
> >> Along the same lines, I think it's unlikely that good programs are
> >> affected by the `read' interning change
> >
> > Some Scribble tests failed in DrDr, because the Scribble reader
> > actually promises a distinct "\n" for literal newlines. There's no way
> > to make that work with syntax objects, since `datum->syntax' now always
> > interns strings.
> >
> > Any objection to removing that feature of the Scribble reader?
> >
> > The idea of a specific "\n" isn't compatible with separate compilation,
> > even prior to v5.2.0.4, in the sense that
> >
> >                      a.rkt
> >                      -----
> >  #lang at-exp racket
> >  (provide is-source-newline?)
> >  (define nl '@{
> >              })
> >  (define (is-source-newline? v) (eq? (first nl) v))
> >
> >                      b.rkt
> >                      -----
> >  #lang at-exp racket
> >  (require "a.rkt")
> >  (define nl '@{
> >              })
> >  (is-source-newline? (first nl))
> >
> > produces different results depending on whether "b.rkt" is run from
> > bytecode or from source.
> >
> > _________________________________________________
> >  For list-related administrative tasks:
> >  http://lists.racket-lang.org/listinfo/dev
> >