Re: [Wrapl-discussion] Corrections to the documentation

[Raja M. <raj...@gm...>]

Roman Mishin wrote:
>
>     The :collect method in Agg.List is actually a method on functions,
>     but defined in Agg.List since it returns a list. I guess there
>     could be another similar method for tables, like :collect_table.
>
>
> I missed that point too (that it comes from Functions). Frankly, I do 
> not really want it to be named :collect_table. Let's defer this until 
> a practical urge? If you'll implement it I'll vote it to be called by 
> a single word, i.e. :glean, :sieve or other English verb that is a 
> form of thorough gathering/collecting, since the result will be 
> unique, sorted values.
I'll leave it out for now so, I think the Table.Collect function call is 
sufficient for the moment.
>
>     UNIQ expr sounds like an interesting idea, but it can be done in
>     code as (VAR t <- {}; EVERY t:insert(expr); t), just as (VAR l <-
>     []; EVERY l:put(expr); l) will emulate ALL expr. The main reason
>     for ALL expr is that directly appending to a list is a lot faster
>     than the the overhead of calling l:put(expr). ALL expr is
>     effectively a more powerful form of list comprehensions, already
>     found in languages like Python. While the time to call
>     t:insert(expr), would be removed by a UNIQ expr, the call to :"#"
>     (to hash the value) and :"?" (to compare values) when inserting
>     into the table would still be present. If you think it would be
>     useful however, I'll implement it, it wouldn't be hard since I can
>     reuse the ALL code.
>
>
> I see ALL expr from such perspective that it makes the code clear and 
> in some sense semantically complete. It's if I'd say: I want here all 
> expr's values. I proposed UNIQ from that point of view.
>
> Here are three files: a small task where this comes from. The first 
> one (Unique1) was created initially. It looks too general. Then I 
> imagined it could be done with UNIQ (Unique2). You suggest it can be 
> done the third way (Unique3) and to me it looks clear but is not 
> a straight way to express the notion.
>
> I would agree on UNIQ implementation even without a performance gain, 
> only because of the syntax.

I forgot to mention one other reason why I didn't have such a thing 
before, the code VAR t <- {}; creates a normal table, but if Agg.Table 
is imported, the code VAR t <- Table.New(comparefn, hashfn); creates a 
table with custom comparison and hashing functions (instead of the 
multimethods :? and :#), which can be faster if the type of the keys is 
known in advance (for example using String.Compare and String.Hash 
directly), or provide different sorting on the keys, etc. There is no 
equivalent concept for lists.

But you're right, consistency has the highest priority in designing 
Wrapl, and a UNIQ expression would mirror the ALL expression perfectly. 
For situations where using custom comparison/hash functions is 
necessary, the previous method of using an explicit variable will always 
be available anyway.

I'll set about implementing it for the next release.
> --
> Roman
Raja