On Sat, Jan 24, 2015 at 12:06 PM, Matthew Butterick <m...@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.
For this issue, Alex just submitted a patch, so it will be fixed soon. In general, TR doesn't work well with functions like `hash` that take their arguments in pairs or triples, and thus they end up having simpler types than the full Racket behavior. Sam > > > > > On Sat, Jan 24, 2015 at 9:01 AM, Matthew Butterick <m...@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 >> <ro...@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 >>> <matth...@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 >>> > >> >> > > > ____________________ > Racket Users list: > http://lists.racket-lang.org/users > ____________________ Racket Users list: http://lists.racket-lang.org/users
