On Fri, Oct 4, 2013 at 1:30 PM, Matthias Felleisen 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 framework. Is there somet
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 ex
t; that to reason about my library's behavior" and if mutable sets are a
>>>>> > sub-thing of immutable ones, we might lose that (depending on how things
>>>>> > are
>>>>> > set up).
>>>>> >
>>>>>
gt; > are
>>>> > set up).
>>>> >
>>>> > Robby
>>>> >
>>>> >
>>>> > On Wed, Oct 2, 2013 at 2:57 PM, Jay McCarthy
>>>> > wrote:
>>>> >>
>>>> >> No. Mutable sets would imp
;> >>
> >> >> Jay
> >> >>
> >> >> On Wed, Oct 2, 2013 at 1:31 PM, J. Ian Johnson
> >> >> wrote:
> >> >> > This means I can't interchange between mutable and immutable sets
> for
> >> >> >
the gen:mset interface. Structs can implement any number of
>>> >> generics.
>>> >>
>>> >> Jay
>>> >>
>>> >> On Wed, Oct 2, 2013 at 1:31 PM, J. Ian Johnson
>>> >> wrote:
>>> >> > This means
gt;> >> wrote:
>> >> > This means I can't interchange between mutable and immutable sets for
>> >> > my
>> >> > functions that only need to read generic sets, unless we further
>> >> > subdivide
>> >> > and have gen
, 2013 at 1:31 PM, J. Ian Johnson
>> >> wrote:
>> >> > This means I can't interchange between mutable and immutable sets for
>> >> > my
>> >> > functions that only need to read generic sets, unless we further
>> >> > sub
>> > functions that only need to read generic sets, unless we further
> subdivide
> >> > and have gen:set-query gen:set-constructor gen:set-mconstruct.
> >> >
> >> > -Ian
> >> > - Original Message -
> >> > From: "J
to read generic sets, unless we further subdivide
>> > and have gen:set-query gen:set-constructor gen:set-mconstruct.
>> >
>> > -Ian
>> > - Original Message -
>> > From: "Jay McCarthy"
>> > To: "Carl Eastlund"
>>
> > - Original Message -
> > From: "Jay McCarthy"
> > To: "Carl Eastlund"
> > Cc: "Racket Developers"
> > Sent: Wednesday, October 2, 2013 3:23:07 PM GMT -05:00 US/Canada Eastern
> > Subject: Re: [racket-dev] Generics update
opers"
> 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
> mut
t;Carl Eastlund"
Cc: "Racket Developers"
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
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) interface for mutable versions.
I dislike that an obvious implementation of s
At Fri, 2 Aug 2013 15:33:02 -0400,
Carl Eastlund wrote:
>
> [1 ]
> On Fri, Aug 2, 2013 at 1:47 PM, Stephen Chang 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 b
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 s
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 int
On Fri, Aug 2, 2013 at 1:47 PM, Stephen Chang 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 the primitive
> 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
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 t
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 necessa
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 fallb
> 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 thin
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
> 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 deri
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 eith
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
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 wrote:
> My work on adding gen:set, and related changes to define-generics and
> gen:dict, is ready for rev
Thanks for those pointers, Tobias, I'll get those fixed.
Carl Eastlund
On Wed, Jul 24, 2013 at 1:34 PM, Tobias Hammer 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 bit mixed up with
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: cont
My work on adding gen:set, and related changes to define-generics and
gen:dict, is ready for review and (hopefully) to push to the master
branch. The branch moved in the process of cleaning things up, it's now at:
https://github.com/carl-eastlund/racket/tree/generics-from-scratch
(The "from sc
31 matches
Mail list logo
