You can use wider types. It is one thing to be able to formulate types at all and another to formulate the most descriptive ones, right?
On Aug 9, 2012, at 3:27 PM, Neil Toronto wrote: > On 08/09/2012 12:52 PM, Ray Racine wrote: >> Noticed here http://www.ccs.neu.edu/home/samth/adapt/Current_Status.html > > I had no idea someone had been assigned. Cool! > >> That the Plot collection still awaits porting to TR. Has any partial >> work been done, maybe languishing in a github repo somewhere, that can >> be leveraged? > > Are you volunteering? :) > > It's only possible now that TR has support for keyword arguments. > > There's one issue that could cause problems: some renderer-producing > functions, like `points', accept lists of vectors as arguments. If the data > argument to `points' had a nice, general type like > > (Listof (Vectorof Real Real)) > > then applying `points' to > > '(#(0.0 1.0) #(1.0 2.2)) > > wouldn't typecheck. The problem is that TR thinks `points' might change that > 0.0 to 0, which would make the original argument type (Listof (Vector Float > Float)) incorrect. It thinks Bad Things could happen. (Technically, a vector > is "invariant".) > > I can think of two solutions right now: > > 1. Wait for a Const type constructor or similar. > > 2. Change the contract of `points' to accept lists of pairs, sequences or a > specialized data type. > > I think the contract of `points' should be changed anyway, so users can send > it any kind of sequence. Might as well make it current-TR-friendly at the > same time. > > Neil ⊥ > > ____________________ > Racket Users list: > http://lists.racket-lang.org/users
smime.p7s
Description: S/MIME cryptographic signature
____________________ Racket Users list: http://lists.racket-lang.org/users
