www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - '$' and opDollar

reply spir <denis.spir gmail.com> writes:
Hello,


[This is another currently unfixed point of D2 that prevents us implementin=
g our project the way we wish it.]

AFAIK, using '$' for custom collection types is not yet possible: oDollar i=
s simply not implemented (correct?). But why do we need it? I do not unders=
tand the logic requiring an opDollar special method to "desugarise" the '$'=
 operator. For me, '$' simply means length, so I would be fully happy with =
the simple rewrite of
    coll[$]  coll[$-i] coll[i..$]
to
    coll[coll.length]   coll[coll.length-i]   coll[i..coll.length]
et caetera.
I have thought at two objections against this.

First, 'length' is not a language-defined special member. Actually, it is a=
lready one for the 3 kinds of D arrays --if coll is an array, '$' actually =
maps to length, I guess. We could extend this principle to programmer-defin=
ed collections: make 'length' a special member, just like opIndex or range =
properties; it is just a decision to take.
Precisely, if needed, index could be either a plain data member _or_ a prop=
erty, possibly depending on the kind of collection (or rather on whether th=
e designer wants to maintain length or compute it on demand).
Finally, I consider 'length' as already somewhat special for random-access =
ranges: how else determine index validity, or simply the end point?

Second, length (in the sense of size, or count of elements) may not really =
make sense for every kind of collections. For instance, there are open, pot=
ential, sequences like the set of all integer cubes. Also, there are collec=
tions for which the notion of element --thus of count-- is ambiguous or unc=
lear (eg sequences in which elements should be grouped like code unit strin=
gs, or trees for which only some nodes hold actual elements,...).
But precisely, I think such non-trivial kinds of collections which do not c=
onceptually have (an obvious) length also do not support '$' (in a simple w=
ay). I vaguely have in mind a kind of equivalence class between collections=
 for which indexing/slicing makes full sense and the notion of random-acces=
s range with its special attribute 'length'. What so you think?
For what it's worth, python's equivalent to [i..$] ([i:]) is AFAIK actually=
 rewritten to the magic __len__ method for custom types. The equivalent of =
D's coll[$-1] (coll[-i]) is rewritten to coll[coll.__len__()-i]. I do not k=
now of any practicle issue or limitation of this design in Python --a langu=
age in which many features have been fixed or generalised along times.

[OT]
Precisely, has a python-like syntax of negative indices and slice expressio=
ns open on right side been considered for D? Like:
    coll[-3]    // third element, counting from right side
    coll[1..-1] // all but first and last elements
    coll[3..]   // all but first 3 elements
and maybe (?)
    coll[..3]   // first 3 elements
I would very much prefere D's explicite notation if ever "$" had any sensib=
le meaning in context. (I also prefere explicite '0' than an open interval =
on left side.) But as "$" makes no sense, and no other ASCII sign can do th=
e job well, I find python's choice finally better. Also, intervals open on =
either side would be consistent with D's current use of [], I guess.=20
[/OT]


Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Jan 01 2011
parent reply Don <nospam nospam.com> writes:
spir wrote:

 Hello,
 
 
 [This is another currently unfixed point of D2 that prevents us implementing
our project the way we wish it.]
 
 AFAIK, using '$' for custom collection types is not yet possible: oDollar is
simply not implemented (correct?). But why do we need it? I do not understand
the logic requiring an opDollar special method to "desugarise" the '$'
operator. For me, '$' simply means length, so I would be fully happy with the
simple rewrite of
     coll[$]  coll[$-i] coll[i..$]
 to
     coll[coll.length]   coll[coll.length-i]   coll[i..coll.length]


The problem is with multi-dimensional indices.
Consider:
a[$-1][$-2];

There are two different values for $.
Jan 01 2011
next sibling parent reply spir <denis.spir gmail.com> writes:
On Sat, 01 Jan 2011 19:27:57 +0100
Don <nospam nospam.com> wrote:


 AFAIK, using '$' for custom collection types is not yet possible: oDoll=




ar is simply not implemented (correct?). But why do we need it? I do not un=
derstand the logic requiring an opDollar special method to "desugarise" the=
 '$' operator. For me, '$' simply means length, so I would be fully happy w=
ith the simple rewrite of

     coll[$]  coll[$-i] coll[i..$]
 to
     coll[coll.length]   coll[coll.length-i]   coll[i..coll.length] =20


=20
 The problem is with multi-dimensional indices.
 Consider:
 a[$-1][$-2];
=20
 There are two different values for $.


Right. I don't understand why a solution like length does not apply, and wh=
y opDollar would. In the above example, both a and a[$-1] should have a len=
gth member or an opDollar method. What do I misinterpret?

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Jan 01 2011
parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
spir <denis.spir gmail.com> wrote:


 On Sat, 01 Jan 2011 19:27:57 +0100
 Don <nospam nospam.com> wrote:


 AFAIK, using '$' for custom collection types is not yet possible:  


 oDollar is simply not implemented (correct?). But why do we need it? I  
 do not understand the logic requiring an opDollar special method to  
 "desugarise" the '$' operator. For me, '$' simply means length, so I  
 would be fully happy with the simple rewrite of

     coll[$]  coll[$-i] coll[i..$]
 to
     coll[coll.length]   coll[coll.length-i]   coll[i..coll.length]


 The problem is with multi-dimensional indices.
 Consider:
 a[$-1][$-2];

 There are two different values for $.


 Right. I don't understand why a solution like length does not apply, and  
 why opDollar would. In the above example, both a and a[$-1] should have  
 a length member or an opDollar method. What do I misinterpret?


I believe Don made a typo:

a[$-1, $-2];


-- 
Simen
Jan 01 2011
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/1/11 12:27 PM, Don wrote:

 spir wrote:

 Hello,


 [This is another currently unfixed point of D2 that prevents us
 implementing our project the way we wish it.]

 AFAIK, using '$' for custom collection types is not yet possible:
 oDollar is simply not implemented (correct?). But why do we need it? I
 do not understand the logic requiring an opDollar special method to
 "desugarise" the '$' operator. For me, '$' simply means length, so I
 would be fully happy with the simple rewrite of
 coll[$] coll[$-i] coll[i..$]
 to
 coll[coll.length] coll[coll.length-i] coll[i..coll.length]


 The problem is with multi-dimensional indices.
 Consider:
 a[$-1][$-2];

 There are two different values for $.


TDPL has solved that once and for all. The design hasn't been yet 
implemented.

Andrei
Jan 01 2011