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
On Mon, Oct 11, 2010 at 9:59 AM, Neil Toronto neil.toro...@gmail.com 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
On Mon, Oct 11, 2010 at 2:10 PM, Joe Marshall jmarsh...@alum.mit.edu wrote:
On Mon, Oct 11, 2010 at 9:59 AM, Neil Toronto neil.toro...@gmail.com 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
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, 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 response in
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 some
6 matches
Mail list logo
