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