<div dir="ltr">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)?<div><br></div><div>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?"?</div> <div><br></div><div>Robby</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 22, 2013 at 6:22 AM, Matthew Flatt <span dir="ltr"><<a href="mailto:mflatt@cs.utah.edu" target="_blank">mflatt@cs.utah.edu</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">How much should we prioritize backward compatibility in this case?<br> <br> One possibility is to make `set?' mean `hash-set?', and add<br> `generic-set?' in place of the current `set?'. That's uglier,<br> obviously, but it would be better if we want to prioritize backward<br> compatibility.<br> <div class="HOEnZb"><div class="h5"><br> At Wed, 21 Aug 2013 19:14:06 -0400, Carl Eastlund wrote:<br> > Ah, yes. The set? predicate no longer distinguishes a representation.<br> > There are several predicates for the original set type, now called "hash<br> > sets": set-eq?, set-eqv?, set-equal?, set-mutable?, set-immtuable?, and<br> > set-weak?. I didn't add the basic "hash-set?", but perhaps I should. It's<br> > a weird name, since "hash-set" and "hash-set!" are already existing,<br> > unrelated functions.<br> ><br> > Carl Eastlund<br> ><br> ><br> > On Wed, Aug 21, 2013 at 7:08 PM, J. Ian Johnson <<a href="mailto:ianj@ccs.neu.edu">ianj@ccs.neu.edu</a>> wrote:<br> ><br> > > Okay, I can abide. However, that doesn't really get at my frustration. I'm<br> > > using the set constructor, that appears to now be an immutable-custom-set<br> > > with make-immutable-hash as its make-table. So what I'm looking for is not<br> > > set?, but set-immutable?, as it's a distinct (family of) struct types that<br> > > won't clash with the primitive data that I'm otherwise using.<br> > > -Ian<br> > > ----- Original Message -----<br> > > From: "Carl Eastlund" <<a href="mailto:cce@ccs.neu.edu">cce@ccs.neu.edu</a>><br> > > To: "J. Ian Johnson" <<a href="mailto:ianj@ccs.neu.edu">ianj@ccs.neu.edu</a>><br> > > Cc: "dev" <<a href="mailto:dev@racket-lang.org">dev@racket-lang.org</a>><br> > > Sent: Wednesday, August 21, 2013 6:58:56 PM GMT -05:00 US/Canada Eastern<br> > > Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations<br> > ><br> > ><br> > > Ian, sets are now a generic datatype, like dictionaries. Association lists<br> > > are dictionaries, and lists are now sets. They're also streams and<br> > > sequences. They're not just "set-like".<br> > ><br> > ><br> > ><br> > > Carl Eastlund<br> > ><br> > ><br> > > On Wed, Aug 21, 2013 at 6:56 PM, J. Ian Johnson < <a href="mailto:ianj@ccs.neu.edu">ianj@ccs.neu.edu</a> ><br> > > wrote:<br> > ><br> > ><br> > > I just wasted about 2 hours tracking down a bug that ended up being due to<br> > > (set? '()) now evaluating to #t. I have no problems with set-union,<br> > > intersection, etc. being defined for lists, but to treat lists as sets<br> > > always is perverse to me. The contracts for set operations should use<br> > > set-like? for (or/c set? list?) and keep the two constructions separate.<br> > ><br> > > This conflation is almost as bad as treating empty list as false.<br> > ><br> > > -Ian<br> > > _________________________<br> > > Racket Developers list:<br> > > <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a><br> > ><br> > ><br> > ><br> > ><br> > _________________________<br> > Racket Developers list:<br> > <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a><br> _________________________<br> Racket Developers list:<br> <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a><br> </div></div></blockquote></div><br></div>