On Feb 7, 2015, at 7:35 AM, Sam Tobin-Hochstadt <sa...@cs.indiana.edu> wrote:
> Can you say more about what the best workflow for you would be here?
> Should this information appear in the blue boxes that DrRacket shows,
> or in a tooltip, or somewhere else? Or do you want to have it listed
> in a separate document that you read in the browser? Or something else
> entirely?
My one-person focus group would create entries for each `(inst proc ...)` in
the HTML documentation that might look something like this:
Then I would hook these entries into DrRacket so they appear in the upper-right
blue box when I hover over `inst` (in lieu of the default '(inst e t ...) (inst
e t ... t ooo bound)')
>>
> I'm not sure what you're imagining the "instantiation-arg-spec" would
> look like. If we add documentation with the types of standard library
> functions, then I think the most useful thing to present is the actual
> type (or perhaps a simplified version in some cases where the type is
> very large). In particular, I don't think that we could describe how
> to instantiate polymorphic types better than by giving the type.
As someone learning TR, I find that the types as printed in the REPL sometimes
reveal implementation details that conceal a simpler underlying logic. Take
`map`:
- : (All (c a b ...)
(case->
(-> (-> a c) (Pairof a (Listof a)) (Pairof c (Listof c)))
(-> (-> a b ... b c) (Listof a) (Listof b) ... b (Listof c))))
After a little fiddling one discovers that "oh, it's just (inst map output-type
input-type ...)". So this is where a documentation entry could add value,
because it can explain this underlying logic.____________________
Racket Users list:
http://lists.racket-lang.org/users
