No, you recall correctly. We conducted this experiment a long
time ago (w/o inserting else clauses though as far as I recall).
That is, when the code base was small compared to what we have now.
I forgot why the issue came up but there was an additional, external
impetus.
The cond issue also
We have been discussing 'optimistic run' for at least a year. The idea has been
around since the late 80's back then called 'optimistic make' (the OS ran
Makefiles when triggering events occurred so that when you typed 'make', there
was nothing to do). About 10 years ago, we discussed a related
Oops, I hadn't meant to push that to the main repository without consulting
anyone. Hope this change is okay, it seemed weird for read-json to error
instead of producing eof.
Carl Eastlund
On Tue, Oct 2, 2012 at 1:46 PM, wrote:
> cce has updated `master' from 937c901ce7 to bc681836bc.
> http
An off-list discussion spurred by my previous post about IDE's for education
led to the following blue-sky idea:
Suppose there were another pane or window in DrRacket that showed essentially
what we see in Interactions immediately after we click "Run" -- the values of
all the top-level expressi
It looks like this is a result of the way that "libssl" is linked on
OpenBSD. In particular, it seems to not refer to "libcrypto" directly,
and instead depends on "libcrypto" supplying it exports in the global
namespace. Although the Racket `openssl' library does load "libcrypto"
in advance, it doe
Environment: OpenBSD 5.1 amd64
Problem: Many racket programs spams with "undefined symbol" for openssl.
This makes it almost impossible to to read outputs in the console.
**$ drracket
/usr/local/bin/gracket:/usr/lib/libssl.so.17.1: undefined symbol
'X509_EXTENSION_free'
/usr/local/bin/gracke
https://github.com/plt/racket/wiki/Racket2
On Tue, Oct 2, 2012 at 8:22 AM, Matthew Flatt wrote:
> I think this a great change for a future `racket2' (someone should be
> keeping a list of these), but it's too incompatible a change for `cond'
> in `racket'.
>
> At Tue, 2 Oct 2012 09:52:38 -0400, C
On Tue, Oct 2, 2012 at 9:39 AM, Carl Eastlund wrote:
> I'm not surprised, I pretty much expected this response, but I'm curious
> what the difficulty was. Is cond-as-void relied on that much more
> pervasively than mutable pairs?
I'm not sure I can comment on the relative reliance, but in the ca
I'm not surprised, I pretty much expected this response, but I'm curious
what the difficulty was. Is cond-as-void relied on that much more
pervasively than mutable pairs? Is it exceedingly hard to add else-clauses
to all the necessary conds? You two, Robby and Matthew, probably have a
better ide
IIRC, we even experimented with this one briefly and quickly gave up
as we got overwhelmed.
Robby
On Tue, Oct 2, 2012 at 9:22 AM, Matthew Flatt wrote:
> I think this a great change for a future `racket2' (someone should be
> keeping a list of these), but it's too incompatible a change for `cond'
I think this a great change for a future `racket2' (someone should be
keeping a list of these), but it's too incompatible a change for `cond'
in `racket'.
At Tue, 2 Oct 2012 09:52:38 -0400, Carl Eastlund wrote:
> I often wish cond would raise an exception if all the tests failed and
> there were n
Let's not piggy-back too much on this one change. First of all, I'm
proposing a very simple change, albeit with potentially complex
consequences; you've got a somewhat more complex design change in mind, but
entirely backwards compatible. Second, you detect definitions by using
"define" as a keyw
In addition to this, I want internal definitions in conds:
(cond
[test1 body1]
(define var ...)
[(test2 var) body2]
[(test3 var) body3])
I have a macro that does these things:
https://github.com/jeapostrophe/exp/blob/master/condd.rkt
It's pretty cute
Jay
On Tue, Oct 2, 2012 at 7:58 AM, Ca
The high level is that the predicate with identifier given by
build-struct-names should have the same purity/predicate properties of
something like string?. As for not, it's just an alias for false?, so it should
have the same info again.
-Ian
- Original Message -
From: "Sam Tobin-Hochst
On Tue, Oct 2, 2012 at 9:55 AM, J. Ian Johnson wrote:
> This surprises me, since not and make-struct-type are in '#%kernel, they
> should have this kind of information baked in, without a purity analysis.
If you're suggesting that the Racket compiler should perform the
purity analysis, then that
Oh, no, as far as a "does it work out of the box" experiment goes, it
fails. Racket doesn't even compile. I meant more along the lines of our
immutable-cons experiment, where we fix a bunch of code and see how
problematic the compatibility issue becomes over time.
Carl Eastlund
On Tue, Oct 2, 2
This experiment should be easy to run, no? Change the default cond and run DrDr?
-Ian
- Original Message -
From: "Carl Eastlund"
To: "Racket Developers"
Sent: Tuesday, October 2, 2012 9:52:38 AM GMT -05:00 US/Canada Eastern
Subject: [racket-dev] Falling through cond clauses
I often wish
This surprises me, since not and make-struct-type are in '#%kernel, they should
have this kind of information baked in, without a purity analysis.
-Ian
- Original Message -
From: "Sam Tobin-Hochstadt"
To: "Neil Toronto"
Cc: ""
Sent: Tuesday, October 2, 2012 9:44:13 AM GMT -05:00 US/Cana
I often wish cond would raise an exception if all the tests failed and
there were no else clause. I have taken to writing a macro to enforce
this; I usually call it cond!. The void default for cond seems like an
un-Racketish holdover from primarily-imperative programming. With some of
the other
On Mon, Oct 1, 2012 at 9:44 PM, Neil Toronto wrote:
> The only bit that bothers me is the (begin (not (flonum-wrapper? x)) ...)
> stuff left lying around after TR's optimizer eliminates the branches in the
> expansions of `fw+'. IIRC, they cause futures to sync, but I'm going to
> believe that the
20 matches
Mail list logo
