[racket] Puzzled about type inference

From: Sam Tobin-Hochstadt (samth at cs.indiana.edu)
Date: Tue Aug 12 15:46:53 EDT 2014

On Tue, Aug 12, 2014 at 1:39 PM, Robby Findler
<robby at 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
> <samth at 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" <robby at 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
>>> <samth at 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
>>> > <robby at 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
>>> >> <matthias at 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 <raould at 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


Posted on the users mailing list.