I absolutely totally agree. -- Rudoplh, red-nodes raindeer
On Dec 14, 2010, at 8:33 AM, Doug Williams wrote:
> How about Racket II as a unified literate (from the Scribble syntax), typed,
> contracted Racket?
>
> Of all the syntaxes for defining things, the ones from Scribble (e.g.,
> defpr
I was not thinking of unsafe operations.
Jos
> -Original Message-
> From: Vincent St-Amour [mailto:stamo...@ccs.neu.edu]
> Sent: 13 December 2010 18:11
> To: Jos Koot
> Cc: 'Vincent St-Amour'; 'Noel Welsh'; dev@racket-lang.org
> Subject: Re: [rac
How about Racket II as a unified literate (from the Scribble syntax), typed,
contracted Racket?
Of all the syntaxes for defining things, the ones from Scribble (e.g.,
defproc) seems to be the most general since they capture all of the
identifiers (e.g., procedure name, parameter names, keywords),
At Mon, 13 Dec 2010 17:29:11 +0100,
Jos Koot wrote:
> When multiplying any number (nan and inf excepted) by exact 0, should, of
> course produce exact 0.
If you're multiplying an integer that may or may not be zero (say, an
index) by a float, you cannot assume that the result is a float, even
thou
> -Original Message-
> From: Vincent St-Amour [mailto:stamo...@ccs.neu.edu]
> Sent: 13 December 2010 17:01
> To: Jos Koot
> Cc: 'Noel Welsh'; dev@racket-lang.org
> Subject: Re: [racket-dev] (round), etc. in Typed Racket
>
> At Mon, 13 Dec 201
At Mon, 13 Dec 2010 16:43:58 +0100,
Jos Koot wrote:
> Would we not have the same problem with 'rational?'.
> All reals, both exact and inexact ones are rationals (for the obvious reason
> that we cannot represent every irrational number in finite memory)
> Would we not need the same distinction bet
forced to produce an approximation
(as in (sqrt 2)).
When it comes to efficiency, flonums may be preferred, but it is not
difficult to enforce a function to do all its computations with flonums.
Jos
> -Original Message-
> From: Noel Welsh [mailto:noelwe...@gmail.com]
> Sent: 13 De
On Mon, Dec 13, 2010 at 10:17 AM, Noel Welsh wrote:
>
> (More broadly I find the numeric tower more hassle than help. A lot of
> my code cares about efficiency and interacting with C libraries, so
> perhaps I'm atypical.)
While I feel your pain, I think we should try to move beyond the
implicit d
At this point we're just talking about nomenclature. I think round
would still return an inexact integer, as it does at the moment, but
we wouldn't call this an integer.
(More broadly I find the numeric tower more hassle than help. A lot of
my code cares about efficiency and interacting with C lib
> From: dev-boun...@racket-lang.org
> [mailto:dev-boun...@racket-lang.org] On Behalf Of Robby Findler
> Sent: 13 December 2010 14:29
> To: Sam Tobin-Hochstadt
> Cc: dev@racket-lang.org
> Subject: Re: [racket-dev] (round), etc. in Typed Racket
>
> On Sat, Dec 11, 2010
On Mon, Dec 13, 2010 at 1:28 PM, Robby Findler
wrote:
> Also,
> after having that look, I definitely think that if we got to do this
> one over that integer? accepting only exacts is wise; it seems too
> easy to allow inexacts to flow around when you didn't mean to with the
> current definition of
On Sat, Dec 11, 2010 at 9:53 PM, Robby Findler
wrote:
> [ ... talking about changing integer? to only recognize exacts ... ]
> This seems like it would cause far too much breakage to far too much
> code. I certainly wouldn't want to attempt it. Changing TR (as I
> suggest below) seems far easier.
Maybe someone can figure out a sensible way for modules to specify in
which version(s) of the Racket language they are believed to work, and
what to do with that information.
I'm not sure what's sensible. I could see being able to specify "this
module was last developed and working with Racke
At Sun, 12 Dec 2010 20:33:08 -0500,
Eli Barzilay wrote:
> -1 for a `racket2',
I agree.
> but why not change racket to that?
Sounds good to me. #lang racket is young enough that I expect most of
the existing code we're afraid of breaking is still written in #lang
scheme (or mzscheme).
> -- In a
An hour ago, Matthias Felleisen wrote:
>
> This particular change is a good example: You'd have to get used to
> the idea that Integer denotes 'exact integer'. Is this really bad?
>
> Then again, perhaps we should produce a brand new
>
> #lang racket2
>
> that is a true break and develop
>
On Dec 12, 2010, at 7:30 PM, Robby Findler wrote:
> On Sunday, December 12, 2010, Matthias Felleisen wrote:
>>
>> All of this discussion suggests that we start developing RacketII, a
>> language that is a true break from Scheme. Our backward compatibility
>> constraints are just overwhelming
On Sunday, December 12, 2010, Matthias Felleisen wrote:
>
> All of this discussion suggests that we start developing RacketII, a language
> that is a true break from Scheme. Our backward compatibility constraints are
> just overwhelming our knowledge of what we know is 'bad' with Racket in
> re
All of this discussion suggests that we start developing RacketII, a language
that is a true break from Scheme. Our backward compatibility constraints are
just overwhelming our knowledge of what we know is 'bad' with Racket in
relation to other languages.
Perhaps TR is the proper place to sta
On Sun, Dec 12, 2010 at 9:15 AM, Doug Williams
wrote:
> Since Racket is not Scheme anymore, I think revisiting some of the
> annoyances of Scheme should be fair game.
Just to clarify what I wrote before, I certainly agree with this
point. My worry is that this particular change (in the meaning of
Since Racket is not Scheme anymore, I think revisiting some of the
annoyances of Scheme should be fair game. And, certainly the semantics of
integer? is an annoyance. It is useful if you KNOW you are restricted to a
range where floating point CAN exactly represent an integer (|x| < 15 or so)
and yo
On Sun, Dec 12, 2010 at 8:15 AM, Sam Tobin-Hochstadt wrote:
> On Sat, Dec 11, 2010 at 10:53 PM, Robby Findler
> wrote:
>>
>>> Changing Racket is tricky, but I think using the `Integer' type for
>>> something useless (it's not even currently represented in the TR type
>>> system) would be a mistak
On Sat, Dec 11, 2010 at 10:53 PM, Robby Findler
wrote:
>
>> Changing Racket is tricky, but I think using the `Integer' type for
>> something useless (it's not even currently represented in the TR type
>> system) would be a mistake.
>
> Well, the change to TR would be to change "Integer" to "ExactI
On Sat, Dec 11, 2010 at 9:49 PM, Sam Tobin-Hochstadt wrote:
> On Sat, Dec 11, 2010 at 9:47 PM, Robby Findler
> wrote:
>> This seems like an unfortunate naming discrepancy.
>
> I agree. I think the solution is to change Racket, however. From the
> perspective of the type system, inexact integers
On Sat, Dec 11, 2010 at 9:47 PM, Robby Findler
wrote:
> This seems like an unfortunate naming discrepancy.
I agree. I think the solution is to change Racket, however. From the
perspective of the type system, inexact integers are useless - they
have no closure properties, don't obey various laws
This seems like an unfortunate naming discrepancy.
Robby
On Sat, Dec 11, 2010 at 7:52 PM, Vincent St-Amour wrote:
> At Sat, 11 Dec 2010 18:35:17 -0700,
> Petey Aldous wrote:
>> I've discovered what may be a bug in the type system of Typed Racket. The
>> functions that round - (round), (truncate)
At Sat, 11 Dec 2010 18:35:17 -0700,
Petey Aldous wrote:
> I've discovered what may be a bug in the type system of Typed Racket. The
> functions that round - (round), (truncate), (ceiling), etc. are typed as
> Real, not Integer; however, the result of (integer? (round (* 10e15
> (random is consi
I've discovered what may be a bug in the type system of Typed Racket. The
functions that round - (round), (truncate), (ceiling), etc. are typed as
Real, not Integer; however, the result of (integer? (round (* 10e15
(random is consistently true - and the same holds for the other rounding
functio
27 matches
Mail list logo
