Re: [racket-dev] Five feature/limitation interactions conspire to drive mad

2013-01-03 Thread Vincent St-Amour
At Wed, 02 Jan 2013 16:57:39 -0700, Neil Toronto wrote: On 01/02/2013 02:51 PM, Vincent St-Amour wrote: In your experience, have these types caused you trouble other than when you went looking for them specifically? Not that I recall. If I stick to union types like Integer,

Re: [racket-dev] Five feature/limitation interactions conspire to drive mad

2013-01-02 Thread Matthias Felleisen
On Jan 1, 2013, at 7:42 PM, Neil Toronto wrote: Question: did you start the math library in an untyped form (and switch) or did you go with types from the get-go? It's all been in Typed Racket from the beginning. This was initially because I mostly had floating-point functions planned,

Re: [racket-dev] Five feature/limitation interactions conspire to drive mad

2013-01-02 Thread Neil Toronto
On 01/02/2013 10:09 AM, Matthias Felleisen wrote: I remain worried that R programmers will want to use math and array and matrix and friends and will experience performance problems when you have invested so much work in doing it right the first time. But we will see. They'll experience

Re: [racket-dev] Five feature/limitation interactions conspire to drive mad

2013-01-02 Thread Vincent St-Amour
At Wed, 02 Jan 2013 12:39:21 -0700, Neil Toronto wrote: Interesting. My extremely limited experience -- and Shriram's -- suggests an eternal struggle with the numerical tower for 'beginners' like myself. This is my experience as well. One place this bit me pretty early was getting TR

Re: [racket-dev] Five feature/limitation interactions conspire to drive mad

2013-01-02 Thread Neil Toronto
On 01/02/2013 02:51 PM, Vincent St-Amour wrote: At Wed, 02 Jan 2013 12:39:21 -0700, Neil Toronto wrote: One place this bit me pretty early was getting TR to optimize loops over indexes *without using casts or assertions*. Right, fixnum types are tricky. They don't have many closure

Re: [racket-dev] Five feature/limitation interactions conspire to drive mad

2013-01-02 Thread Matthias Felleisen
On Jan 2, 2013, at 2:39 PM, Neil Toronto wrote: After you do understand the numeric tower well, you start looking for ways to prove to TR that your code won't explode at runtime. It's not always possible - again because, sometimes, the types aren't as precise as they could be. But

Re: [racket-dev] Five feature/limitation interactions conspire to drive mad

2013-01-01 Thread Matthias Felleisen
On Dec 31, 2012, at 6:32 PM, Sam Tobin-Hochstadt wrote: I'm not sure that an ad-hoc naming solution is the right thing. I really want to avoid adding more ad-hoc complexity to the Typed Racket type checker, and instead work on simplifying it into something that can be more precisely

Re: [racket-dev] Five feature/limitation interactions conspire to drive mad

2013-01-01 Thread Matthias Felleisen
Neil, thanks for the user story. We should hear more of those for all kinds of corners in our world. Question: did you start the math library in an untyped form (and switch) or did you go with types from the get-go? -- Matthias On Dec 31, 2012, at 3:27 PM, Neil Toronto wrote: The

Re: [racket-dev] Five feature/limitation interactions conspire to drive mad

2013-01-01 Thread Neil Toronto
On 01/01/2013 03:35 PM, Matthias Felleisen wrote: Neil, thanks for the user story. We should hear more of those for all kinds of corners in our world. You're welcome! Question: did you start the math library in an untyped form (and switch) or did you go with types from the get-go? It's

Re: [racket-dev] Five feature/limitation interactions conspire to drive mad

2013-01-01 Thread Ray Racine
All good points on TR development flows. If I could elaborate from my perspective on Neils' #3. I think this is the #1 benefit of TR over R. Yes, static type checking, real-time while you type is superb road kill on the highway of code development And I do enjoy it so. BUT what TR really,