First of all, +1 for this stuff being confusing. I’ve been implementing a language lately that needs its own lexer, reader, runtime configuration, etc., and while the Racket docs are usually very good, this stuff is sprawled out across the guide, the reference, the docs for syntax/module-reader, the docs for DrRacket, and other random places. It’s really hard to get a good grasp on all the details.
My current understanding of get-info is that it... (1) ...was designed to be extensible with arbitrary keys. (2) ...isn’t actually used for all that much. The only key I have implemented myself is 'color-lexer, which is used by DrRacket to pick a lexer for the highlighter. The DrRacket docs[1] also include a number of other properties that can be used to customize things like the indenter and toolbar buttons, but my impression is that all of the things get-info is used for are for tooling, not for adjusting language semantics in any way. Of course, syntax/module-reader also passes a third argument[2], which allows syntax/module-reader to provide some of its own defaults while still allowing the user to override the implementation for those keys and have access to the defaults provided to the get-info function. This seems a bit needlessly complicated at first, but I’m not sure if there’s a better way to do it. Now, my impression is that for the vast majority of #langs, the get-info function will never depend upon the contents of the input port provided to the factory function, and in fact, syntax/module-reader skips that step entirely and always provides the same function. However, for meta-languages, the ability to read what language follows is extremely important, because it needs to delegate to the underlying language to get the actual get-info implementation. I can’t imagine that would ever be terribly useful for things that don’t do that sort of delegation trickery, though, so the syntax/module-reader interface seems to make a lot more sense for the vast majority of languages. That’s all I got, though. If you find out something more definitive, centralizing this information in the documentation would be much appreciated! [1]: http://docs.racket-lang.org/tools/adding-languages.html [2]: http://docs.racket-lang.org/syntax/reader-helpers.html#%28mod-path._syntax%2Fmodule-reader%29 > On Jun 29, 2016, at 15:58, Alex Knauth <alexan...@knauth.org> wrote: > > I'm trying to rewrite `make-meta-reader` to hopefully make more sense. > > A racket #lang language normally defines and provides a `get-info` function > in its reader module along with `read` and `read-syntax`. However, there > seems to be very little documentation about what this is supposed to do, and > there are different versions for bare #langs versus `syntax/module-reader` > versus `make-meta-reader` versus `read-language`. > > Is there anyone who can explain what is allowed and what isn't for the > `get-info` function that a #lang is supposed to provide? > > ;; ---------------- > > The only documentation I could find was in the Source-Handling Configuration > part of the Creating Languages section of the Racket Guide, here: > http://docs.racket-lang.org/guide/language-get-info.html > > It gives this example > >> (define (get-info in mod line col pos) >> (lambda (key default) >> (case key >> [(color-lexer) >> (dynamic-require 'syntax-color/default-lexer >> 'default-lexer)] >> [else default]))) > > And this explanation > >> The get-info function is called by read-language (which DrRacket calls) with >> the source input stream and location information, in case query results >> should depend on the content of the module after the language name (which is >> not the case for literal). The result of get-info is a function of two >> arguments. > > So the `in` argument is the input stream, and the `line`, `col`, and `pos` > arguments specify positions of something (what?). > > What is the second argument, the `mod` argument? > > At the top I mentioned I was trying to rewrite `make-meta-reader`, which > needs to return a valid `get-info` function as one of its 3 return values. As > it does that it needs to go to the module returned by the > `module-path-parser` argument and use the original `get-info` function from > there. It seems to be doing some pretty weird stuff, having a `get` helper > function which return 2 values, the second of which is a `next-mod` thing, > which it passes as the second argument to the original `get-info` function, > and then passes the result of that to the `convert-get-info` function. > > I am thoroughly confused by all of this. Can someone explain how the > `get-info` function is supposed to work? > > Alex Knauth -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
