Re: [racket-dev] Lists aren't sets, but have set-like operations
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" To: "Carl Eastlund" Cc: "J. Ian Johnson" , "Racket Developers" Sent: Thursday, August 22, 2013 2:47:44 PM GMT -05:00 US/Canada Eastern Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations On Aug 22, 2013, at 2:31 PM, Carl Eastlund wrote: Here's what I propose to do now: - rename set? to generic-set?; this predicate recognizes the new all-inclusive generic set type - rename set-immutable? to set?; this predicate recognizes the pre-existing immutable hash set type - leave set-mutable? and set-weak? alone; they recognize the other two hash set types (on the mutability axis) - allow multiple-set operations to combine equal-based hash sets and lists, since both use equal? for equality Sounds like the right direction to me. -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Lists aren't sets, but have set-like operations
On Aug 22, 2013, at 2:31 PM, Carl Eastlund wrote: > > Here's what I propose to do now: > > - rename set? to generic-set?; this predicate recognizes the new > all-inclusive generic set type > - rename set-immutable? to set?; this predicate recognizes the pre-existing > immutable hash set type > - leave set-mutable? and set-weak? alone; they recognize the other two hash > set types (on the mutability axis) > - allow multiple-set operations to combine equal-based hash sets and lists, > since both use equal? for equality Sounds like the right direction to me. -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Lists aren't sets, but have set-like operations
I think it is a good idea to let multiple kinds of sets interact, but at the time I implemented all this I wasn't sure exactly how to make it work, so I took a conservative approach -- make it an error now; then we can make it a non-error later any way we want, without constraint. I don't want to give the impression I'm against interoperation. Here's what I propose to do now: - rename set? to generic-set?; this predicate recognizes the new all-inclusive generic set type - rename set-immutable? to set?; this predicate recognizes the pre-existing immutable hash set type - leave set-mutable? and set-weak? alone; they recognize the other two hash set types (on the mutability axis) - allow multiple-set operations to combine equal-based hash sets and lists, since both use equal? for equality I don't know how to make other user-defined types recognize when they share a notion of equality. I'm not 100% sure that rejecting these operations when sets don't share a notion of equality is actually the right thing to do; sometimes it's best to just let the user take responsibility for whether putting the elements of one set into another will have meaningful results. But that restriction is documented and predates my changes, so I'm leaving it in unless someone wants to propose a better way. That means rejecting all other kinds of sets beyond hash sets and lists for union, intersection, etc. Carl Eastlund On Thu, Aug 22, 2013 at 12:27 PM, Matthias Felleisen wrote: > > I can see why an eq-set and an eqv-set can't be union-ed without > additional information about the desired result type. > > But if we had two different implementation of the eq-set API we could > easily define unions as derived code; that's the point of OO. > > > > > > > On Aug 22, 2013, at 12:14 PM, Carl Eastlund wrote: > > Set-union never worked for even different hash set representations. Even > before I touched the code, the union of an eq set and an eqv set, for > instance, caused a runtime error. > > Generics do not have multiple dispatch. That's not a mechanism we have > right now. And "fallbacks" are for when there's no method implemented for > a given receiver value, they're not particularly related to a question of > "are these things the same type". > > I chose to keep the semantics that union and operations like it only work > with the same representation. Partly because that's how things already > were, and partly to set the precedent that generics authors don't have to > write two versions of every method. Perhaps this wasn't the best idiom, > but it's what I wrote. Perhaps there's a better idiom for fallbacks that > makes this work more cleanly. Anyway, right now, generic sets are designed > so you can use any one representation, but they don't combine > representations. > > Carl Eastlund > > > On Thu, Aug 22, 2013 at 9:03 AM, J. Ian Johnson wrote: > >> No, it doesn't seem to be using the fallback in this case. >> >> ianj@sampson:~/racket/racket/bin$ ./racket -il xrepl >> Welcome to Racket v5.90.0.8. >> -> (set-union '() (set)) >> ; in-list: contract violation >> ; expected: list? >> ; given: (set) >> ; [,bt for context] >> -> >> >> -Ian >> - Original Message - >> From: "Sam Tobin-Hochstadt" >> To: "J. Ian Johnson" , "Carl Eastlund" > > >> Cc: dev@racket-lang.org, "Matthew Flatt" >> Sent: Thursday, August 22, 2013 8:51:30 AM GMT -05:00 US/Canada Eastern >> Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations >> >> Wait, `set-union` of two different set representations doesn't work? >> >> Sam >> >> On Thu, Aug 22, 2013 at 8:07 AM, J. Ian Johnson wrote: >> > You misunderstand. I used set-union, but single dispatch saw '() and >> used list-union for the '() (set) combination. >> > -Ian >> > - Original Message - >> > From: "Sam Tobin-Hochstadt" >> > To: "J. Ian Johnson" >> > Cc: dev@racket-lang.org, "Matthew Flatt" >> > Sent: Thursday, August 22, 2013 8:02:50 AM GMT -05:00 US/Canada Eastern >> > Subject: Re: [racket-dev] Lists aren't sets, but have set-like >> operations >> > >> > >> > >> > But 'list-union' is not a generic operation so it isn't surprising that >> this didn't work. To do this generically, you'd need to use 'set-union'. >> > >> > Sam >> > On Aug 22, 2013 7:59 AM, "J. Ian Johnson" &
Re: [racket-dev] Lists aren't sets, but have set-like operations
The implementation of set-union for hash sets would be unnecessarily slow if that's how I wrote it. It's faster to extract the hash tables and operate directly on those. It's even faster still to find the largest immutable hash table in the argument list and start from that. On top of that, the operation is specified, since before my changes, to go through the arguments and reject any hash sets that use a different notion of equality, so that the output of set-union has a meaningful semantics. For an arbitrary other set representation, I don't necessarily know what the notion of equality is. So currently, I just reject all of them. Carl Eastlund On Thu, Aug 22, 2013 at 1:52 PM, Jay McCarthy wrote: > I find this an unsatisfying consequence of the implementation and not > necessary. For instance, you could implement set-union purely > generically as: > > (define (set-union a b) > (for/fold ([a a]) ([e (in-set b)]) (set-add a e))) > > and then it would work for everything. Right? > > Jay > > On Thu, Aug 22, 2013 at 10:14 AM, Carl Eastlund wrote: > > Set-union never worked for even different hash set representations. Even > > before I touched the code, the union of an eq set and an eqv set, for > > instance, caused a runtime error. > > > > Generics do not have multiple dispatch. That's not a mechanism we have > > right now. And "fallbacks" are for when there's no method implemented > for a > > given receiver value, they're not particularly related to a question of > "are > > these things the same type". > > > > I chose to keep the semantics that union and operations like it only work > > with the same representation. Partly because that's how things already > > were, and partly to set the precedent that generics authors don't have to > > write two versions of every method. Perhaps this wasn't the best idiom, > but > > it's what I wrote. Perhaps there's a better idiom for fallbacks that > makes > > this work more cleanly. Anyway, right now, generic sets are designed so > you > > can use any one representation, but they don't combine representations. > > > > Carl Eastlund > > > > > > On Thu, Aug 22, 2013 at 9:03 AM, J. Ian Johnson > wrote: > >> > >> No, it doesn't seem to be using the fallback in this case. > >> > >> ianj@sampson:~/racket/racket/bin$ ./racket -il xrepl > >> Welcome to Racket v5.90.0.8. > >> -> (set-union '() (set)) > >> ; in-list: contract violation > >> ; expected: list? > >> ; given: (set) > >> ; [,bt for context] > >> -> > >> > >> -Ian > >> - Original Message - > >> From: "Sam Tobin-Hochstadt" > >> To: "J. Ian Johnson" , "Carl Eastlund" < > c...@ccs.neu.edu> > >> Cc: dev@racket-lang.org, "Matthew Flatt" > >> Sent: Thursday, August 22, 2013 8:51:30 AM GMT -05:00 US/Canada Eastern > >> Subject: Re: [racket-dev] Lists aren't sets, but have set-like > operations > >> > >> Wait, `set-union` of two different set representations doesn't work? > >> > >> Sam > >> > >> On Thu, Aug 22, 2013 at 8:07 AM, J. Ian Johnson > wrote: > >> > You misunderstand. I used set-union, but single dispatch saw '() and > >> > used list-union for the '() (set) combination. > >> > -Ian > >> > - Original Message - > >> > From: "Sam Tobin-Hochstadt" > >> > To: "J. Ian Johnson" > >> > Cc: dev@racket-lang.org, "Matthew Flatt" > >> > Sent: Thursday, August 22, 2013 8:02:50 AM GMT -05:00 US/Canada > Eastern > >> > Subject: Re: [racket-dev] Lists aren't sets, but have set-like > >> > operations > >> > > >> > > >> > > >> > But 'list-union' is not a generic operation so it isn't surprising > that > >> > this didn't work. To do this generically, you'd need to use > 'set-union'. > >> > > >> > Sam > >> > On Aug 22, 2013 7:59 AM, "J. Ian Johnson" < i...@ccs.neu.edu > wrote: > >> > > >> > > >> > The problem manifested itself when I got an exception that in-list > can't > >> > be called on (set), which really confused me. (set? '()) answered > true, so > >> > it tried to do (list-union '() (set)), which failed. > >> > Generi
Re: [racket-dev] Lists aren't sets, but have set-like operations
I find this an unsatisfying consequence of the implementation and not necessary. For instance, you could implement set-union purely generically as: (define (set-union a b) (for/fold ([a a]) ([e (in-set b)]) (set-add a e))) and then it would work for everything. Right? Jay On Thu, Aug 22, 2013 at 10:14 AM, Carl Eastlund wrote: > Set-union never worked for even different hash set representations. Even > before I touched the code, the union of an eq set and an eqv set, for > instance, caused a runtime error. > > Generics do not have multiple dispatch. That's not a mechanism we have > right now. And "fallbacks" are for when there's no method implemented for a > given receiver value, they're not particularly related to a question of "are > these things the same type". > > I chose to keep the semantics that union and operations like it only work > with the same representation. Partly because that's how things already > were, and partly to set the precedent that generics authors don't have to > write two versions of every method. Perhaps this wasn't the best idiom, but > it's what I wrote. Perhaps there's a better idiom for fallbacks that makes > this work more cleanly. Anyway, right now, generic sets are designed so you > can use any one representation, but they don't combine representations. > > Carl Eastlund > > > On Thu, Aug 22, 2013 at 9:03 AM, J. Ian Johnson wrote: >> >> No, it doesn't seem to be using the fallback in this case. >> >> ianj@sampson:~/racket/racket/bin$ ./racket -il xrepl >> Welcome to Racket v5.90.0.8. >> -> (set-union '() (set)) >> ; in-list: contract violation >> ; expected: list? >> ; given: (set) >> ; [,bt for context] >> -> >> >> -Ian >> - Original Message ----- >> From: "Sam Tobin-Hochstadt" >> To: "J. Ian Johnson" , "Carl Eastlund" >> Cc: dev@racket-lang.org, "Matthew Flatt" >> Sent: Thursday, August 22, 2013 8:51:30 AM GMT -05:00 US/Canada Eastern >> Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations >> >> Wait, `set-union` of two different set representations doesn't work? >> >> Sam >> >> On Thu, Aug 22, 2013 at 8:07 AM, J. Ian Johnson wrote: >> > You misunderstand. I used set-union, but single dispatch saw '() and >> > used list-union for the '() (set) combination. >> > -Ian >> > - Original Message - >> > From: "Sam Tobin-Hochstadt" >> > To: "J. Ian Johnson" >> > Cc: dev@racket-lang.org, "Matthew Flatt" >> > Sent: Thursday, August 22, 2013 8:02:50 AM GMT -05:00 US/Canada Eastern >> > Subject: Re: [racket-dev] Lists aren't sets, but have set-like >> > operations >> > >> > >> > >> > But 'list-union' is not a generic operation so it isn't surprising that >> > this didn't work. To do this generically, you'd need to use 'set-union'. >> > >> > Sam >> > On Aug 22, 2013 7:59 AM, "J. Ian Johnson" < i...@ccs.neu.edu > wrote: >> > >> > >> > The problem manifested itself when I got an exception that in-list can't >> > be called on (set), which really confused me. (set? '()) answered true, so >> > it tried to do (list-union '() (set)), which failed. >> > Generic sets as they are don't work generically. Some action should be >> > taken. Either set? means what it once did, or we do some awfully slow >> > multiple dispatch for set operations. My bias shows. >> > -Ian >> > - Original Message - >> > From: "Matthew Flatt" < mfl...@cs.utah.edu > >> > To: "Carl Eastlund" < c...@ccs.neu.edu > >> > Cc: "J. Ian Johnson" < i...@ccs.neu.edu >, "dev" < dev@racket-lang.org > >> > Sent: Thursday, August 22, 2013 7:22:25 AM GMT -05:00 US/Canada Eastern >> > Subject: Re: [racket-dev] Lists aren't sets, but have set-like >> > operations >> > >> > How much should we prioritize backward compatibility in this case? >> > >> > One possibility is to make `set?' mean `hash-set?', and add >> > `generic-set?' in place of the current `set?'. That's uglier, >> > obviously, but it would be better if we want to prioritize backward >> > compatibility. >> > >> > At Wed, 21 Aug 2013 19:14:06 -0400, Carl Eastlund wrote: >> >> A
Re: [racket-dev] Lists aren't sets, but have set-like operations
I can see why an eq-set and an eqv-set can't be union-ed without additional information about the desired result type. But if we had two different implementation of the eq-set API we could easily define unions as derived code; that's the point of OO. On Aug 22, 2013, at 12:14 PM, Carl Eastlund wrote: > Set-union never worked for even different hash set representations. Even > before I touched the code, the union of an eq set and an eqv set, for > instance, caused a runtime error. > > Generics do not have multiple dispatch. That's not a mechanism we have right > now. And "fallbacks" are for when there's no method implemented for a given > receiver value, they're not particularly related to a question of "are these > things the same type". > > I chose to keep the semantics that union and operations like it only work > with the same representation. Partly because that's how things already were, > and partly to set the precedent that generics authors don't have to write two > versions of every method. Perhaps this wasn't the best idiom, but it's what > I wrote. Perhaps there's a better idiom for fallbacks that makes this work > more cleanly. Anyway, right now, generic sets are designed so you can use > any one representation, but they don't combine representations. > > Carl Eastlund > > > On Thu, Aug 22, 2013 at 9:03 AM, J. Ian Johnson wrote: > No, it doesn't seem to be using the fallback in this case. > > ianj@sampson:~/racket/racket/bin$ ./racket -il xrepl > Welcome to Racket v5.90.0.8. > -> (set-union '() (set)) > ; in-list: contract violation > ; expected: list? > ; given: (set) > ; [,bt for context] > -> > > -Ian > - Original Message - > From: "Sam Tobin-Hochstadt" > To: "J. Ian Johnson" , "Carl Eastlund" > Cc: dev@racket-lang.org, "Matthew Flatt" > Sent: Thursday, August 22, 2013 8:51:30 AM GMT -05:00 US/Canada Eastern > Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations > > Wait, `set-union` of two different set representations doesn't work? > > Sam > > On Thu, Aug 22, 2013 at 8:07 AM, J. Ian Johnson wrote: > > You misunderstand. I used set-union, but single dispatch saw '() and used > > list-union for the '() (set) combination. > > -Ian > > - Original Message - > > From: "Sam Tobin-Hochstadt" > > To: "J. Ian Johnson" > > Cc: dev@racket-lang.org, "Matthew Flatt" > > Sent: Thursday, August 22, 2013 8:02:50 AM GMT -05:00 US/Canada Eastern > > Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations > > > > > > > > But 'list-union' is not a generic operation so it isn't surprising that > > this didn't work. To do this generically, you'd need to use 'set-union'. > > > > Sam > > On Aug 22, 2013 7:59 AM, "J. Ian Johnson" < i...@ccs.neu.edu > wrote: > > > > > > The problem manifested itself when I got an exception that in-list can't be > > called on (set), which really confused me. (set? '()) answered true, so it > > tried to do (list-union '() (set)), which failed. > > Generic sets as they are don't work generically. Some action should be > > taken. Either set? means what it once did, or we do some awfully slow > > multiple dispatch for set operations. My bias shows. > > -Ian > > - Original Message - > > From: "Matthew Flatt" < mfl...@cs.utah.edu > > > To: "Carl Eastlund" < c...@ccs.neu.edu > > > Cc: "J. Ian Johnson" < i...@ccs.neu.edu >, "dev" < dev@racket-lang.org > > > Sent: Thursday, August 22, 2013 7:22:25 AM GMT -05:00 US/Canada Eastern > > Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations > > > > How much should we prioritize backward compatibility in this case? > > > > One possibility is to make `set?' mean `hash-set?', and add > > `generic-set?' in place of the current `set?'. That's uglier, > > obviously, but it would be better if we want to prioritize backward > > compatibility. > > > > At Wed, 21 Aug 2013 19:14:06 -0400, Carl Eastlund wrote: > >> Ah, yes. The set? predicate no longer distinguishes a representation. > >> There are several predicates for the original set type, now called "hash > >> sets": set-eq?, set-eqv?, set-equal?, set-mutable?, set-immtuable?, and > >> set-weak?. I did
Re: [racket-dev] Lists aren't sets, but have set-like operations
Set-union never worked for even different hash set representations. Even before I touched the code, the union of an eq set and an eqv set, for instance, caused a runtime error. Generics do not have multiple dispatch. That's not a mechanism we have right now. And "fallbacks" are for when there's no method implemented for a given receiver value, they're not particularly related to a question of "are these things the same type". I chose to keep the semantics that union and operations like it only work with the same representation. Partly because that's how things already were, and partly to set the precedent that generics authors don't have to write two versions of every method. Perhaps this wasn't the best idiom, but it's what I wrote. Perhaps there's a better idiom for fallbacks that makes this work more cleanly. Anyway, right now, generic sets are designed so you can use any one representation, but they don't combine representations. Carl Eastlund On Thu, Aug 22, 2013 at 9:03 AM, J. Ian Johnson wrote: > No, it doesn't seem to be using the fallback in this case. > > ianj@sampson:~/racket/racket/bin$ ./racket -il xrepl > Welcome to Racket v5.90.0.8. > -> (set-union '() (set)) > ; in-list: contract violation > ; expected: list? > ; given: (set) > ; [,bt for context] > -> > > -Ian > - Original Message - > From: "Sam Tobin-Hochstadt" > To: "J. Ian Johnson" , "Carl Eastlund" > Cc: dev@racket-lang.org, "Matthew Flatt" > Sent: Thursday, August 22, 2013 8:51:30 AM GMT -05:00 US/Canada Eastern > Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations > > Wait, `set-union` of two different set representations doesn't work? > > Sam > > On Thu, Aug 22, 2013 at 8:07 AM, J. Ian Johnson wrote: > > You misunderstand. I used set-union, but single dispatch saw '() and > used list-union for the '() (set) combination. > > -Ian > > ----- Original Message ----- > > From: "Sam Tobin-Hochstadt" > > To: "J. Ian Johnson" > > Cc: dev@racket-lang.org, "Matthew Flatt" > > Sent: Thursday, August 22, 2013 8:02:50 AM GMT -05:00 US/Canada Eastern > > Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations > > > > > > > > But 'list-union' is not a generic operation so it isn't surprising that > this didn't work. To do this generically, you'd need to use 'set-union'. > > > > Sam > > On Aug 22, 2013 7:59 AM, "J. Ian Johnson" < i...@ccs.neu.edu > wrote: > > > > > > The problem manifested itself when I got an exception that in-list can't > be called on (set), which really confused me. (set? '()) answered true, so > it tried to do (list-union '() (set)), which failed. > > Generic sets as they are don't work generically. Some action should be > taken. Either set? means what it once did, or we do some awfully slow > multiple dispatch for set operations. My bias shows. > > -Ian > > - Original Message - > > From: "Matthew Flatt" < mfl...@cs.utah.edu > > > To: "Carl Eastlund" < c...@ccs.neu.edu > > > Cc: "J. Ian Johnson" < i...@ccs.neu.edu >, "dev" < dev@racket-lang.org > > > Sent: Thursday, August 22, 2013 7:22:25 AM GMT -05:00 US/Canada Eastern > > Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations > > > > How much should we prioritize backward compatibility in this case? > > > > One possibility is to make `set?' mean `hash-set?', and add > > `generic-set?' in place of the current `set?'. That's uglier, > > obviously, but it would be better if we want to prioritize backward > > compatibility. > > > > At Wed, 21 Aug 2013 19:14:06 -0400, Carl Eastlund wrote: > >> Ah, yes. The set? predicate no longer distinguishes a representation. > >> There are several predicates for the original set type, now called "hash > >> sets": set-eq?, set-eqv?, set-equal?, set-mutable?, set-immtuable?, and > >> set-weak?. I didn't add the basic "hash-set?", but perhaps I should. > It's > >> a weird name, since "hash-set" and "hash-set!" are already existing, > >> unrelated functions. > >> > >> Carl Eastlund > >> > >> > >> On Wed, Aug 21, 2013 at 7:08 PM, J. Ian Johnson < i...@ccs.neu.edu > > wrote: > >> > >> > Okay, I can abide. However, that doesn't really
Re: [racket-dev] Lists aren't sets, but have set-like operations
No, it doesn't seem to be using the fallback in this case. ianj@sampson:~/racket/racket/bin$ ./racket -il xrepl Welcome to Racket v5.90.0.8. -> (set-union '() (set)) ; in-list: contract violation ; expected: list? ; given: (set) ; [,bt for context] -> -Ian - Original Message - From: "Sam Tobin-Hochstadt" To: "J. Ian Johnson" , "Carl Eastlund" Cc: dev@racket-lang.org, "Matthew Flatt" Sent: Thursday, August 22, 2013 8:51:30 AM GMT -05:00 US/Canada Eastern Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations Wait, `set-union` of two different set representations doesn't work? Sam On Thu, Aug 22, 2013 at 8:07 AM, J. Ian Johnson wrote: > You misunderstand. I used set-union, but single dispatch saw '() and used > list-union for the '() (set) combination. > -Ian > - Original Message - > From: "Sam Tobin-Hochstadt" > To: "J. Ian Johnson" > Cc: dev@racket-lang.org, "Matthew Flatt" > Sent: Thursday, August 22, 2013 8:02:50 AM GMT -05:00 US/Canada Eastern > Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations > > > > But 'list-union' is not a generic operation so it isn't surprising that this > didn't work. To do this generically, you'd need to use 'set-union'. > > Sam > On Aug 22, 2013 7:59 AM, "J. Ian Johnson" < i...@ccs.neu.edu > wrote: > > > The problem manifested itself when I got an exception that in-list can't be > called on (set), which really confused me. (set? '()) answered true, so it > tried to do (list-union '() (set)), which failed. > Generic sets as they are don't work generically. Some action should be taken. > Either set? means what it once did, or we do some awfully slow multiple > dispatch for set operations. My bias shows. > -Ian > - Original Message - > From: "Matthew Flatt" < mfl...@cs.utah.edu > > To: "Carl Eastlund" < c...@ccs.neu.edu > > Cc: "J. Ian Johnson" < i...@ccs.neu.edu >, "dev" < dev@racket-lang.org > > Sent: Thursday, August 22, 2013 7:22:25 AM GMT -05:00 US/Canada Eastern > Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations > > How much should we prioritize backward compatibility in this case? > > One possibility is to make `set?' mean `hash-set?', and add > `generic-set?' in place of the current `set?'. That's uglier, > obviously, but it would be better if we want to prioritize backward > compatibility. > > At Wed, 21 Aug 2013 19:14:06 -0400, Carl Eastlund wrote: >> Ah, yes. The set? predicate no longer distinguishes a representation. >> There are several predicates for the original set type, now called "hash >> sets": set-eq?, set-eqv?, set-equal?, set-mutable?, set-immtuable?, and >> set-weak?. I didn't add the basic "hash-set?", but perhaps I should. It's >> a weird name, since "hash-set" and "hash-set!" are already existing, >> unrelated functions. >> >> Carl Eastlund >> >> >> On Wed, Aug 21, 2013 at 7:08 PM, J. Ian Johnson < i...@ccs.neu.edu > wrote: >> >> > Okay, I can abide. However, that doesn't really get at my frustration. I'm >> > using the set constructor, that appears to now be an immutable-custom-set >> > with make-immutable-hash as its make-table. So what I'm looking for is not >> > set?, but set-immutable?, as it's a distinct (family of) struct types that >> > won't clash with the primitive data that I'm otherwise using. >> > -Ian >> > - Original Message - >> > From: "Carl Eastlund" < c...@ccs.neu.edu > >> > To: "J. Ian Johnson" < i...@ccs.neu.edu > >> > Cc: "dev" < dev@racket-lang.org > >> > Sent: Wednesday, August 21, 2013 6:58:56 PM GMT -05:00 US/Canada Eastern >> > Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations >> > >> > >> > Ian, sets are now a generic datatype, like dictionaries. Association lists >> > are dictionaries, and lists are now sets. They're also streams and >> > sequences. They're not just "set-like". >> > >> > >> > >> > Carl Eastlund >> > >> > >> > On Wed, Aug 21, 2013 at 6:56 PM, J. Ian Johnson < i...@ccs.neu.edu > >> > wrote: >> > >> > >> > I just wasted about 2 hours tracking down a bug that ended up being due to >> > (set? '()) now evaluating to #t. I have no problems with set-union, >> > intersection, etc. being defined for lists, but to treat lists as sets >> > always is perverse to me. The contracts for set operations should use >> > set-like? for (or/c set? list?) and keep the two constructions separate. >> > >> > This conflation is almost as bad as treating empty list as false. >> > >> > -Ian >> > _ >> > Racket Developers list: >> > http://lists.racket-lang.org/dev >> > >> > >> > >> > >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Lists aren't sets, but have set-like operations
In addition to this backwards-compatibility issue, I also wonder if there are others we've possibly missed that we should also consider (and perhaps try to find alternatives for)? I imagine there are a bunch that turn errors into non-errors that we could decide to deal in one fell swoop (to just accept), but are there others like the change in the behavior of the current "set?"? Robby On Thu, Aug 22, 2013 at 6:22 AM, Matthew Flatt wrote: > How much should we prioritize backward compatibility in this case? > > One possibility is to make `set?' mean `hash-set?', and add > `generic-set?' in place of the current `set?'. That's uglier, > obviously, but it would be better if we want to prioritize backward > compatibility. > > At Wed, 21 Aug 2013 19:14:06 -0400, Carl Eastlund wrote: > > Ah, yes. The set? predicate no longer distinguishes a representation. > > There are several predicates for the original set type, now called "hash > > sets": set-eq?, set-eqv?, set-equal?, set-mutable?, set-immtuable?, and > > set-weak?. I didn't add the basic "hash-set?", but perhaps I should. > It's > > a weird name, since "hash-set" and "hash-set!" are already existing, > > unrelated functions. > > > > Carl Eastlund > > > > > > On Wed, Aug 21, 2013 at 7:08 PM, J. Ian Johnson > wrote: > > > > > Okay, I can abide. However, that doesn't really get at my frustration. > I'm > > > using the set constructor, that appears to now be an > immutable-custom-set > > > with make-immutable-hash as its make-table. So what I'm looking for is > not > > > set?, but set-immutable?, as it's a distinct (family of) struct types > that > > > won't clash with the primitive data that I'm otherwise using. > > > -Ian > > > - Original Message - > > > From: "Carl Eastlund" > > > To: "J. Ian Johnson" > > > Cc: "dev" > > > Sent: Wednesday, August 21, 2013 6:58:56 PM GMT -05:00 US/Canada > Eastern > > > Subject: Re: [racket-dev] Lists aren't sets, but have set-like > operations > > > > > > > > > Ian, sets are now a generic datatype, like dictionaries. Association > lists > > > are dictionaries, and lists are now sets. They're also streams and > > > sequences. They're not just "set-like". > > > > > > > > > > > > Carl Eastlund > > > > > > > > > On Wed, Aug 21, 2013 at 6:56 PM, J. Ian Johnson < i...@ccs.neu.edu > > > > wrote: > > > > > > > > > I just wasted about 2 hours tracking down a bug that ended up being > due to > > > (set? '()) now evaluating to #t. I have no problems with set-union, > > > intersection, etc. being defined for lists, but to treat lists as sets > > > always is perverse to me. The contracts for set operations should use > > > set-like? for (or/c set? list?) and keep the two constructions > separate. > > > > > > This conflation is almost as bad as treating empty list as false. > > > > > > -Ian > > > _ > > > Racket Developers list: > > > http://lists.racket-lang.org/dev > > > > > > > > > > > > > > _ > > Racket Developers list: > > http://lists.racket-lang.org/dev > _ > Racket Developers list: > http://lists.racket-lang.org/dev > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Lists aren't sets, but have set-like operations
Wait, `set-union` of two different set representations doesn't work? Sam On Thu, Aug 22, 2013 at 8:07 AM, J. Ian Johnson wrote: > You misunderstand. I used set-union, but single dispatch saw '() and used > list-union for the '() (set) combination. > -Ian > - Original Message - > From: "Sam Tobin-Hochstadt" > To: "J. Ian Johnson" > Cc: dev@racket-lang.org, "Matthew Flatt" > Sent: Thursday, August 22, 2013 8:02:50 AM GMT -05:00 US/Canada Eastern > Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations > > > > But 'list-union' is not a generic operation so it isn't surprising that this > didn't work. To do this generically, you'd need to use 'set-union'. > > Sam > On Aug 22, 2013 7:59 AM, "J. Ian Johnson" < i...@ccs.neu.edu > wrote: > > > The problem manifested itself when I got an exception that in-list can't be > called on (set), which really confused me. (set? '()) answered true, so it > tried to do (list-union '() (set)), which failed. > Generic sets as they are don't work generically. Some action should be taken. > Either set? means what it once did, or we do some awfully slow multiple > dispatch for set operations. My bias shows. > -Ian > - Original Message - > From: "Matthew Flatt" < mfl...@cs.utah.edu > > To: "Carl Eastlund" < c...@ccs.neu.edu > > Cc: "J. Ian Johnson" < i...@ccs.neu.edu >, "dev" < dev@racket-lang.org > > Sent: Thursday, August 22, 2013 7:22:25 AM GMT -05:00 US/Canada Eastern > Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations > > How much should we prioritize backward compatibility in this case? > > One possibility is to make `set?' mean `hash-set?', and add > `generic-set?' in place of the current `set?'. That's uglier, > obviously, but it would be better if we want to prioritize backward > compatibility. > > At Wed, 21 Aug 2013 19:14:06 -0400, Carl Eastlund wrote: >> Ah, yes. The set? predicate no longer distinguishes a representation. >> There are several predicates for the original set type, now called "hash >> sets": set-eq?, set-eqv?, set-equal?, set-mutable?, set-immtuable?, and >> set-weak?. I didn't add the basic "hash-set?", but perhaps I should. It's >> a weird name, since "hash-set" and "hash-set!" are already existing, >> unrelated functions. >> >> Carl Eastlund >> >> >> On Wed, Aug 21, 2013 at 7:08 PM, J. Ian Johnson < i...@ccs.neu.edu > wrote: >> >> > Okay, I can abide. However, that doesn't really get at my frustration. I'm >> > using the set constructor, that appears to now be an immutable-custom-set >> > with make-immutable-hash as its make-table. So what I'm looking for is not >> > set?, but set-immutable?, as it's a distinct (family of) struct types that >> > won't clash with the primitive data that I'm otherwise using. >> > -Ian >> > - Original Message - >> > From: "Carl Eastlund" < c...@ccs.neu.edu > >> > To: "J. Ian Johnson" < i...@ccs.neu.edu > >> > Cc: "dev" < dev@racket-lang.org > >> > Sent: Wednesday, August 21, 2013 6:58:56 PM GMT -05:00 US/Canada Eastern >> > Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations >> > >> > >> > Ian, sets are now a generic datatype, like dictionaries. Association lists >> > are dictionaries, and lists are now sets. They're also streams and >> > sequences. They're not just "set-like". >> > >> > >> > >> > Carl Eastlund >> > >> > >> > On Wed, Aug 21, 2013 at 6:56 PM, J. Ian Johnson < i...@ccs.neu.edu > >> > wrote: >> > >> > >> > I just wasted about 2 hours tracking down a bug that ended up being due to >> > (set? '()) now evaluating to #t. I have no problems with set-union, >> > intersection, etc. being defined for lists, but to treat lists as sets >> > always is perverse to me. The contracts for set operations should use >> > set-like? for (or/c set? list?) and keep the two constructions separate. >> > >> > This conflation is almost as bad as treating empty list as false. >> > >> > -Ian >> > _ >> > Racket Developers list: >> > http://lists.racket-lang.org/dev >> > >> > >> > >> > >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Lists aren't sets, but have set-like operations
You misunderstand. I used set-union, but single dispatch saw '() and used list-union for the '() (set) combination. -Ian - Original Message - From: "Sam Tobin-Hochstadt" To: "J. Ian Johnson" Cc: dev@racket-lang.org, "Matthew Flatt" Sent: Thursday, August 22, 2013 8:02:50 AM GMT -05:00 US/Canada Eastern Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations But 'list-union' is not a generic operation so it isn't surprising that this didn't work. To do this generically, you'd need to use 'set-union'. Sam On Aug 22, 2013 7:59 AM, "J. Ian Johnson" < i...@ccs.neu.edu > wrote: The problem manifested itself when I got an exception that in-list can't be called on (set), which really confused me. (set? '()) answered true, so it tried to do (list-union '() (set)), which failed. Generic sets as they are don't work generically. Some action should be taken. Either set? means what it once did, or we do some awfully slow multiple dispatch for set operations. My bias shows. -Ian - Original Message - From: "Matthew Flatt" < mfl...@cs.utah.edu > To: "Carl Eastlund" < c...@ccs.neu.edu > Cc: "J. Ian Johnson" < i...@ccs.neu.edu >, "dev" < dev@racket-lang.org > Sent: Thursday, August 22, 2013 7:22:25 AM GMT -05:00 US/Canada Eastern Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations How much should we prioritize backward compatibility in this case? One possibility is to make `set?' mean `hash-set?', and add `generic-set?' in place of the current `set?'. That's uglier, obviously, but it would be better if we want to prioritize backward compatibility. At Wed, 21 Aug 2013 19:14:06 -0400, Carl Eastlund wrote: > Ah, yes. The set? predicate no longer distinguishes a representation. > There are several predicates for the original set type, now called "hash > sets": set-eq?, set-eqv?, set-equal?, set-mutable?, set-immtuable?, and > set-weak?. I didn't add the basic "hash-set?", but perhaps I should. It's > a weird name, since "hash-set" and "hash-set!" are already existing, > unrelated functions. > > Carl Eastlund > > > On Wed, Aug 21, 2013 at 7:08 PM, J. Ian Johnson < i...@ccs.neu.edu > wrote: > > > Okay, I can abide. However, that doesn't really get at my frustration. I'm > > using the set constructor, that appears to now be an immutable-custom-set > > with make-immutable-hash as its make-table. So what I'm looking for is not > > set?, but set-immutable?, as it's a distinct (family of) struct types that > > won't clash with the primitive data that I'm otherwise using. > > -Ian > > - Original Message - > > From: "Carl Eastlund" < c...@ccs.neu.edu > > > To: "J. Ian Johnson" < i...@ccs.neu.edu > > > Cc: "dev" < dev@racket-lang.org > > > Sent: Wednesday, August 21, 2013 6:58:56 PM GMT -05:00 US/Canada Eastern > > Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations > > > > > > Ian, sets are now a generic datatype, like dictionaries. Association lists > > are dictionaries, and lists are now sets. They're also streams and > > sequences. They're not just "set-like". > > > > > > > > Carl Eastlund > > > > > > On Wed, Aug 21, 2013 at 6:56 PM, J. Ian Johnson < i...@ccs.neu.edu > > > wrote: > > > > > > I just wasted about 2 hours tracking down a bug that ended up being due to > > (set? '()) now evaluating to #t. I have no problems with set-union, > > intersection, etc. being defined for lists, but to treat lists as sets > > always is perverse to me. The contracts for set operations should use > > set-like? for (or/c set? list?) and keep the two constructions separate. > > > > This conflation is almost as bad as treating empty list as false. > > > > -Ian > > _ > > Racket Developers list: > > http://lists.racket-lang.org/dev > > > > > > > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Lists aren't sets, but have set-like operations
But 'list-union' is not a generic operation so it isn't surprising that this didn't work. To do this generically, you'd need to use 'set-union'. Sam On Aug 22, 2013 7:59 AM, "J. Ian Johnson" wrote: > The problem manifested itself when I got an exception that in-list can't > be called on (set), which really confused me. (set? '()) answered true, so > it tried to do (list-union '() (set)), which failed. > Generic sets as they are don't work generically. Some action should be > taken. Either set? means what it once did, or we do some awfully slow > multiple dispatch for set operations. My bias shows. > -Ian > - Original Message - > From: "Matthew Flatt" > To: "Carl Eastlund" > Cc: "J. Ian Johnson" , "dev" > Sent: Thursday, August 22, 2013 7:22:25 AM GMT -05:00 US/Canada Eastern > Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations > > How much should we prioritize backward compatibility in this case? > > One possibility is to make `set?' mean `hash-set?', and add > `generic-set?' in place of the current `set?'. That's uglier, > obviously, but it would be better if we want to prioritize backward > compatibility. > > At Wed, 21 Aug 2013 19:14:06 -0400, Carl Eastlund wrote: > > Ah, yes. The set? predicate no longer distinguishes a representation. > > There are several predicates for the original set type, now called "hash > > sets": set-eq?, set-eqv?, set-equal?, set-mutable?, set-immtuable?, and > > set-weak?. I didn't add the basic "hash-set?", but perhaps I should. > It's > > a weird name, since "hash-set" and "hash-set!" are already existing, > > unrelated functions. > > > > Carl Eastlund > > > > > > On Wed, Aug 21, 2013 at 7:08 PM, J. Ian Johnson > wrote: > > > > > Okay, I can abide. However, that doesn't really get at my frustration. > I'm > > > using the set constructor, that appears to now be an > immutable-custom-set > > > with make-immutable-hash as its make-table. So what I'm looking for is > not > > > set?, but set-immutable?, as it's a distinct (family of) struct types > that > > > won't clash with the primitive data that I'm otherwise using. > > > -Ian > > > - Original Message - > > > From: "Carl Eastlund" > > > To: "J. Ian Johnson" > > > Cc: "dev" > > > Sent: Wednesday, August 21, 2013 6:58:56 PM GMT -05:00 US/Canada > Eastern > > > Subject: Re: [racket-dev] Lists aren't sets, but have set-like > operations > > > > > > > > > Ian, sets are now a generic datatype, like dictionaries. Association > lists > > > are dictionaries, and lists are now sets. They're also streams and > > > sequences. They're not just "set-like". > > > > > > > > > > > > Carl Eastlund > > > > > > > > > On Wed, Aug 21, 2013 at 6:56 PM, J. Ian Johnson < i...@ccs.neu.edu > > > > wrote: > > > > > > > > > I just wasted about 2 hours tracking down a bug that ended up being > due to > > > (set? '()) now evaluating to #t. I have no problems with set-union, > > > intersection, etc. being defined for lists, but to treat lists as sets > > > always is perverse to me. The contracts for set operations should use > > > set-like? for (or/c set? list?) and keep the two constructions > separate. > > > > > > This conflation is almost as bad as treating empty list as false. > > > > > > -Ian > > > _ > > > Racket Developers list: > > > http://lists.racket-lang.org/dev > > > > > > > > > > > > > > _ > > Racket Developers list: > > http://lists.racket-lang.org/dev > _ > Racket Developers list: > http://lists.racket-lang.org/dev > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Lists aren't sets, but have set-like operations
The problem manifested itself when I got an exception that in-list can't be called on (set), which really confused me. (set? '()) answered true, so it tried to do (list-union '() (set)), which failed. Generic sets as they are don't work generically. Some action should be taken. Either set? means what it once did, or we do some awfully slow multiple dispatch for set operations. My bias shows. -Ian - Original Message - From: "Matthew Flatt" To: "Carl Eastlund" Cc: "J. Ian Johnson" , "dev" Sent: Thursday, August 22, 2013 7:22:25 AM GMT -05:00 US/Canada Eastern Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations How much should we prioritize backward compatibility in this case? One possibility is to make `set?' mean `hash-set?', and add `generic-set?' in place of the current `set?'. That's uglier, obviously, but it would be better if we want to prioritize backward compatibility. At Wed, 21 Aug 2013 19:14:06 -0400, Carl Eastlund wrote: > Ah, yes. The set? predicate no longer distinguishes a representation. > There are several predicates for the original set type, now called "hash > sets": set-eq?, set-eqv?, set-equal?, set-mutable?, set-immtuable?, and > set-weak?. I didn't add the basic "hash-set?", but perhaps I should. It's > a weird name, since "hash-set" and "hash-set!" are already existing, > unrelated functions. > > Carl Eastlund > > > On Wed, Aug 21, 2013 at 7:08 PM, J. Ian Johnson wrote: > > > Okay, I can abide. However, that doesn't really get at my frustration. I'm > > using the set constructor, that appears to now be an immutable-custom-set > > with make-immutable-hash as its make-table. So what I'm looking for is not > > set?, but set-immutable?, as it's a distinct (family of) struct types that > > won't clash with the primitive data that I'm otherwise using. > > -Ian > > ----- Original Message - > > From: "Carl Eastlund" > > To: "J. Ian Johnson" > > Cc: "dev" > > Sent: Wednesday, August 21, 2013 6:58:56 PM GMT -05:00 US/Canada Eastern > > Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations > > > > > > Ian, sets are now a generic datatype, like dictionaries. Association lists > > are dictionaries, and lists are now sets. They're also streams and > > sequences. They're not just "set-like". > > > > > > > > Carl Eastlund > > > > > > On Wed, Aug 21, 2013 at 6:56 PM, J. Ian Johnson < i...@ccs.neu.edu > > > wrote: > > > > > > I just wasted about 2 hours tracking down a bug that ended up being due to > > (set? '()) now evaluating to #t. I have no problems with set-union, > > intersection, etc. being defined for lists, but to treat lists as sets > > always is perverse to me. The contracts for set operations should use > > set-like? for (or/c set? list?) and keep the two constructions separate. > > > > This conflation is almost as bad as treating empty list as false. > > > > -Ian > > _ > > Racket Developers list: > > http://lists.racket-lang.org/dev > > > > > > > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Lists aren't sets, but have set-like operations
How much should we prioritize backward compatibility in this case? One possibility is to make `set?' mean `hash-set?', and add `generic-set?' in place of the current `set?'. That's uglier, obviously, but it would be better if we want to prioritize backward compatibility. At Wed, 21 Aug 2013 19:14:06 -0400, Carl Eastlund wrote: > Ah, yes. The set? predicate no longer distinguishes a representation. > There are several predicates for the original set type, now called "hash > sets": set-eq?, set-eqv?, set-equal?, set-mutable?, set-immtuable?, and > set-weak?. I didn't add the basic "hash-set?", but perhaps I should. It's > a weird name, since "hash-set" and "hash-set!" are already existing, > unrelated functions. > > Carl Eastlund > > > On Wed, Aug 21, 2013 at 7:08 PM, J. Ian Johnson wrote: > > > Okay, I can abide. However, that doesn't really get at my frustration. I'm > > using the set constructor, that appears to now be an immutable-custom-set > > with make-immutable-hash as its make-table. So what I'm looking for is not > > set?, but set-immutable?, as it's a distinct (family of) struct types that > > won't clash with the primitive data that I'm otherwise using. > > -Ian > > - Original Message ----- > > From: "Carl Eastlund" > > To: "J. Ian Johnson" > > Cc: "dev" > > Sent: Wednesday, August 21, 2013 6:58:56 PM GMT -05:00 US/Canada Eastern > > Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations > > > > > > Ian, sets are now a generic datatype, like dictionaries. Association lists > > are dictionaries, and lists are now sets. They're also streams and > > sequences. They're not just "set-like". > > > > > > > > Carl Eastlund > > > > > > On Wed, Aug 21, 2013 at 6:56 PM, J. Ian Johnson < i...@ccs.neu.edu > > > wrote: > > > > > > I just wasted about 2 hours tracking down a bug that ended up being due to > > (set? '()) now evaluating to #t. I have no problems with set-union, > > intersection, etc. being defined for lists, but to treat lists as sets > > always is perverse to me. The contracts for set operations should use > > set-like? for (or/c set? list?) and keep the two constructions separate. > > > > This conflation is almost as bad as treating empty list as false. > > > > -Ian > > _ > > Racket Developers list: > > http://lists.racket-lang.org/dev > > > > > > > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Lists aren't sets, but have set-like operations
Ah, yes. The set? predicate no longer distinguishes a representation. There are several predicates for the original set type, now called "hash sets": set-eq?, set-eqv?, set-equal?, set-mutable?, set-immtuable?, and set-weak?. I didn't add the basic "hash-set?", but perhaps I should. It's a weird name, since "hash-set" and "hash-set!" are already existing, unrelated functions. Carl Eastlund On Wed, Aug 21, 2013 at 7:08 PM, J. Ian Johnson wrote: > Okay, I can abide. However, that doesn't really get at my frustration. I'm > using the set constructor, that appears to now be an immutable-custom-set > with make-immutable-hash as its make-table. So what I'm looking for is not > set?, but set-immutable?, as it's a distinct (family of) struct types that > won't clash with the primitive data that I'm otherwise using. > -Ian > - Original Message - > From: "Carl Eastlund" > To: "J. Ian Johnson" > Cc: "dev" > Sent: Wednesday, August 21, 2013 6:58:56 PM GMT -05:00 US/Canada Eastern > Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations > > > Ian, sets are now a generic datatype, like dictionaries. Association lists > are dictionaries, and lists are now sets. They're also streams and > sequences. They're not just "set-like". > > > > Carl Eastlund > > > On Wed, Aug 21, 2013 at 6:56 PM, J. Ian Johnson < i...@ccs.neu.edu > > wrote: > > > I just wasted about 2 hours tracking down a bug that ended up being due to > (set? '()) now evaluating to #t. I have no problems with set-union, > intersection, etc. being defined for lists, but to treat lists as sets > always is perverse to me. The contracts for set operations should use > set-like? for (or/c set? list?) and keep the two constructions separate. > > This conflation is almost as bad as treating empty list as false. > > -Ian > _ > Racket Developers list: > http://lists.racket-lang.org/dev > > > > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Lists aren't sets, but have set-like operations
Okay, I can abide. However, that doesn't really get at my frustration. I'm using the set constructor, that appears to now be an immutable-custom-set with make-immutable-hash as its make-table. So what I'm looking for is not set?, but set-immutable?, as it's a distinct (family of) struct types that won't clash with the primitive data that I'm otherwise using. -Ian - Original Message - From: "Carl Eastlund" To: "J. Ian Johnson" Cc: "dev" Sent: Wednesday, August 21, 2013 6:58:56 PM GMT -05:00 US/Canada Eastern Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations Ian, sets are now a generic datatype, like dictionaries. Association lists are dictionaries, and lists are now sets. They're also streams and sequences. They're not just "set-like". Carl Eastlund On Wed, Aug 21, 2013 at 6:56 PM, J. Ian Johnson < i...@ccs.neu.edu > wrote: I just wasted about 2 hours tracking down a bug that ended up being due to (set? '()) now evaluating to #t. I have no problems with set-union, intersection, etc. being defined for lists, but to treat lists as sets always is perverse to me. The contracts for set operations should use set-like? for (or/c set? list?) and keep the two constructions separate. This conflation is almost as bad as treating empty list as false. -Ian _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Lists aren't sets, but have set-like operations
Ian, sets are now a generic datatype, like dictionaries. Association lists are dictionaries, and lists are now sets. They're also streams and sequences. They're not just "set-like". Carl Eastlund On Wed, Aug 21, 2013 at 6:56 PM, J. Ian Johnson wrote: > I just wasted about 2 hours tracking down a bug that ended up being due to > (set? '()) now evaluating to #t. I have no problems with set-union, > intersection, etc. being defined for lists, but to treat lists as sets > always is perverse to me. The contracts for set operations should use > set-like? for (or/c set? list?) and keep the two constructions separate. > > This conflation is almost as bad as treating empty list as false. > > -Ian > _ > Racket Developers list: > http://lists.racket-lang.org/dev > > _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Lists aren't sets, but have set-like operations
I just wasted about 2 hours tracking down a bug that ended up being due to (set? '()) now evaluating to #t. I have no problems with set-union, intersection, etc. being defined for lists, but to treat lists as sets always is perverse to me. The contracts for set operations should use set-like? for (or/c set? list?) and keep the two constructions separate. This conflation is almost as bad as treating empty list as false. -Ian _ Racket Developers list: http://lists.racket-lang.org/dev
