[racket] Typed Racket frustration

FWIW, I ran into this exact same problem when I started using TR. The `hash` function is weird. I started using make-hash and its ilk, and I haven’t had problems since.

There are still plenty of weird edge cases I run into on a regular basis. Submodules don’t really work right. When I started, async channels couldn’t really be used in typed code from untyped code because there were no async channel contracts. I fixed that myself. I recently ran into the fact that struct declarations don’t work in internal definition contexts in TR.

All that said, I keep using Typed Racket because the static typechecking is invaluable to me. I use DrRacket rather than Emacs w/racket-mode, and I can understand why people wouldn’t, but along with the type tooltips and background expansion’s always-on program validation, it’s just a lot harder to make mistakes. The typechecker catches a lot of errors before you even run the program.

So basically, YMMV. If you’re used to writing dynamic code to the point where runtime errors are few enough that the static typechecking isn’t worth it, the trouble with adapting some untyped paradigms to typed code might not be worth your time. I’ve personally found it to be worth it, though.

> On Jan 24, 2015, at 09:06, Matthew Butterick <mb at mbtype.com> wrote:
> 
> Of course, developer time is limited, so I'm always reluctant to post comments amounting to "it would be nice if someone else did such-and-such for me ..." In this case I simply don't have the experience with TR to know where the major breaks with idiomatic Racket occur. 
> 
> But user time is limited too. In my case, I'm trying to decide whether TR is a cost-effective upgrade for my Racket program. What I can't figure out is whether `hash` is an outlier, or the tip of the iceberg, because today, I'm a complete idiot about TR.
> 
> 
> 
> 
> On Sat, Jan 24, 2015 at 9:01 AM, Matthew Butterick <mb at mbtype.com <mailto:mb at mbtype.com>> wrote:
> Of course, developer time is limited, so I'm always reluctant to post comments amounting to "it would be nice if someone else did such-and-such for me ..." In this case I simply don't have the experience with TR to know where the major breaks with idiomatic Racket occur. 
> 
> But user time is limited too. In my case, I'm trying to decide whether TR is a cost-effective upgrade for my Racket program. What I can't figure out is whether `hash
> 
> 
> On Sat, Jan 24, 2015 at 7:13 AM, Robby Findler <robby at eecs.northwestern.edu <mailto:robby at eecs.northwestern.edu>> wrote:
> It seems like a small step to start by documenting the ones that
> people trip up against multiple times in our mailing lists.
> 
> Robby
> 
> On Sat, Jan 24, 2015 at 9:07 AM, Matthias Felleisen
> <matthias at ccs.neu.edu <mailto:matthias at ccs.neu.edu>> wrote:
> >
> > On Jan 24, 2015, at 1:43 AM, Matthew Butterick wrote:
> >
> > FWIW, Sam's point that one can't expect every untyped program to work
> > without modification is entirely fair.
> >
> >
> > Correct.
> >
> > But Konrad's point is also fair: if a function like `append` or `hash` works
> > differently in TR, then it is, for practical purposes, not the same
> > function, even if it relies on the same code.
> >
> >
> > This statement is too coarse. There are at least two senses in which a TR
> > function f is distinct from an R function:
> >
> > 1. f's type restricts the usability of f to a strict "subset" [in the naive
> > set-theoretic sense]. This is most likely due to a weakness of the type
> > system; the language of "theorems" isn't strong enough to express R's
> > intention w/o making the inference rules unsound. [Unlike in the legal
> > world, In PL arguments of 'typedness' must be about truly-guilty or
> > not-guilty. The rulings are completely impartial and uniform, i.e., totally
> > fair.]
> >
> > 2. f's type ___changes___ the meaning of the code. (That's also possible but
> > I don't want to fan the argument that Sam and I have about this.)
> >
> >
> > If it would be superfluous to repeat every TR function in the documentation,
> > it still could be valuable to document some of the major departures from
> > Racket. I mean, I would read that, for sure ;)
> >
> >
> >
> > Actually it would not be superfluous. We just don't have the manpower but
> > perhaps it's time to tackle this problem (perhaps in a semi-automated
> > manner).
> >
> > -- Matthias
> >
> >
> > ____________________
> >   Racket Users list:
> >   http://lists.racket-lang.org/users <http://lists.racket-lang.org/users>
> >
> 
> 
> ____________________
>  Racket Users list:
>  http://lists.racket-lang.org/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20150124/2a453933/attachment.html>