I was thinking of turning of type checking and the translation of types into contracts. (Unless I misunderstand your mini language, I think you're cheating in a more fundamental manner "-)
On Nov 3, 2012, at 11:41 AM, Jay McCarthy wrote: > I have a little language for doing this: > > https://github.com/jeapostrophe/exp/tree/master/tr-cheat > > run > > https://github.com/jeapostrophe/exp/blob/master/tr-cheat/tr-cheat-use.rkt > > to see the SEGFAULT > > :) > > > On Sat, Nov 3, 2012 at 9:20 AM, Matthias Felleisen <matth...@ccs.neu.edu> > wrote: > > On Nov 3, 2012, at 11:13 AM, Neil Toronto wrote: > > > On 10/29/2012 07:03 AM, Matthias Felleisen wrote: > >> > >> > >> On Oct 29, 2012, at 12:31 AM, Neil Toronto wrote: > >> > >>> I wouldn't mind changing the API; it would be nice to have things like > >>> `points' accept sequences anyway. I haven't put much thought into what > >>> would be in the sequences, though. > >> > >> > >> Question: can you change the API for the Typed version and support both > >> APIs for the Untyped one? -- Matthias > > > > More easily than the other way around. Also, that would work around the > > covariance problem with vectors. I could change the contract to accept a > > sequence of vectors or lists, and use the type (Sequenceof (List Real > > Real)). > > > > I still need a `->*' type constructor, because most plot functions have 2-5 > > optional arguments and 10-20 arguments altogether. For the largest > > functions, a `case->' type would be huge and easy to get wrong. Also, I'm > > morally opposed to types that don't fit on my screen. > > > > I'll get around to submitting a formal request, after I get this Poisson > > distribution quantile function working... > > > > Neil ⊥ > > > > > Last night Sam, Tony and I had a discussion on TR/R boundaries > for his "racket on a router" project. Tony ported his software > from Racket to Typed Racket and stopped halfway in between. The > 'framework' (aka kernel) is now in TR and the 'user program' aka > 'client' lives in R. I had predicted that the boundary between the > two would cause a severe performance and Tony has now confirmed > this conjecture. (We are talking factors not small percentages.) > > As you get racket/math ready for production, I think you too should > measure the performance hit from going across the boundary. If it > is bad, we should consider including both a typed and an untyped > variant where the latter is generated from the former (I believe > you are working in TR so that's why I wrote the last sentence). > That is, when the library is installed the Untyped one should be > generated by disabling types and type checking. > > -- Matthias > > > ____________________ > Racket Users list: > http://lists.racket-lang.org/users > > > > > -- > Jay McCarthy <j...@cs.byu.edu> > Assistant Professor / Brigham Young University > http://faculty.cs.byu.edu/~jay > > "The glory of God is Intelligence" - D&C 93
smime.p7s
Description: S/MIME cryptographic signature
____________________ Racket Users list: http://lists.racket-lang.org/users
