<div dir="ltr">Thanks for those pointers, Tobias, I&#39;ll get those fixed.<br><div class="gmail_extra"><br clear="all"><div>Carl Eastlund</div>
<br><div class="gmail_quote">On Wed, Jul 24, 2013 at 1:34 PM, Tobias Hammer <span dir="ltr">&lt;<a href="mailto:tobias.hammer@dlr.de" target="_blank">tobias.hammer@dlr.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I really like the new set features, especially mutable sets and lists as sets.<br>
<br>
Two things i have notices:<br>
* The docs for set-intersect seem a bit mixed up with set-union stuff<br>
* I could not get set-intersect on lists working, what i&#39;ve tried<br>
<br>
-&gt; (set-intersect &#39;(1 2 3) &#39;(2 3 4))<br>
; set-add: contract violation<br>
;   expected: set?<br>
;   given: 2<br>
<br>
-&gt; (set-intersect (list-&gt;set &#39;(1 2 3)) &#39;(2 3 4))<br>
; set-intersect: set arguments have incompatible equivalence predicates<br>
;   first set: (set 1 2 3)<br>
;   incompatible set: &#39;(2 3 4)<br>
<br>
Tobias<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Tue, 23 Jul 2013 17:37:15 +0200, Carl Eastlund &lt;<a href="mailto:cce@ccs.neu.edu" target="_blank">cce@ccs.neu.edu</a>&gt; wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My work on adding gen:set, and related changes to define-generics and<br>
gen:dict, is ready for review and (hopefully) to push to the master<br>
branch.  The branch moved in the process of cleaning things up, it&#39;s now at:<br>
<br>
  <a href="https://github.com/carl-eastlund/racket/tree/generics-from-scratch" target="_blank">https://github.com/carl-<u></u>eastlund/racket/tree/generics-<u></u>from-scratch</a><br>
<br>
(The &quot;from scratch&quot; just refers to the process of rebuilding the git<br>
history, I didn&#39;t go out of my way to rewrite anything in the code base<br>
from scratch, although in some places a lot of code did move around.)<br>
<br>
What&#39;s new in the branch:<br>
<br>
- Generics now support a few new options<br>
  - #:fallbacks specifies fallback method implementations for instances<br>
with no implementation<br>
  - #:fast-defaults specifies instances on a &quot;fast path&quot;, useful for<br>
built-in types<br>
  - #:defined-predicate gives a more intuitive and efficient interface than<br>
#:defined-table<br>
  - #:derive-property allows generics to piggy-back on existing struct<br>
properties<br>
<br>
- Sets are now a generic datatype through gen:set<br>
  - lists are now sets<br>
  - the built-in set types are now documented as &quot;hash sets&quot;<br>
  - there are mutable and weak hash sets<br>
  - you can define new set types quickly with define-custom-set-types<br>
  - most set operations are now methods with fallbacks<br>
  - sets now support -copy and -clear operations, plus mutating [!]<br>
versions of operations<br>
<br>
- Dictionaries have a few changes<br>
  - new macro define-custom-hash-types [*]<br>
  - most dict operations are now methods with fallbacks<br>
  - dicts now support -copy, -clear, -clear!, and -empty? operations<br>
<br>
I&#39;ve run some benchmarks and performance of the various generic operations<br>
are comparable to the current HEAD, so there should be no major performance<br>
changes with this patch.<br>
<br>
[*] I&#39;ve added define-custom-hash-types and define-custom-set-types rather<br>
than just adding make-custom-set akin to make-custom-hash because<br>
make-custom-hash is hard to use.  The documented behavior -- that any<br>
custom hash is equal to any other created with the same bindings and<br>
predicates / hash functions -- was never true and can be expensive or at<br>
least tricky to implement.  It seemed more sensible to just remove the<br>
erroneous documentation on make-custom-hash, and add the definition form to<br>
create constructors for new, explicitly-compatible dict and set types.<br>
Both definition forms bind predicates and constructors for new (set or<br>
dict) types with immutable, mutable, and weak variants that inter-operate.<br>
<br>
If there are no serious issues brought up in the next day or two, I&#39;ll push<br>
it to the development branch, since our current release process isn&#39;t<br>
following HEAD.<br>
<br>
Carl Eastlund<br>
</blockquote>
<br>
<br></div></div><span class="HOEnZb"><font color="#888888">
-- <br>
------------------------------<u></u>---------------------------<br>
Tobias Hammer<br>
DLR / Robotics and Mechatronics Center (RMC)<br>
Muenchner Str. 20, D-82234 Wessling<br>
Tel.: 08153/28-1487<br>
Mail: <a href="mailto:tobias.hammer@dlr.de" target="_blank">tobias.hammer@dlr.de</a><br>
<br>
</font></span></blockquote></div><br></div></div>