On Oct 2, 2013, at 4:41 PM, Sam Tobin-Hochstadt wrote:
I think I prefer separate unrelated data structures,
+1
We need to look at other languages and what devs
say about intermingling and/or separating applicative
and stateful data types. Java and Scala seem to provide
particularly bad
On Fri, Oct 4, 2013 at 1:30 PM, Matthias Felleisen matth...@ccs.neu.edu wrote:
Java and Scala seem to provide
particularly bad examples, so perhaps we should not follow
what they do :-)
I know what you mean about Java, but I've heard lots of good things
about the new Scala collections
Eastlund c...@ccs.neu.edu
Cc: Racket Developers dev@racket-lang.org
Sent: Wednesday, October 2, 2013 3:23:07 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Generics updates
Regarding a point from RacketCon, I don't like that gen:set includes
functions like set-add! and set-remove!. I
-lang.org
Sent: Wednesday, October 2, 2013 3:23:07 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Generics updates
Regarding a point from RacketCon, I don't like that gen:set includes
functions like set-add! and set-remove!. I think that sets with
mutations are subclass of get:set
-constructor gen:set-mconstruct.
-Ian
- Original Message -
From: Jay McCarthy jay.mccar...@gmail.com
To: Carl Eastlund c...@ccs.neu.edu
Cc: Racket Developers dev@racket-lang.org
Sent: Wednesday, October 2, 2013 3:23:07 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev
...@gmail.com
To: Carl Eastlund c...@ccs.neu.edu
Cc: Racket Developers dev@racket-lang.org
Sent: Wednesday, October 2, 2013 3:23:07 PM GMT -05:00 US/Canada
Eastern
Subject: Re: [racket-dev] Generics updates
Regarding a point from RacketCon, I don't like that gen:set includes
...@ccs.neu.edu
Cc: Racket Developers dev@racket-lang.org
Sent: Wednesday, October 2, 2013 3:23:07 PM GMT -05:00 US/Canada
Eastern
Subject: Re: [racket-dev] Generics updates
Regarding a point from RacketCon, I don't like that gen:set includes
functions like set-add! and set-remove
Sent: Wednesday, October 2, 2013 3:23:07 PM GMT -05:00 US/Canada
Eastern
Subject: Re: [racket-dev] Generics updates
Regarding a point from RacketCon, I don't like that gen:set includes
functions like set-add! and set-remove!. I think that sets with
mutations are subclass
/Canada
Eastern
Subject: Re: [racket-dev] Generics updates
Regarding a point from RacketCon, I don't like that gen:set includes
functions like set-add! and set-remove!. I think that sets with
mutations are subclass of get:set and we should have a separate
gen:mset (or something
-mconstruct.
-Ian
- Original Message -
From: Jay McCarthy jay.mccar...@gmail.com
To: Carl Eastlund c...@ccs.neu.edu
Cc: Racket Developers dev@racket-lang.org
Sent: Wednesday, October 2, 2013 3:23:07 PM GMT -05:00 US/Canada
Eastern
Subject: Re: [racket-dev
PM GMT -05:00 US/Canada
Eastern
Subject: Re: [racket-dev] Generics updates
Regarding a point from RacketCon, I don't like that gen:set includes
functions like set-add! and set-remove!. I think that sets with
mutations are subclass of get:set and we should have a separate
gen:mset
Eastlund c...@ccs.neu.edu
Cc: Racket Developers dev@racket-lang.org
Sent: Wednesday, October 2, 2013 3:23:07 PM GMT -05:00 US/Canada
Eastern
Subject: Re: [racket-dev] Generics updates
Regarding a point from RacketCon, I don't like that gen:set includes
functions like set-add
At Fri, 2 Aug 2013 15:33:02 -0400,
Carl Eastlund wrote:
[1 text/plain; UTF-8 (7bit)]
On Fri, Aug 2, 2013 at 1:47 PM, Stephen Chang stch...@ccs.neu.edu wrote:
With that in mind, I think it would make sense to move `set-first' and
`set-empty?' to the primitive set (making it clear that
This whole discussion reminds me of the idea of specialization interface
specification. The notion is due to Lamping, I think. Stevie and I read the
paper and his class contracts provide some of the power of SIs but not all. In
particular, they fail to provide the power that seems to be
At Thu, 1 Aug 2013 18:56:08 -0400,
Carl Eastlund wrote:
Ah, yes, set-stream isn't primitive because it can be derived if you have
set-first and either set-rest or set-remove. And I know there are
dependency cycles, this is intentional so that you can implement any one of
several related
With that in mind, I think it would make sense to move `set-first' and
`set-empty?' to the primitive set (making it clear that they are
optional, and can be derived from `set-stream' if need be). With those
two in the primitive set, anything that implements all the primitives
should get all
On Fri, Aug 2, 2013 at 1:47 PM, Stephen Chang stch...@ccs.neu.edu wrote:
With that in mind, I think it would make sense to move `set-first' and
`set-empty?' to the primitive set (making it clear that they are
optional, and can be derived from `set-stream' if need be). With those
two in
Actually, I am realizing that every derived method depends on
set-stream, even the ones that don't document it (ie set-union,
set-union!, set-intersect, set-intersect!, etc), since they use
in-set.
I was in the process of creating a patch for the docs to add the
missing dependencies but I ran
Yes, this is an issue. I kind of vaguely hint at it in the documentation,
and didn't get around to making it an explicit point -- I use the phrase
implements for things that have to be directly implemented, and
supports for sort of transitive implements. I use in-set and things
like it in some
Just played a bit with gen:set. It looks great and in particular the
fallback implementations are very convenient.
One comment: the distinction between primitive methods and derived
methods confused me somewhat. Can you explain the reasoning for
determining which is which?
For example, when I
Hmm. Well, partially, I wasn't sure how to document the methods, because
the relationships are complex, and because we don't have existing
terminology or documentation patterns for this. I'm open to other
suggestions, and especially (though not exclusively) to patches. For the
other part, I
For the other part, I either should have made it as you say -- implement the
primitive ones and you get the others -- or else I should have clearly
documented the relationship somewhere.
You did document the dependencies, but some of them are circular, ie
some derived rely on other derived.
Ah, yes, set-stream isn't primitive because it can be derived if you have
set-first and either set-rest or set-remove. And I know there are
dependency cycles, this is intentional so that you can implement any one of
several related things, but most of them were supposed to go all the way
down to
Would it be better to just remove the primitve / derived distinction,
since it's somewhat artificial, and leave it up to the individual method
descriptions? Is there some better way I should be describing things?
Ok I can see now that there's no easy way to organize the methods.
I think we
No, that doesn't work. If someone implements, say, an efficient subset?
test, then set=? should use that rather than iterating using set-stream
and set-member?. You should use the highest-level methods you can, in
order to get the most out of an implementation. Which is why I made all
the
After some fixes, mostly to contracts and documentation, I've pushed the
new generics and set features to the master branch.
Carl Eastlund
On Tue, Jul 23, 2013 at 11:37 AM, Carl Eastlund c...@ccs.neu.edu wrote:
My work on adding gen:set, and related changes to define-generics and
gen:dict,
I really like the new set features, especially mutable sets and lists as
sets.
Two things i have notices:
* The docs for set-intersect seem a bit mixed up with set-union stuff
* I could not get set-intersect on lists working, what i've tried
- (set-intersect '(1 2 3) '(2 3 4))
; set-add:
Thanks for those pointers, Tobias, I'll get those fixed.
Carl Eastlund
On Wed, Jul 24, 2013 at 1:34 PM, Tobias Hammer tobias.ham...@dlr.de wrote:
I really like the new set features, especially mutable sets and lists as
sets.
Two things i have notices:
* The docs for set-intersect seem a
28 matches
Mail list logo
