I've just pushed a change to check syntax that picks up tooltip syntax properties in syntax objects that it sees. See the docs for mouse-over-tooltips.
Robby On Thu, Oct 2, 2014 at 8:23 AM, Neil Toronto <neil.toro...@gmail.com> wrote: > [rather later] > > When can I have this wonderful thing? > > As it is, I insert (ann e Void) to discover the type that TR gives `e`. The > type error is very informative. > > With `case->` types, as you say, it can get tricky to find out which > combination of argument types produces which type for any given `e` in the > function body. It might work out to just keep the types in order and number > them. > > Neil ⊥ > > > On 08/12/2014 09:55 AM, Sam Tobin-Hochstadt wrote: >> >> [rather late] >> >> Typed Racket knows quite a bit about the types of expressions, not >> just constants, even when type checking fails. I think we could use a >> logging mechanism similar to the one that allows check syntax to work >> even when type checking fails to communicate types of sub-expressions >> to DrRacket. >> >> There are some cases where expressions are typechecked twice that >> might cause problems, but in general this should be pretty easy. >> >> Sam >> >> On Tue, Aug 5, 2014 at 9:04 PM, Robby Findler >> <ro...@eecs.northwestern.edu> wrote: >>> >>> Is TR's type checker organized in such a way that the decisions about >>> what types are given to constants decided as a separate (first) phase? >>> That is, no matter the context, is this constant: >>> >>> #(0 0) >>> >>> always going to be given the type (Vector Integer Integer), assuming >>> there is no annotation? >>> >>> If so, then it seems like TR could communicate that series of >>> decisions even when type checking fails and that that might be useful >>> for this program? >>> >>> Robby >>> >>> >>> On Tue, Aug 5, 2014 at 7:53 PM, Matthias Felleisen <matth...@ccs.neu.edu> >>> wrote: >>>> >>>> >>>> You guys came up with some wonderful ideas. >>>> >>>> I think this particular one is easy to implement when >>>> the program type checks. But when it doesn't, what do >>>> you show? >>>> >>>> -- Matthias >>>> >>>> >>>> >>>> >>>> >>>> On Aug 5, 2014, at 6:13 PM, Alexander D. Knauth wrote: >>>> >>>>> >>>>> On Aug 5, 2014, at 6:06 PM, Raoul Duke <rao...@gmail.com> wrote: >>>>> >>>>>>>> add type declarations to variables and fields and function and >>>>>>>> method signatures. >>>>>>> >>>>>>> >>>>>>> A good motto, which I shall endeavour to remember. >>>>>> >>>>>> >>>>>> what i do not get about TR and other languages (ocaml, haskell, etc.) >>>>>> is: there are these rules of thumb that you must somehow learn to keep >>>>>> yourself out of the weeds, but you only get to learn them the long and >>>>>> hard way. why don't the runtimes/ides >>>>>> >>>>>> (1) have a switch that says "hey, force me, the user, to put in type >>>>>> annotations by hand in the critical places, ok? so i don't have to >>>>>> suffer so much down the road, ok?" >>>>>> >>>>>> (2) put the inferred annotations into the code as it goes along so i >>>>>> can see what kind of crazy talk the inference engine is having with >>>>>> itself? >>>>> >>>>> >>>>> I’m just wondering, would it be possible for DrRacket to do something >>>>> where you can right-click a variable or expression or something and one of >>>>> the options is to see what the inferred type is? >>>>> >>>>>> ____________________ >>>>>> Racket Users list: >>>>>> http://lists.racket-lang.org/users >>>>> >>>>> >>>>> >>>>> ____________________ >>>>> Racket Users list: >>>>> http://lists.racket-lang.org/users >>>> >>>> >>>> >>>> ____________________ >>>> Racket Users list: >>>> http://lists.racket-lang.org/users >>> >>> >>> ____________________ >>> Racket Users list: >>> http://lists.racket-lang.org/users >> >> >> ____________________ >> Racket Users list: >> http://lists.racket-lang.org/users >> > > ____________________ > Racket Users list: > http://lists.racket-lang.org/users ____________________ Racket Users list: http://lists.racket-lang.org/users