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