[racket] Puzzled about type inference

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Thu Oct 2 19:48:32 EDT 2014

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.toronto at 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
>> <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
>>
>>
>> ____________________
>>    Racket Users list:
>>    http://lists.racket-lang.org/users
>>
>
> ____________________
>  Racket Users list:
>  http://lists.racket-lang.org/users


Posted on the users mailing list.