[racket] Puzzled about type inference

[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
>