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
-0400 (EDT)
Subject: Re: [racket-dev] Generics scoping issues
Mind you, I don't think this example -- using a method in a #:fast-defaults
predicate -- can work. The implementation of free-box will have to check
the predicate in order to perform generic dispatch, and the predicate has
to call fre
med to do the trick, oddly.
>>> -Ian
>>> ----- Original Message -
>>> From: "Carl Eastlund"
>>> To: "J. Ian Johnson"
>>> Cc: "dev"
>>> Sent: Friday, August 16, 2013 5:23:33 PM GMT -05:00 US/Canada Easter
:39 PM, J. Ian Johnson wrote:
>
>> WRT the struct abstraction, using syntax-local-introduce on
>> #'gen:binds-variables seemed to do the trick, oddly.
>> -Ian
>> - Original Message -
>> From: "Carl Eastlund"
>> To: "J. Ian Johnson
iables seemed to do the trick, oddly.
> -Ian
> - Original Message -
> From: "Carl Eastlund"
> To: "J. Ian Johnson"
> Cc: "dev"
> Sent: Friday, August 16, 2013 5:23:33 PM GMT -05:00 US/Canada Eastern
> Subject: Re: [racket-dev] Generic
gen:binds-variables
at: free
in: (define/generic gfree free)
- Original Message -
From: "Carl Eastlund" < c...@ccs.neu.edu >
To: "J. Ian Johnson" < i...@ccs.neu.edu >
Cc: "dev" < dev@racket-lang.org >
Sent: Friday, August 16, 2013 4:
eric: free is not a method of
> generic interfaces gen:binds-variables
> at: free
> in: (define/generic gfree free)
>
>
> - Original Message -
> From: "Carl Eastlund"
> To: "J. Ian Johnson"
> Cc: "dev"
> Sent: Friday, Aug
To: "J. Ian Johnson"
Cc: "dev"
Sent: Friday, August 16, 2013 4:50:53 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Generics scoping issues
Problem 1 -- you have to use define/generic if you want to use the generic
version of something in the context of a set of
Problem 1 -- you have to use define/generic if you want to use the generic
version of something in the context of a set of specific method
implementations. That's by design.
Problem 2 -- what error message or unexpected behavior are you getting?
That should work, it sounds like a bug in define/ge
I'm starting to use generics, and me being myself, I wrote some macros to make
writing method definitions easier.
But, I'm seeing that #:methods seems to rebind method identifiers in a way that
hygiene interferes with.
I would expect to be allowed to do the following two things (problems
annota
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
I just pushed some of my work on generics in response to the mailing list
thread about define/generic. What I pushed includes:
- define-generics now takes keyword arguments in any order, and allows them
before and/or after the method declarations
- #:defaults now works exactly like #:methods; it
I have a long-running branch on github where I've been working on making
the set datatype generic the way dictionaries are, and improving the
generic system to support that effort. Some of the people here at
Northeastern know about it, but I should probably make more people aware of
the work. Thi
At Wed, 9 May 2012 18:13:55 -0400,
Asumu Takikawa wrote:
> Ideally, we would provide similar interfaces for the other generic APIs
> in the tree, such as streams and sequences. However, the existing APIs
> rely on different representations for method tables from the one used by
> unstable/generics,
On 2012-05-09 18:02:04 -0600, Ryan Culpepper wrote:
> See the 'supers' argument to 'make-struct-type-property'.
>
> Create 'real-prop:sequence' that takes a vector (compatible with
> generics library).
>
> Define 'prop:sequence' as a backwards compatibility property that
> takes an old-style implem
On 2012-05-09 19:01:10 -0400, Neil Van Dyke wrote:
> When you say "dictionaries, sequences,", are you including the
> Racket types hash, vector, and list?
Yes, the changes we made to racket/dict will work with hashes, vectors,
and a-lists in the same way it did before. The only difference is when
On 05/09/2012 04:13 PM, Asumu Takikawa wrote:
Hi all,
Racket currently provides several generic extensible data structure APIs
such as dictionaries, sequences, streams, and so on. Unfortunately, each
data structure currently has its own extension API, but no consistent
convention exists: some AP
Asumu Takikawa wrote at 05/09/2012 06:13 PM:
Any thoughts or suggestions?
When you say "dictionaries, sequences,", are you including the Racket
types hash, vector, and list?
If so, would current performance for those Racket types be affected?
And does this have implications for what op
Hi all,
Racket currently provides several generic extensible data structure APIs
such as dictionaries, sequences, streams, and so on. Unfortunately, each
data structure currently has its own extension API, but no consistent
convention exists: some APIs use lists of methods, some use vectors,
etc.
48 matches
Mail list logo
