FWIW, I don't like that any of these 'in-*' thigns are optional. I was
recently reading over a script that was used to build web pages from
the output of testing runs for my compilers class and there were
several nested for loops without in-* thingies and it was painfully
difficult for me to
On Mon, Apr 18, 2011 at 9:25 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
I often write
(for ([i (in-range N)]) ...)
In cases where the loop overhead is not significant (i.e., I don't care
whether the compiler can tell that I'm iterating through integers),
Or in cases where you're using
I have written (for ([i N]) ..) many times only to remember that it's in-range.
On Apr 18, 2011, at 9:25 AM, Matthew Flatt wrote:
I often write
(for ([i (in-range N)]) ...)
In cases where the loop overhead is not significant (i.e., I don't care
whether the compiler can tell that
On Mon, Apr 18, 2011 at 9:58 AM, Robby Findler
ro...@eecs.northwestern.edu wrote:
I also don't buy Sam's implicit argument for my example. If I had
tried to port this to code to typed racket to just read off the types,
I would have spent far longer as debugging via TR's error messages is
going
9 minutes ago, Matthew Flatt wrote:
Thanks for the clarifications, and I now agree that it's not about
genericity.
I think it's about scripts to programs, though. In a script, not
having to type `(in-range )' or `(in-list )' feels
worthwhile. You make a good point that those
Three minutes ago, Robby Findler wrote:
On Mon, Apr 18, 2011 at 9:59 AM, Eli Barzilay e...@barzilay.org wrote:
9 minutes ago, Matthew Flatt wrote:
Thanks for the clarifications, and I now agree that it's not about
genericity.
I think it's about scripts to programs, though. In a script,
At Mon, 18 Apr 2011 11:04:18 -0400, Eli Barzilay wrote:
An hour and a half ago, Matthew Flatt wrote:
I often write
(for ([i (in-range N)]) ...)
In cases where the loop overhead is not significant (i.e., I don't
care whether the compiler can tell that I'm iterating through
FWIW, it would make sense to me if TR's regexp-match function accepted
only regexps in the first argument (ditto for Racket and then Scracket
could take strings (which of course are hashes mapping integers to
chars)).
Robby
On Mon, Apr 18, 2011 at 10:09 AM, Eli Barzilay e...@barzilay.org wrote:
Two minutes ago, Robby Findler wrote:
FWIW, it would make sense to me if TR's regexp-match function
accepted only regexps in the first argument (ditto for Racket and
then Scracket could take strings (which of course are hashes mapping
integers to chars)).
I think that Sam's usual policy for
On Mon, Apr 18, 2011 at 10:18 AM, Eli Barzilay e...@barzilay.org wrote:
Two minutes ago, Robby Findler wrote:
FWIW, it would make sense to me if TR's regexp-match function
accepted only regexps in the first argument (ditto for Racket and
then Scracket could take strings (which of course are
Which also raises an idea: now that TR is getting going, maybe we
should have another step on this scripts-to-programs slope that is
_lower_ than Racket. A language where we really only have one single
datatype and everything just works on it, hashes being the obvious
one (altho we probably
50 minutes ago, Robby Findler wrote:
On Mon, Apr 18, 2011 at 10:18 AM, Eli Barzilay e...@barzilay.org wrote:
As for Scratchit (obviously the right spelling), it does sound
like a good idea, but the nice thing about the untyped - TR route
is that you get to keep your code, whereas a
I dunno. Do some search again-ing?
On Mon, Apr 18, 2011 at 11:06 AM, Eli Barzilay e...@barzilay.org wrote:
50 minutes ago, Robby Findler wrote:
On Mon, Apr 18, 2011 at 10:18 AM, Eli Barzilay e...@barzilay.org wrote:
As for Scratchit (obviously the right spelling), it does sound
like a good
1. Racket should obviously use S-expressions as the one-and-only data
structure. That's where we come from, and we're different that way.
2. I played with the idea of gluing code like that together some 10 years ago.
The idea was to glue together units (no modules yet) where on one side you
14 matches
Mail list logo