40 minutes ago, Matthew Flatt wrote:
> I agree about changing `when', `unless', and `cond'.
>
> I can't see changing `begin', especially now that
> internal-definition contexts allow a mixture of definitions and
> expressions. Unlike changing `when' and `unless', changing `begin'
> could change so
At Sun, 10 Oct 2010 11:27:36 -0400, Neil Van Dyke wrote:
> If "#true" and "#false" were just alternative read syntax for "#t" and
> "#f", and they always printed as "#t" and "#f" (except perhaps in
> teaching languages), that would make me happiest.
That's what we have now in v5.0.1.8. From the
I agree about changing `when', `unless', and `cond'.
I can't see changing `begin', especially now that internal-definition
contexts allow a mixture of definitions and expressions. Unlike
changing `when' and `unless', changing `begin' could change some
existing programs, such as
(let ()
(begin
6 hours ago, Neil Toronto wrote:
> Also, I could do
>
> (if
> (begin (define ...) ...)
> ...)
>
> instead of the current (and very ugly)
>
> (if
> (let ()
>(define ...) ...)
> ...)
>
> which I've been doing a lot more now that I can mi
Yesterday, Robby Findler wrote:
>
> Maybe you're saying that people would be confused by that error?
> Woudln't that already happen with
>
> (define (foo x) (define x (add1 x)) x)
>
> ?
Yes, they would. I just think that overall more newbies fall for the
trap of trying a conditional definition
On Mon, Oct 11, 2010 at 2:10 PM, Joe Marshall wrote:
> On Mon, Oct 11, 2010 at 9:59 AM, Neil Toronto wrote:
>> If I get a vote, +1/2 from me.
>>
>> My vote isn't +1 because I'd rather see a syntactic restriction removed:
>> make the inside of a `begin' an internal definition context. Then the cha
At Mon, 11 Oct 2010 13:28:38 -0600, Neil Toronto wrote:
> I also sent bug reports.
Thanks!
> The one that's killing me is the Delete key
> not working. Is there something I can do now to make it work?
That one is now fixed in the git repo.
> I don't
> want to have to wait until after you're d
Matthew Flatt wrote:
The new implementation of `racket/gui' is about as usable as my last
report a month ago, at least for Gtk and Cocoa. Bug reports are still
welcome. Editor performance has improved (thanks to Robby and Sam for
testing and feedback), but not much else changed for Gtk and Cocoa,
On Mon, Oct 11, 2010 at 12:05 PM, Sam Tobin-Hochstadt wrote:
> Today, I started having repeated segfaults while running gracket.
This went away after a cleaner clean rebuild.
--
sam th
sa...@ccs.neu.edu
_
For list-related administrative tasks:
On Mon, Oct 11, 2010 at 9:59 AM, Neil Toronto wrote:
> If I get a vote, +1/2 from me.
>
> My vote isn't +1 because I'd rather see a syntactic restriction removed:
> make the inside of a `begin' an internal definition context. Then the change
> would happen in every similar macro at once.
>
> Woul
The new implementation of `racket/gui' is about as usable as my last
report a month ago, at least for Gtk and Cocoa. Bug reports are still
welcome. Editor performance has improved (thanks to Robby and Sam for
testing and feedback), but not much else changed for Gtk and Cocoa,
because I shifted my a
If I get a vote, +1/2 from me.
My vote isn't +1 because I'd rather see a syntactic restriction removed:
make the inside of a `begin' an internal definition context. Then the
change would happen in every similar macro at once.
Also, I could do
(if
(begin (define ...) ...)
Today, I started having repeated segfaults while running gracket. I
tried a clean rebuild, to no avail. Here's the backtrace, obtained by
1. Starting gracket under GDB.
2. Clicking the window close button.
I'm happy to try to bisect this if it would help. This is on Ubuntu 10.04.
[Thread debu
13 matches
Mail list logo
