I think that it would work better to: a. Associate the information with a syntax object rather than a location. b. Provide an sexp rather than a string, so that it can be formatted appropriately by DrRacket.
Sam On Aug 12, 2014 12:15 PM, "Robby Findler" <ro...@eecs.northwestern.edu> wrote: > That would be great. I think you'd just want to tell check syntax "at > this position, here is a string to show the user". Is that ok? (And > you'd put newlines in the string to format it, I guess?) > > Robby > > On Tue, Aug 12, 2014 at 8:55 AM, Sam Tobin-Hochstadt > <sa...@cs.indiana.edu> 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
