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,
On Jan 1, 2013, at 5:59 PM, Danny Yoo wrote:
(Note: the Python parser example works! It's basically a copy and
paste of the one in the original Python source tree.)
That is fantastic.
I need to polish ragg.
Thanks. I can foresee tons of uses in the DSL world.
As I was trying to assembly my first planet2 package, I found myself wondering
how exactly to 'require' modules associated with planet2 packages. My initial
assumption (require them like any other collection containing modules) turned
out to be correct, but there was a period when I doubted
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
The documentation already says A package is a set of modules for some
number of collections. And there's no reason to think that these modules
are different from other modules, so I don't see why we need to point out
that they are required like all other modules are.
If you think it's very
There _is_ reason to think these modules are different, because they were
different in Planet1. I've had to remind myself several times that Planet2
packages don't have special require forms, and that's just during
discussions -- I haven't even been writing code with them yet. Clarifying
that
I agree in that context that it is useful as a part of the What's
different about Planet 2? And it's there (question 6).
But, in the context of a new Racket user learning about packages, I don't
see a reason to add the baggage of how it's different than some system
they've never used.
Jay
On
It doesn't need to be phrased as a comparison to Planet1, but it can be
given as a reassurance that this package system thingy does not add any
baggage to require lines.
Carl Eastlund
On Wed, Jan 2, 2013 at 3:49 PM, Jay McCarthy jay.mccar...@gmail.com wrote:
I agree in that context that it is
Sounds fine. John's original language seems like that and is good to me.
On Wed, Jan 2, 2013 at 1:59 PM, Carl Eastlund c...@ccs.neu.edu wrote:
It doesn't need to be phrased as a comparison to Planet1, but it can be
given as a reassurance that this package system thingy does not add any
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
On Jan 2, 2013, at 1:03 PM, Jay McCarthy wrote:
Sounds fine. John's original language seems like that and is good to me.
Pushed, thanks.
John
On Wed, Jan 2, 2013 at 1:59 PM, Carl Eastlund c...@ccs.neu.edu wrote:
It doesn't need to be phrased as a comparison to Planet1, but it can be
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
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
13 matches
Mail list logo
