<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 24, 2015, at 09:06, Matthew Butterick <<a href="mailto:mb@mbtype.com" class="">mb@mbtype.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><span style="font-size:12.8000001907349px" class="">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. </span><br class=""></div><div style="font-size:12.8000001907349px" class=""><br class=""></div><div style="font-size:12.8000001907349px" class="">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.</div><div style="font-size:12.8000001907349px" class=""><br class=""></div><div style="font-size:12.8000001907349px" class=""><br class=""></div><div style="font-size:12.8000001907349px" class=""><br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Jan 24, 2015 at 9:01 AM, Matthew Butterick <span dir="ltr" class=""><<a href="mailto:mb@mbtype.com" target="_blank" class="">mb@mbtype.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">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. <div class=""><br class=""></div><div class="">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<div class=""><div class="h5"><div class=""><div class=""><div class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Jan 24, 2015 at 7:13 AM, Robby Findler <span dir="ltr" class=""><<a href="mailto:robby@eecs.northwestern.edu" target="_blank" class="">robby@eecs.northwestern.edu</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It seems like a small step to start by documenting the ones that<br class=""> people trip up against multiple times in our mailing lists.<br class=""> <span class=""><font color="#888888" class=""><br class=""> Robby<br class=""> </font></span><div class=""><div class=""><br class=""> On Sat, Jan 24, 2015 at 9:07 AM, Matthias Felleisen<br class=""> <<a href="mailto:matthias@ccs.neu.edu" target="_blank" class="">matthias@ccs.neu.edu</a>> wrote:<br class=""> ><br class=""> > On Jan 24, 2015, at 1:43 AM, Matthew Butterick wrote:<br class=""> ><br class=""> > FWIW, Sam's point that one can't expect every untyped program to work<br class=""> > without modification is entirely fair.<br class=""> ><br class=""> ><br class=""> > Correct.<br class=""> ><br class=""> > But Konrad's point is also fair: if a function like `append` or `hash` works<br class=""> > differently in TR, then it is, for practical purposes, not the same<br class=""> > function, even if it relies on the same code.<br class=""> ><br class=""> ><br class=""> > This statement is too coarse. There are at least two senses in which a TR<br class=""> > function f is distinct from an R function:<br class=""> ><br class=""> > 1. f's type restricts the usability of f to a strict "subset" [in the naive<br class=""> > set-theoretic sense]. This is most likely due to a weakness of the type<br class=""> > system; the language of "theorems" isn't strong enough to express R's<br class=""> > intention w/o making the inference rules unsound. [Unlike in the legal<br class=""> > world, In PL arguments of 'typedness' must be about truly-guilty or<br class=""> > not-guilty. The rulings are completely impartial and uniform, i.e., totally<br class=""> > fair.]<br class=""> ><br class=""> > 2. f's type ___changes___ the meaning of the code. (That's also possible but<br class=""> > I don't want to fan the argument that Sam and I have about this.)<br class=""> ><br class=""> ><br class=""> > If it would be superfluous to repeat every TR function in the documentation,<br class=""> > it still could be valuable to document some of the major departures from<br class=""> > Racket. I mean, I would read that, for sure ;)<br class=""> ><br class=""> ><br class=""> ><br class=""> > Actually it would not be superfluous. We just don't have the manpower but<br class=""> > perhaps it's time to tackle this problem (perhaps in a semi-automated<br class=""> > manner).<br class=""> ><br class=""> > -- Matthias<br class=""> ><br class=""> ><br class=""> </div></div><div class=""><div class="">> ____________________<br class=""> > Racket Users list:<br class=""> > <a href="http://lists.racket-lang.org/users" target="_blank" class="">http://lists.racket-lang.org/users</a><br class=""> ><br class=""> </div></div></blockquote></div><br class=""></div></div></div></div></div></div></div></div> </blockquote></div><br class=""></div></div> ____________________<br class=""> Racket Users list:<br class=""> <a href="http://lists.racket-lang.org/users" class="">http://lists.racket-lang.org/users</a><br class=""></div></blockquote></div><br class=""></body></html>