Yeah: I think that it is safe to say at this point that pollen doesn't need to change. Either read-language's docs (and various places in DrRacket and libraries) need to change or read-language needs to change and either way pollen will work afterwards.
My guess is that your language is the only one that doesn't define a get-info function itself but I can't check that theory right now. You can probably make pollen work now by supplying a get-info proc that always returns the default value. (See the third and subsequent paragraphs here: http://docs.racket-lang.org/reference/Reading.html?q=read-language#%28def._%28%28quote._~23~25kernel%29._read-language%29%29 ). Robby On Monday, July 21, 2014, Matthew Butterick <m...@mbtype.com> wrote: > > It appears that read-language can return #f and what DrRacket does in > > that case appears to be what you're seeing. Is that what you're > > getting? > > Your theory seems correct. Yes, Pollen is the only #lang returning #f for > read-language, e.g.: > > #lang racket/base > (map > (λ(lang) (read-language (open-input-string (format "#lang ~a" lang)))) > '(racket racket/base scratchy scribble/manual scribble/text rackjure > pollen)) > > '(#<procedure:language-info> > #<procedure:language-info> > #<procedure:...atchy/reader.rkt:26:2> > #<procedure:language-info> > #<procedure:language-info> > #<procedure:language-info> > #f) > > > Moreover, if I use your main.rkt, it triggers the same problem in DrRacket > (#lang line is red, no toolbar buttons) > > But beyond the issue of whether the docs or DrRacket is doing the right > thing with the #f value, I'm unclear why Pollen is returning #f for > read-language. One possibly unorthodox thing I'm doing here is that my > #lang files rely on macro expansion. For instance, here's Pollen's main.rkt: > > > #lang racket/base > (require pollen/main-base) > (define+provide-module-begin-in-mode world:mode-preproc) > > (module reader racket/base > (require pollen/reader-base) > (define+provide-reader-in-mode world:mode-auto)) > > > ... where `define+provide-module-begin-in-mode` is a macro that creates > the #%module-begin macro, and `define+provide-reader-in-mode` is a macro > that creates the reader. > > This doesn't bother DrRacket when the file is being run, but perhaps this > approach is incompatible with either read-language, or DrRacket's #lang > validation? > > > > > > On Jul 20, 2014, at 4:50 PM, Robby Findler <ro...@eecs.northwestern.edu > <javascript:;>> wrote: > > > It appears that read-language can return #f and what DrRacket does in > > that case appears to be what you're seeing. Is that what you're > > getting? > > > > The docs say that read-language never returns #f (presumably it is > > allowed to return #f when fail-thunk returns #f, but the relevant > > fail-thunk here doesn't return #f) so I'm not sure if that's a docs > > bug, in which case I should change drracket to cope with it or an > > implementation bug. > > > > But if I create a pollen directory, use 'rack pkg --link pollen' to > > set it up and then put main.rkt with this content: > > > > #lang racket/base > > (module reader racket/base (provide read-syntax) > > (define (read-syntax a b) > > #'(module m racket/base))) > > > > then I see this: > > > > $ racket > > Welcome to Racket v6.1.0.3. > >> (read-language (open-input-string "#lang pollen")) > > #f > > > > > > Robby > > > ____________________ > Racket Users list: > http://lists.racket-lang.org/users >
____________________ Racket Users list: http://lists.racket-lang.org/users
