Re: [racket-dev] Five feature/limitation interactions conspire to drive mad
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, and I wanted TR's help proving that I never used non-flonums by mistake. Also, I wanted the special functions to have performance competitive with C implementations. I suspect I asked you the question before. Here is why I am asking. TR is still in its formative phase. So is the numerical type hierarchy, and so is OC. If you had developed in R first, we could have created (1) a use-case story for TR (2) measured how often you accidentally use an integer in library code and this 'pollute' the performance by accident (3) measured how easily OC helps you with (2) (4) measured the performance of 'best but not unsafe' R code (5) converted from R to TR and measured improvement cmp to (4) Step (5) is particularly interesting because none of our past R - TR experiences was about number-intensive programs. As you may know, we claimed in PADL '12 that writing numeric code in R is like translating text book math into code. Question is whether this is true from an SE perspective. Even if it is, how much do you pay for this ease of SE; see (2) through (5). In OOPSLA '12 we claimed OC can help you a lot with finding (among others) numerical slow-downs where an R programmer accidentally pollutes numeric programs with ints and, worse, big nums. Again, it would have been wonderful to confirm the conjecture. BUT: I understand that this library isn't a small library and we already imposed on you and your 'vacation' time. So perhaps it would have been way too much effort to conduct an SE/performance experiment at the same time. 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. ;; --- 3. ... I can't speak for anyone else, but when I get something ... to pass the type checker, my code is usually correct. I have heard this sentence often, in exactly this form. I have never believed it and I will share an anecdote here on this one. Some 10 years ago I was invited to teach at some European summer school on functional programming. I presented my first lecture early and I emphasized the design recipe, and our brand-new built-in support for testing. As the only untyped speaker (sounds like 'unwashed' when I write this here), I was heckled for testing my code. But you know me, I gave back what I got. That afternoon a speaker whose initials are P and W spoke about something typed and he wanted to imitate me with a life demo. He ran his code .. and got an exception. I couldn't help it but suggesting a test suite facility for this language; its name starts with H. I will freely acknowledge that type systems such as ML's, Haskell's, and ours eliminate typo-level mistakes immediately. I am deeply skeptical about the elimination of semantic bugs. That's not what these type systems are about. 4. TR's types for Racket's numeric tower, especially the additional `Index' type, makes it easy to safely use unsafe indexing. Throughout `math/array', values of type `Index' are always either a size (e.g. a vector length) or an index that has been proved to be less than a size. IOW, if I can get TR to prove j : Index, I'm satisfied that (unsafe-vector-ref xs j) is actually safe. Also, if `j' is a loop counter, TR can usually compare and increment using unsafe fixnum ops. There are a bunch of other little things that are like #4 (which is only a big thing because indexes are so prevalent in `math/array'). Maybe I'll collect those into a separate user story. Interesting. My extremely limited experience -- and Shriram's -- suggests an eternal struggle with the numerical tower for 'beginners' like myself. Thanks -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Working on Ragg. Suggestions?
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. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Attempted clarification for planet2 docs
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 this, and I think it
should be documented.
Below is a proposed doc change; I'll commit it if you like it, or abandon it if
not. I'm including the (git format-patch) text and also attaching it as a file.
John
From d3f72c47820effb240532c518378dc9709d69600 Mon Sep 17 00:00:00 2001
From: John Clements cleme...@racket-lang.org
Date: Tue, 1 Jan 2013 10:40:40 -0800
Subject: [PATCH] added docs on requiring planet2 modules
---
collects/planet2/scribblings/planet2.scrbl | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/collects/planet2/scribblings/planet2.scrbl
b/collects/planet2/scribblings/planet2.scrbl
index e9e565a..81d6e58 100644
--- a/collects/planet2/scribblings/planet2.scrbl
+++ b/collects/planet2/scribblings/planet2.scrbl
@@ -200,6 +200,20 @@ imply a change in the @tech{checksum}.
@section{Using Packages}
+Modules installed using planet2 may be @tech{require}d like any other
+modules. For instance, if the package @pkgname{recipes} contains
+the module file @filepath{vegan/fruitsalad.rkt}, then package users
+who have this package installed may evaluate
+
+@racketblock[(require vegan/fruitsalad)]
+
+...to require this module.
+
+@;
+
+@section{Managing Packages}
+
+
The Racket package manager has two user interfaces: a command line @exec{raco}
sub-command and a library. They have the exact same capabilities, as
the command line interface invokes the library functions and
--
1.7.7.5 (Apple Git-26)
0001-added-docs-on-requiring-planet2-modules.patch
Description: Binary data
smime.p7s
Description: S/MIME cryptographic signature
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] Five feature/limitation interactions conspire to drive mad
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 performance problems only for `math/array' and `math/matrix'. Most everything else isn't higher-order. 3. ... I can't speak for anyone else, but when I get something ... to pass the type checker, my code is usually correct. I have heard this sentence often, in exactly this form. I have never believed it... I don't believe it, either, because it's obviously wrong. That's why the array library has hundreds of test cases. The like `array-axis-reduce' part is missing from that sentence, probably because I wasn't very clear about what it means. Having had time to mull it over, I've decided I meant combinators. When I get a combinator to pass the type checker, its implementation is usually correct. The type of `unsafe-array-axis-reduce' is (All (A B) ((Array A) Index (Index (Index - A) - B) - (Array B))) (Haskell, in Racket. It's so beautiful. *sniff*) Like most combinators, it's not obvious from the type what it means. But the type puts severe constraints on what can be done with the arguments. Usually, when I fill in the code around a type like this, there are only two options that pass the type checker, which also plausibly implement what I want. For this, I had a test case in mind: (unsafe-array-axis-reduce arr 0 build-list) which reduced the two options to the correct one. On the other hand, I've written monads in untyped Racket before. It... really kind of sucks without having about 5x more test cases than code. If you don't have them - and they can be hard to come up with, so it's easy to leave them out - getting it right is awful. It's really easy to have something you think works until you use some return/bind combo you didn't think of before, which blows up. I will freely acknowledge that type systems such as ML's, Haskell's, and ours eliminate typo-level mistakes immediately. I am deeply skeptical about the elimination of semantic bugs. That's not what these type systems are about. I wonder if I could sum up by claiming that, with combinators, there's a great amount of overlap between typos and semantic errors. The simplest example I can think of is the type (All (A) (A - A)), which has only one correct implementation. Everything else is a typo. 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 to optimize loops over indexes *without using casts or assertions*. It's a puzzle, but it's solvable with a couple of templates. Here's one to loop over [0..n-1]: ensure n : Index ... (let: loop ([i : Nonnegative-Fixnum 0] args ...) (cond [(i . fx . n) compute ... (loop (fx+ i 1) args ...)] [else answer ...])) The optimizer changes `fx' into `unsafe-fx' and `fx+' into `unsafe-fx+'. Also, (i . fx . n) proves i : Index within compute Here's a template to loop over [n-1..0]: ensure n : Index ... (let: loop ([i : Index n] args ...) (cond [(i . fx= . 0) answer ...] [else (let ([i (fx- i 1)]) compute ... (loop i args ...))])) The optimizer changes `fx=' and `fx-' to their unsafe counterparts. Also, (i . fx= . 0) proves i : Positive-Index in the `else' branch, so i : Index in compute This should also work: (let: loop ([i : Index n] args ...) (cond [(i . fx . 0) (let ([i (fx- i 1)]) compute ... (loop i))] [else answer ...])) Unfortunately, (i . fx . 0) doesn't prove i : Positive-Index, even though it could. This brings me to what I think is the major issue for us n00bs: the types force you to understand the numeric tower really well if you want to use types more precise than `Number'. Before you reach that level of understanding, though, and Typed Racket spits errors at you, it's hard to tell whether it has a legitimate complaint - especially when you don't know whether you should expect, say, (i . fx . 0) to prove i : Positive-Index. It would be really handy if TR could give counterexamples in these cases. This is how you can end up with an exact zero by multiplying an exact rational and a flonum: (* 0 1.0). 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 sometimes because it's just hard. One fine example is `sqrt'. Its types are sensible: (sqrt (ann 5 Real)) - : Number
Re: [racket-dev] Attempted clarification for planet2 docs
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 confusing, then feel free to push the commit with
two small changes:
1. The docs don't use the term planet2, so just say the Racket package
manager
2. Consider using the same examples from the rest of the docs (such as
data/matrix from tic-tac-toe)
Jay
On Wed, Jan 2, 2013 at 12:30 PM, John Clements cleme...@brinckerhoff.orgwrote:
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 this, and I think it should be documented.
Below is a proposed doc change; I'll commit it if you like it, or abandon
it if not. I'm including the (git format-patch) text and also attaching it
as a file.
John
From d3f72c47820effb240532c518378dc9709d69600 Mon Sep 17 00:00:00 2001
From: John Clements cleme...@racket-lang.org
Date: Tue, 1 Jan 2013 10:40:40 -0800
Subject: [PATCH] added docs on requiring planet2 modules
---
collects/planet2/scribblings/planet2.scrbl | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/collects/planet2/scribblings/planet2.scrbl
b/collects/planet2/scribblings/planet2.scrbl
index e9e565a..81d6e58 100644
--- a/collects/planet2/scribblings/planet2.scrbl
+++ b/collects/planet2/scribblings/planet2.scrbl
@@ -200,6 +200,20 @@ imply a change in the @tech{checksum}.
@section{Using Packages}
+Modules installed using planet2 may be @tech{require}d like any other
+modules. For instance, if the package @pkgname{recipes} contains
+the module file @filepath{vegan/fruitsalad.rkt}, then package users
+who have this package installed may evaluate
+
+@racketblock[(require vegan/fruitsalad)]
+
+...to require this module.
+
+@;
+
+@section{Managing Packages}
+
+
The Racket package manager has two user interfaces: a command line
@exec{raco}
sub-command and a library. They have the exact same capabilities, as
the command line interface invokes the library functions and
--
1.7.7.5 (Apple Git-26)
--
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay
The glory of God is Intelligence - DC 93
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] Attempted clarification for planet2 docs
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 Planet2 simplifies the require lines, and makes user packages on a
peer level with built-in collections, is a useful thing to put early on in
the Planet2 docs.
Carl Eastlund
On Wed, Jan 2, 2013 at 3:27 PM, Jay McCarthy jay.mccar...@gmail.com wrote:
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 confusing, then feel free to push the commit with
two small changes:
1. The docs don't use the term planet2, so just say the Racket package
manager
2. Consider using the same examples from the rest of the docs (such as
data/matrix from tic-tac-toe)
Jay
On Wed, Jan 2, 2013 at 12:30 PM, John Clements
cleme...@brinckerhoff.orgwrote:
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 this, and I think it should be documented.
Below is a proposed doc change; I'll commit it if you like it, or abandon
it if not. I'm including the (git format-patch) text and also attaching it
as a file.
John
From d3f72c47820effb240532c518378dc9709d69600 Mon Sep 17 00:00:00 2001
From: John Clements cleme...@racket-lang.org
Date: Tue, 1 Jan 2013 10:40:40 -0800
Subject: [PATCH] added docs on requiring planet2 modules
---
collects/planet2/scribblings/planet2.scrbl | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/collects/planet2/scribblings/planet2.scrbl
b/collects/planet2/scribblings/planet2.scrbl
index e9e565a..81d6e58 100644
--- a/collects/planet2/scribblings/planet2.scrbl
+++ b/collects/planet2/scribblings/planet2.scrbl
@@ -200,6 +200,20 @@ imply a change in the @tech{checksum}.
@section{Using Packages}
+Modules installed using planet2 may be @tech{require}d like any other
+modules. For instance, if the package @pkgname{recipes} contains
+the module file @filepath{vegan/fruitsalad.rkt}, then package users
+who have this package installed may evaluate
+
+@racketblock[(require vegan/fruitsalad)]
+
+...to require this module.
+
+@;
+
+@section{Managing Packages}
+
+
The Racket package manager has two user interfaces: a command line
@exec{raco}
sub-command and a library. They have the exact same capabilities, as
the command line interface invokes the library functions and
--
1.7.7.5 (Apple Git-26)
--
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay
The glory of God is Intelligence - DC 93
_
Racket Developers list:
http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] Attempted clarification for planet2 docs
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 Wed, Jan 2, 2013 at 1:40 PM, Carl Eastlund c...@ccs.neu.edu wrote:
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 Planet2 simplifies the require lines, and makes user packages on a
peer level with built-in collections, is a useful thing to put early on in
the Planet2 docs.
Carl Eastlund
On Wed, Jan 2, 2013 at 3:27 PM, Jay McCarthy jay.mccar...@gmail.comwrote:
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 confusing, then feel free to push the commit with
two small changes:
1. The docs don't use the term planet2, so just say the Racket package
manager
2. Consider using the same examples from the rest of the docs (such as
data/matrix from tic-tac-toe)
Jay
On Wed, Jan 2, 2013 at 12:30 PM, John Clements cleme...@brinckerhoff.org
wrote:
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 this, and I think it should be documented.
Below is a proposed doc change; I'll commit it if you like it, or
abandon it if not. I'm including the (git format-patch) text and also
attaching it as a file.
John
From d3f72c47820effb240532c518378dc9709d69600 Mon Sep 17 00:00:00 2001
From: John Clements cleme...@racket-lang.org
Date: Tue, 1 Jan 2013 10:40:40 -0800
Subject: [PATCH] added docs on requiring planet2 modules
---
collects/planet2/scribblings/planet2.scrbl | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/collects/planet2/scribblings/planet2.scrbl
b/collects/planet2/scribblings/planet2.scrbl
index e9e565a..81d6e58 100644
--- a/collects/planet2/scribblings/planet2.scrbl
+++ b/collects/planet2/scribblings/planet2.scrbl
@@ -200,6 +200,20 @@ imply a change in the @tech{checksum}.
@section{Using Packages}
+Modules installed using planet2 may be @tech{require}d like any other
+modules. For instance, if the package @pkgname{recipes} contains
+the module file @filepath{vegan/fruitsalad.rkt}, then package users
+who have this package installed may evaluate
+
+@racketblock[(require vegan/fruitsalad)]
+
+...to require this module.
+
+@;
+
+@section{Managing Packages}
+
+
The Racket package manager has two user interfaces: a command line
@exec{raco}
sub-command and a library. They have the exact same capabilities, as
the command line interface invokes the library functions and
--
1.7.7.5 (Apple Git-26)
--
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay
The glory of God is Intelligence - DC 93
_
Racket Developers list:
http://lists.racket-lang.org/dev
--
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay
The glory of God is Intelligence - DC 93
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] Attempted clarification for planet2 docs
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 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 Wed, Jan 2, 2013 at 1:40 PM, Carl Eastlund c...@ccs.neu.edu wrote:
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 Planet2 simplifies the require lines, and makes user packages on a
peer level with built-in collections, is a useful thing to put early on in
the Planet2 docs.
Carl Eastlund
On Wed, Jan 2, 2013 at 3:27 PM, Jay McCarthy jay.mccar...@gmail.comwrote:
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 confusing, then feel free to push the commit with
two small changes:
1. The docs don't use the term planet2, so just say the Racket
package manager
2. Consider using the same examples from the rest of the docs (such as
data/matrix from tic-tac-toe)
Jay
On Wed, Jan 2, 2013 at 12:30 PM, John Clements
cleme...@brinckerhoff.org wrote:
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 this, and I think it should be documented.
Below is a proposed doc change; I'll commit it if you like it, or
abandon it if not. I'm including the (git format-patch) text and also
attaching it as a file.
John
From d3f72c47820effb240532c518378dc9709d69600 Mon Sep 17 00:00:00 2001
From: John Clements cleme...@racket-lang.org
Date: Tue, 1 Jan 2013 10:40:40 -0800
Subject: [PATCH] added docs on requiring planet2 modules
---
collects/planet2/scribblings/planet2.scrbl | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/collects/planet2/scribblings/planet2.scrbl
b/collects/planet2/scribblings/planet2.scrbl
index e9e565a..81d6e58 100644
--- a/collects/planet2/scribblings/planet2.scrbl
+++ b/collects/planet2/scribblings/planet2.scrbl
@@ -200,6 +200,20 @@ imply a change in the @tech{checksum}.
@section{Using Packages}
+Modules installed using planet2 may be @tech{require}d like any other
+modules. For instance, if the package @pkgname{recipes} contains
+the module file @filepath{vegan/fruitsalad.rkt}, then package users
+who have this package installed may evaluate
+
+@racketblock[(require vegan/fruitsalad)]
+
+...to require this module.
+
+@;
+
+@section{Managing Packages}
+
+
The Racket package manager has two user interfaces: a command line
@exec{raco}
sub-command and a library. They have the exact same capabilities, as
the command line interface invokes the library functions and
--
1.7.7.5 (Apple Git-26)
--
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay
The glory of God is Intelligence - DC 93
_
Racket Developers list:
http://lists.racket-lang.org/dev
--
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay
The glory of God is Intelligence - DC 93
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] Attempted clarification for planet2 docs
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
baggage to require lines.
Carl Eastlund
On Wed, Jan 2, 2013 at 3:49 PM, Jay McCarthy jay.mccar...@gmail.comwrote:
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 Wed, Jan 2, 2013 at 1:40 PM, Carl Eastlund c...@ccs.neu.edu wrote:
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 Planet2 simplifies the require lines, and makes user packages on a
peer level with built-in collections, is a useful thing to put early on in
the Planet2 docs.
Carl Eastlund
On Wed, Jan 2, 2013 at 3:27 PM, Jay McCarthy jay.mccar...@gmail.comwrote:
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 confusing, then feel free to push the commit
with two small changes:
1. The docs don't use the term planet2, so just say the Racket
package manager
2. Consider using the same examples from the rest of the docs (such as
data/matrix from tic-tac-toe)
Jay
On Wed, Jan 2, 2013 at 12:30 PM, John Clements
cleme...@brinckerhoff.org wrote:
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 this, and I think it should be documented.
Below is a proposed doc change; I'll commit it if you like it, or
abandon it if not. I'm including the (git format-patch) text and also
attaching it as a file.
John
From d3f72c47820effb240532c518378dc9709d69600 Mon Sep 17 00:00:00 2001
From: John Clements cleme...@racket-lang.org
Date: Tue, 1 Jan 2013 10:40:40 -0800
Subject: [PATCH] added docs on requiring planet2 modules
---
collects/planet2/scribblings/planet2.scrbl | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/collects/planet2/scribblings/planet2.scrbl
b/collects/planet2/scribblings/planet2.scrbl
index e9e565a..81d6e58 100644
--- a/collects/planet2/scribblings/planet2.scrbl
+++ b/collects/planet2/scribblings/planet2.scrbl
@@ -200,6 +200,20 @@ imply a change in the @tech{checksum}.
@section{Using Packages}
+Modules installed using planet2 may be @tech{require}d like any other
+modules. For instance, if the package @pkgname{recipes} contains
+the module file @filepath{vegan/fruitsalad.rkt}, then package users
+who have this package installed may evaluate
+
+@racketblock[(require vegan/fruitsalad)]
+
+...to require this module.
+
+@;
+
+@section{Managing Packages}
+
+
The Racket package manager has two user interfaces: a command line
@exec{raco}
sub-command and a library. They have the exact same capabilities, as
the command line interface invokes the library functions and
--
1.7.7.5 (Apple Git-26)
--
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay
The glory of God is Intelligence - DC 93
_
Racket Developers list:
http://lists.racket-lang.org/dev
--
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay
The glory of God is Intelligence - DC 93
--
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay
The glory of God is Intelligence - DC 93
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] Five feature/limitation interactions conspire to drive mad
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 to optimize loops over indexes *without using casts or assertions*. Right, fixnum types are tricky. They don't have many closure properties, so it's hard to stay within these types. Because of this, we try to avoid exposing these types to beginners as much as possible (by, e.g., not having functions in the standard library require them as arguments). The hope is that only experts that are trying to either (1) get every bit of performance our of their programs or (2) enforce strict range properties in their programs actually need to use these types. For the first use case, OC provides some help (and better support is on the way). In your experience, have these types caused you trouble other than when you went looking for them specifically? Unfortunately, (i . fx . 0) doesn't prove i : Positive-Index, even though it could. That's a bug. This brings me to what I think is the major issue for us n00bs: the types force you to understand the numeric tower really well if you want to use types more precise than `Number'. Before you reach that level of understanding, though, and Typed Racket spits errors at you, it's hard to tell whether it has a legitimate complaint - especially when you don't know whether you should expect, say, (i . fx . 0) to prove i : Positive-Index. Were there specific corners of the tower that you found frustrating (other than fixnum types)? It would be really handy if TR could give counterexamples in these cases. This is how you can end up with an exact zero by multiplying an exact rational and a flonum: (* 0 1.0). Since most TR optimization failures can be traced back to a failure to typecheck at an optimizable type, Optimization Coach should be able to help you here. It doesn't currently provide counter-examples, but I'll look into it. However, OC requires a program that typechecks, so it doesn't always apply. Perhaps applying optimization coaching techniques (especially proximity) to type error messages would work. Worth a try. 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 sometimes because it's just hard. One fine example is `sqrt'. Its types are sensible: (sqrt (ann 5 Real)) - : Number 2.23606797749979 (sqrt (ann 5 Nonnegative-Real)) - : Real [generalized from Nonnegative-Real] 2.23606797749979 But it's often really hard to prove that something is nonnegative without an explicit cast, assertion, or test, and thus stay within the reals in expressions with roots. I actually see that as a positive: if a property is too hard to prove using the type system alone, you have the option to use casts, assertions, or tests to help TR prove what you want [1]. Casts, assertions and tests give you extra power to prove things that you couldn't prove otherwise, or to make proofs easier. As for the difficulty of proving properties, specific types could probably be improved, but I don't have a general solution. Racket's numeric tower is complicated, and TR needs to be compatible with it. Thanks for the feedback! Vincent [1] Assertions and tests are usually cheap, but casts are surprisingly expensive since they involve contracts. There's probably room for improvement there. In the meantime, I'll extend OC to warn you when you use casts in hot code. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Attempted clarification for planet2 docs
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 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 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 Wed, Jan 2, 2013 at 1:40 PM, Carl Eastlund c...@ccs.neu.edu wrote:
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 Planet2
simplifies the require lines, and makes user packages on a peer level with
built-in collections, is a useful thing to put early on in the Planet2 docs.
Carl Eastlund
On Wed, Jan 2, 2013 at 3:27 PM, Jay McCarthy jay.mccar...@gmail.com wrote:
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 confusing, then feel free to push the commit with two
small changes:
1. The docs don't use the term planet2, so just say the Racket package
manager
2. Consider using the same examples from the rest of the docs (such as
data/matrix from tic-tac-toe)
Jay
On Wed, Jan 2, 2013 at 12:30 PM, John Clements cleme...@brinckerhoff.org
wrote:
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
this, and I think it should be documented.
Below is a proposed doc change; I'll commit it if you like it, or abandon it
if not. I'm including the (git format-patch) text and also attaching it as a
file.
John
From d3f72c47820effb240532c518378dc9709d69600 Mon Sep 17 00:00:00 2001
From: John Clements cleme...@racket-lang.org
Date: Tue, 1 Jan 2013 10:40:40 -0800
Subject: [PATCH] added docs on requiring planet2 modules
---
collects/planet2/scribblings/planet2.scrbl | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/collects/planet2/scribblings/planet2.scrbl
b/collects/planet2/scribblings/planet2.scrbl
index e9e565a..81d6e58 100644
--- a/collects/planet2/scribblings/planet2.scrbl
+++ b/collects/planet2/scribblings/planet2.scrbl
@@ -200,6 +200,20 @@ imply a change in the @tech{checksum}.
@section{Using Packages}
+Modules installed using planet2 may be @tech{require}d like any other
+modules. For instance, if the package @pkgname{recipes} contains
+the module file @filepath{vegan/fruitsalad.rkt}, then package users
+who have this package installed may evaluate
+
+@racketblock[(require vegan/fruitsalad)]
+
+...to require this module.
+
+@;
+
+@section{Managing Packages}
+
+
The Racket package manager has two user interfaces: a command line
@exec{raco}
sub-command and a library. They have the exact same capabilities, as
the command line interface invokes the library functions and
--
1.7.7.5 (Apple Git-26)
--
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay
The glory of God is Intelligence - DC 93
_
Racket Developers list:
http://lists.racket-lang.org/dev
--
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay
The glory of God is Intelligence - DC 93
--
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay
The glory of God is Intelligence - DC 93
smime.p7s
Description: S/MIME cryptographic signature
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] Five feature/limitation interactions conspire to drive mad
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 properties, so it's hard to stay within these types. Because of this, we try to avoid exposing these types to beginners as much as possible (by, e.g., not having functions in the standard library require them as arguments). The hope is that only experts that are trying to either (1) get every bit of performance our of their programs or (2) enforce strict range properties in their programs actually need to use these types. For the first use case, OC provides some help (and better support is on the way). 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, Exact-Rational, Flonum, Real, and Number, they don't often show up. I expect generalization and covariance have a lot to do with it. Of course, these types caused me trouble immediately because I went looking for them immediately, to get optimizations. It's a happy accident that always using Index for bounds and bounds-checked values works out so well. (Unless you planned it?) This brings me to what I think is the major issue for us n00bs: the types force you to understand the numeric tower really well if you want to use types more precise than `Number'. Before you reach that level of understanding, though, and Typed Racket spits errors at you, it's hard to tell whether it has a legitimate complaint - especially when you don't know whether you should expect, say, (i . fx . 0) to prove i : Positive-Index. Were there specific corners of the tower that you found frustrating (other than fixnum types)? Mostly `sqrt' and `log', when it's hard to prove their arguments are nonnegative. I've gotten around it using `flsqrt' and `fllog'. I was usually working with flonums anyway. One that has bugged me recently is that TR can't prove (* x (conjugate x)) : Nonnegative-Real. I have no idea how you'd do it without turning Number into a product type, though. I almost forgot this one: (/ (ann 5 Nonnegative-Real) (ann 3 Nonnegative-Real)) - : Real 1 2/3 If you want more, you can grep for `assert' in the math library. But it's often really hard to prove that something is nonnegative without an explicit cast, assertion, or test, and thus stay within the reals in expressions with roots. I actually see that as a positive: if a property is too hard to prove using the type system alone, you have the option to use casts, assertions, or tests to help TR prove what you want [1]. Casts, assertions and tests give you extra power to prove things that you couldn't prove otherwise, or to make proofs easier. We should differentiate between what *I* can prove and what *Typed Racket* can prove. I can usually prove more. For example, *I* know that this function preserves types: (: x^2n (Real Positive-Integer - Nonnegative-Real)) (define (x^2n x n) (expt x (* 2 n))) But TR has no concept of even, positive integer. (To be clear, I'm not advocating adding it.) Frustration happens when I know something, but I can't get TR to know it. FWIW, this mismatch doesn't happen very often anymore, probably because I know TR's model of the numeric tower a lot better, and because you've improved Racket's basic math types a lot. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Five feature/limitation interactions conspire to drive mad
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 sometimes because it's just hard. One fine example is `sqrt'. Its types are sensible: (sqrt (ann 5 Real)) - : Number 2.23606797749979 (sqrt (ann 5 Nonnegative-Real)) - : Real [generalized from Nonnegative-Real] 2.23606797749979 But it's often really hard to prove that something is nonnegative without an explicit cast, assertion, or test, and thus stay within the reals in expressions with roots. That's precisely the example with which I launched Vincent on the numerical hierarchy paper. I am not saying I can't program with it. I am saying the desire to prove the exact type -- and knowing that you could do even better -- drives me nuts. So I'd rather program in bliss -- plain old Racket :-) ;; --- I have asked Sam and Vincent to write a chapter in the TR guide on how to program well with numerics and TR. I think you are in an even better position than they are. If you have time, could you distill your experience into some lessons for our Guide? That would be absolutely terrific. (You know what they say about busy men who just completed a large task: ask them, and they will say 'yes'.) Thanks. -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
