On Tue, Aug 12, 2014 at 1:39 PM, Robby Findler <ro...@eecs.northwestern.edu> wrote: > A. won't work; the communication has to be things that can be > transmitted on place channels. Currently, all of this communication is > already position-based. Of course, it's easy to make position based > information from a syntax object.
Sure, I can do that. It might make sense for the logging to handle syntax objects, though, and do its own internal serialization that could be improved as needed. > B.: I don't see what you mean. Why does DrRacket know better than TR > how to format TR types? I was thinking that DrRacket might want to line-break things differently, or otherwise render things more interestingly. Sam > On Tue, Aug 12, 2014 at 12:36 PM, Sam Tobin-Hochstadt > <sa...@cs.indiana.edu> wrote: >> 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