Hi Stephen,
As an educational side project, I've been toying around with a
different way of organizing all the binding forms. What I wanted to do
is remove the need to manually combine current (and future) binding
forms by moving the binding logic to the binding site itself.
Your goals seem
On Sun, Aug 25, 2013 at 10:54 PM, Stephen Chang stch...@ccs.neu.edu wrote:
Hi dev,
I've noticed that Racket has a lot of convenient binding forms but
they don't fit together unless someone does it manually (for example
there's match-let and match-let-values, but no match-for).
As an
On Mon, Aug 26, 2013 at 6:46 AM, Sam Tobin-Hochstadt
sa...@cs.indiana.edu wrote:
On Fri, Aug 23, 2013 at 2:48 PM, Jay McCarthy jay.mccar...@gmail.com
wrote:
I feel that the only thing it could do better is support two more
options for #:data:
- A input-port? to read from and copy to the
I've been wanting a match-for for quite some time, but there are design
decisions to be made in such cases. Non-linear patterns are tricky to
coordinate - should all clauses of a for/fold be considered part of the same
match pattern? How about for*/fold? (My opinions are yes then no). If you
What are the performance implications of this design? Specifically how do
overlapping uses fare in the two systems? Microbenchmarks okay for now. --
Matthias
On Aug 26, 2013, at 12:54 AM, Stephen Chang wrote:
Hi dev,
I've noticed that Racket has a lot of convenient binding forms but
I like this, except now the hash sets have too little exposed. There isn't a
special sequence-syntax that I can get a hold of for faster iteration when I
know the type of data I'm working with.
-Ian
- Original Message -
From: Matthias Felleisen matth...@ccs.neu.edu
To: Carl Eastlund
6 matches
Mail list logo
