Comments on: Decided -- WORD datatypes within set functions
Some background information:
The data set (set as in a collection of values, not as in set-word) native functions are:
difference
exclude
intersect
union
unique
These functions have been entirely rewritten due to Unicode and due to the removal of the HASH! datatype, by which they were optimized. They now use the MAP! datatype hashing method.
Each of these functions will operate on three argument types:
block!
string! (includes Unicode)
bitset! (includes Unicode)
Currently, this is the case:
>> union [a b] ['a 'b]
== [a b]
>> union ['a 'b] [a b]
== ['a 'b]
However, does that make sense?
I think we should probably differentiate on word datatypes. The above example would become:
I agree that it should differentiate by type. That's what R2 does as well, so it's one less thing that will break. It's also easier to post-filter if you want the other behavior.
Brian Hawley 12-Feb-2008 18:17:54
I prefer to differentiate based on datatype.
Brian Hawley 12-Feb-2008 18:43:17
Would the answer to this question affect key matching in the map! datatype?
Brian Tiffin 12-Feb-2008 21:06:45
For any R3 source code analysis tooling, it may help to consider datatypes.
Oldes 13-Feb-2008 3:35:12
differentiate between word types
Gabriele 13-Feb-2008 4:28:49
I agree it should differentiate, unless this breaks MAP!
Carl Sassenrath 13-Feb-2008 11:28:31
Ok, so a decision has been reached, as stated above words are differentiated by type. This discussion is concluded.
It can be done w/o affecting the MAP type.
Duane Lachney 7-Mar-2008 14:12:19
Why not build a refinement in each of the data set native functions so that - if needed or desired - the differentiation by type could be turned off?
example:
/* following code differentiates by type */
>> union [a b] ['a 'b]
== [a b 'a 'b]
/* following - using function refinement - does NOT differentiate by type */
>> union /notype [a b] ['a 'b]
== [a b]
maxim oliver-adlhoch 10-Mar-2008 23:07:28
I second the idea, its not a bad idea, similar in scope to the /case refinement which appears here and there.
