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 <mfl...@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
> >
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
