www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Re: opDollar

reply "Bill Baxter" <wbaxter gmail.com> writes:
On Tue, Sep 9, 2008 at 9:37 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Denis Koroskin wrote:
 4) We need some way of supporting dollar notation in user containers. The
 hack of using __dollar is bad (although it works).

It doesn't work for multiple dimensions. There should be an opDollar(uint dim) that gives the library information on which argument count it occured in. Consider: auto x = matrix[$-1, $-1]; Here the dollar's occurrences have different meanings. A good start would be to expand the above into: auto x = matrix[matrix.opDollar(0)-1, matrix.opDollar(1)-1];

Actually __dollar can be made to work with a bit of overhead. Make __dollar be a particular struct type, say EndRelativeIndex, that holds an integer offset and has overloaded opAdd and opSub, then make overloads for Matrix opIndex that accept that struct type. A "sufficiently smart compiler" could probably even get rid of the overhead. But all that trickery would be unnecessary if opDollar existed and behaved as you suggest. --bb
Sep 08 2008
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Tue, Sep 9, 2008 at 9:37 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Denis Koroskin wrote:
 4) We need some way of supporting dollar notation in user containers. The
 hack of using __dollar is bad (although it works).

dim) that gives the library information on which argument count it occured in. Consider: auto x = matrix[$-1, $-1]; Here the dollar's occurrences have different meanings. A good start would be to expand the above into: auto x = matrix[matrix.opDollar(0)-1, matrix.opDollar(1)-1];

Actually __dollar can be made to work with a bit of overhead. Make __dollar be a particular struct type, say EndRelativeIndex, that holds an integer offset and has overloaded opAdd and opSub, then make overloads for Matrix opIndex that accept that struct type. A "sufficiently smart compiler" could probably even get rid of the overhead. But all that trickery would be unnecessary if opDollar existed and behaved as you suggest.

That's a nice trick! But shhh, let's convince Walter do the right thing while he's bent on making ranges work. Andrei
Sep 08 2008
prev sibling next sibling parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Bill Baxter" <wbaxter gmail.com> wrote in message 
news:mailman.89.1220922329.19733.digitalmars-d-announce puremagic.com...
 On Tue, Sep 9, 2008 at 9:37 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Denis Koroskin wrote:
 4) We need some way of supporting dollar notation in user containers. 
 The
 hack of using __dollar is bad (although it works).



Agreed.
 It doesn't work for multiple dimensions. There should be an opDollar(uint
 dim) that gives the library information on which argument count it 
 occured
 in. Consider:


opDollar is the wrong choice of name. The op* methods are - as a rule - named after the semantic function of the operator, rather than what the operator looks like. For example, opMul not opAsterisk, opIndex not opSquareBrackets. Consequently, opStar is already inconsistently named; I think one such is enough. As for what the function to overload $ should be called ... how about opEnd? Where did this conversation begin? I can't seem to find any messages up the thread from the one I'm replying to now. Stewart. -- My e-mail address is valid but not my primary mailbox. Please keep replies on the 'group where everybody may benefit.
Sep 11 2008
parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Stewart Gordon wrote:
 "Bill Baxter" <wbaxter gmail.com> wrote in message 
 news:mailman.89.1220922329.19733.digitalmars-d-announce puremagic.com...
 On Tue, Sep 9, 2008 at 9:37 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Denis Koroskin wrote:
 4) We need some way of supporting dollar notation in user 
 containers. The
 hack of using __dollar is bad (although it works).



Agreed.
 It doesn't work for multiple dimensions. There should be an 
 opDollar(uint
 dim) that gives the library information on which argument count it 
 occured
 in. Consider:


opDollar is the wrong choice of name. The op* methods are - as a rule - named after the semantic function of the operator, rather than what the operator looks like. For example, opMul not opAsterisk, opIndex not opSquareBrackets. Consequently, opStar is already inconsistently named; I think one such is enough. As for what the function to overload $ should be called ... how about opEnd? Where did this conversation begin? I can't seem to find any messages up the thread from the one I'm replying to now. Stewart.

Since $ is used as a shortcut for for array.length, I'd say opLength is a better choice. Maybe I missed some of the discussion ... -Tomas
Sep 11 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Tomas Lindquist Olsen" wrote
 Stewart Gordon wrote:
 "Bill Baxter" <wbaxter gmail.com> wrote in message 
 news:mailman.89.1220922329.19733.digitalmars-d-announce puremagic.com...
 On Tue, Sep 9, 2008 at 9:37 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Denis Koroskin wrote:
 4) We need some way of supporting dollar notation in user containers. 
 The
 hack of using __dollar is bad (although it works).



Agreed.
 It doesn't work for multiple dimensions. There should be an 
 opDollar(uint
 dim) that gives the library information on which argument count it 
 occured
 in. Consider:


opDollar is the wrong choice of name. The op* methods are - as a rule - named after the semantic function of the operator, rather than what the operator looks like. For example, opMul not opAsterisk, opIndex not opSquareBrackets. Consequently, opStar is already inconsistently named; I think one such is enough. As for what the function to overload $ should be called ... how about opEnd? Where did this conversation begin? I can't seem to find any messages up the thread from the one I'm replying to now. Stewart.

Since $ is used as a shortcut for for array.length, I'd say opLength is a better choice. Maybe I missed some of the discussion ...

I'd agree with opEnd. opLength is only a valid construct for arrays, where the slice indexes are based on how far into the container the element is. For example, if you wanted to 'slice' an AA, you would use 2 keys for the slice 'indexes', what if the keys are strings? -Steve
Sep 11 2008
next sibling parent "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:gabkfm$2q5j$1 digitalmars.com...
 "Tomas Lindquist Olsen" wrote

 Since $ is used as a shortcut for for array.length, I'd say opLength is a 
 better choice. Maybe I missed some of the discussion ...

I'd agree with opEnd. opLength is only a valid construct for arrays, where the slice indexes are based on how far into the container the element is.

Moreover, 'end' and 'length' correspond only in the case of _zero-based_ arrays. If you create a class that implements 10-based arrays, you'll more likely want this notation for the end of the array than for the element that's 10 away from the end. You could even invent signed-index arrays - maybe there's a use for indexes ranging from -16 to 15 inclusive, IWC -$ would signify the beginning. Stewart. -- My e-mail address is valid but not my primary mailbox. Please keep replies on the 'group where everybody may benefit.
Sep 11 2008
prev sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Bill Baxter wrote:
 On Fri, Sep 12, 2008 at 11:10 AM, Steven Schveighoffer
 size doesn't work for slices that don't use sequential integers as index.
 i.e. imagine a sorted map (such as tree map) slice:

 I much prefer 'end' or 'last'.  It reads natural.  From the "one" element to
 the end.

Ok, so you want to change the meaning of $ altogether from being a number to something container dependent?

Also, even when $ is a number, it isn't the index of the "end" node or the "last" element. It's the index *after* the last element. I think only "length" or "size" are accurate. --benji
Sep 11 2008
next sibling parent reply Sclytrack <sclytrack pi.be> writes:
 Ok, so you want to change the meaning of $ altogether from being a
 number to something container dependent?

the "last" element. It's the index *after* the last element. I think only "length" or "size" are accurate.

size is the size in bytes length is the number of elements norm is the length, darn.
Sep 12 2008
parent Alix Pexton <_a_l_i_x_._p_e_x_t_o_n_ _g_m_a_i_l_._c_o_m_> writes:
Sclytrack wrote:
 Ok, so you want to change the meaning of $ altogether from being a
 number to something container dependent?

the "last" element. It's the index *after* the last element. I think only "length" or "size" are accurate.

size is the size in bytes length is the number of elements norm is the length, darn.

I like the sound of opTerminus as the function behind $ ^^ A...
Sep 12 2008
prev sibling parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Benji Smith" <dlanguage benjismith.net> wrote in message 
news:gacrn7$221v$1 digitalmars.com...
<snip>
 Also, even when $ is a number, it isn't the index of the "end" node or the 
 "last" element. It's the index *after* the last element.

 I think only "length" or "size" are accurate.

So you think that, in the case of a 3-based array type, $ should be the index of the antepenultimate element? Stewart. -- My e-mail address is valid but not my primary mailbox. Please keep replies on the 'group where everybody may benefit.
Sep 12 2008
parent Benji Smith <dlanguage benjismith.net> writes:
Stewart Gordon wrote:
 "Benji Smith" <dlanguage benjismith.net> wrote in message 
 news:gacrn7$221v$1 digitalmars.com...
 <snip>
 Also, even when $ is a number, it isn't the index of the "end" node or 
 the "last" element. It's the index *after* the last element.

 I think only "length" or "size" are accurate.

So you think that, in the case of a 3-based array type, $ should be the index of the antepenultimate element? Stewart.

I didn't say anything about what it *should* mean. I was just saying that it certainly doesn't refer to the last element. I have mixed feelings about what $ should mean. In an array slice, it makes sense for $ to be the length, because slicing uses an open range on the right-hand side array[0..5] // selects elements 0 - 4 array[5..$] // selects everything from 5 to the end But I also think the $, when used alone in an array index, ought to refer to the last element: array[$] // ideally: selects the last element. Of course, the way it really works right now is like this: array[$ - 1] // awkward: selects last element array[$] // out of bounds. access violation. So, I'm not really sure what I want. Above all, I think $ should have a consistent meaning. --benji
Sep 12 2008
prev sibling next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Sep 12, 2008 at 2:28 AM, Steven Schveighoffer
<schveiguy yahoo.com> wrote:
 "Tomas Lindquist Olsen" wrote
 Stewart Gordon wrote:
 "Bill Baxter" <wbaxter gmail.com> wrote in message
 news:mailman.89.1220922329.19733.digitalmars-d-announce puremagic.com...
 On Tue, Sep 9, 2008 at 9:37 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Denis Koroskin wrote:
 4) We need some way of supporting dollar notation in user containers.
 The
 hack of using __dollar is bad (although it works).



Agreed.
 It doesn't work for multiple dimensions. There should be an
 opDollar(uint
 dim) that gives the library information on which argument count it
 occured
 in. Consider:


opDollar is the wrong choice of name. The op* methods are - as a rule - named after the semantic function of the operator, rather than what the operator looks like. For example, opMul not opAsterisk, opIndex not opSquareBrackets. Consequently, opStar is already inconsistently named; I think one such is enough. As for what the function to overload $ should be called ... how about opEnd? Where did this conversation begin? I can't seem to find any messages up the thread from the one I'm replying to now. Stewart.

Since $ is used as a shortcut for for array.length, I'd say opLength is a better choice. Maybe I missed some of the discussion ...

I'd agree with opEnd. opLength is only a valid construct for arrays, where the slice indexes are based on how far into the container the element is. For example, if you wanted to 'slice' an AA, you would use 2 keys for the slice 'indexes', what if the keys are strings?

I'd say opSize, ala STL. They got it right. Should .size for arrays too, not .length. "Size" is a word that generalizes pretty well, "length" is not. Also don't forget about opStar! It shoudn't be called that either. opDeref is what it really wants to be. :-) [/dream mode off] --bb
Sep 11 2008
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Bill Baxter" wrote
 On Fri, Sep 12, 2008 at 2:28 AM, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:
 "Tomas Lindquist Olsen" wrote
 Stewart Gordon wrote:
 "Bill Baxter" <wbaxter gmail.com> wrote in message
 news:mailman.89.1220922329.19733.digitalmars-d-announce puremagic.com...
 On Tue, Sep 9, 2008 at 9:37 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Denis Koroskin wrote:
 4) We need some way of supporting dollar notation in user 
 containers.
 The
 hack of using __dollar is bad (although it works).



Agreed.
 It doesn't work for multiple dimensions. There should be an
 opDollar(uint
 dim) that gives the library information on which argument count it
 occured
 in. Consider:


opDollar is the wrong choice of name. The op* methods are - as a rule - named after the semantic function of the operator, rather than what the operator looks like. For example, opMul not opAsterisk, opIndex not opSquareBrackets. Consequently, opStar is already inconsistently named; I think one such is enough. As for what the function to overload $ should be called ... how about opEnd? Where did this conversation begin? I can't seem to find any messages up the thread from the one I'm replying to now. Stewart.

Since $ is used as a shortcut for for array.length, I'd say opLength is a better choice. Maybe I missed some of the discussion ...

I'd agree with opEnd. opLength is only a valid construct for arrays, where the slice indexes are based on how far into the container the element is. For example, if you wanted to 'slice' an AA, you would use 2 keys for the slice 'indexes', what if the keys are strings?

I'd say opSize, ala STL. They got it right. Should .size for arrays too, not .length. "Size" is a word that generalizes pretty well, "length" is not.

size doesn't work for slices that don't use sequential integers as index. i.e. imagine a sorted map (such as tree map) slice: TreeMap!(char[], char[]) tm; // create a slice of the treemap auto slice = tm["one".."two"]; Replace the second with 'length' or 'size', and it looks weird: auto slice = tm["one"..length] auto slice = tm["one"..size] I much prefer 'end' or 'last'. It reads natural. From the "one" element to the end.
 Also don't forget about opStar!  It shoudn't be called that either.
 opDeref is what it really wants to be.  :-)

 [/dream mode off]

I agree with you there. -Steve
Sep 11 2008
prev sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Sep 12, 2008 at 11:10 AM, Steven Schveighoffer
<schveiguy yahoo.com> wrote:
 "Bill Baxter" wrote
 On Fri, Sep 12, 2008 at 2:28 AM, Steven Schveighoffer
 For example, if you wanted to 'slice' an AA, you would use 2 keys for the
 slice 'indexes', what if the keys are strings?

I'd say opSize, ala STL. They got it right. Should .size for arrays too, not .length. "Size" is a word that generalizes pretty well, "length" is not.

size doesn't work for slices that don't use sequential integers as index. i.e. imagine a sorted map (such as tree map) slice: TreeMap!(char[], char[]) tm; // create a slice of the treemap auto slice = tm["one".."two"]; Replace the second with 'length' or 'size', and it looks weird: auto slice = tm["one"..length] auto slice = tm["one"..size] I much prefer 'end' or 'last'. It reads natural. From the "one" element to the end.

Ok, so you want to change the meaning of $ altogether from being a number to something container dependent? I guess that may generalize better... But then shouldn't it evaluate to an iterator? Argh! :-) --bb
Sep 11 2008
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Bill Baxter" wrote
 On Fri, Sep 12, 2008 at 11:10 AM, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:
 "Bill Baxter" wrote
 On Fri, Sep 12, 2008 at 2:28 AM, Steven Schveighoffer
 For example, if you wanted to 'slice' an AA, you would use 2 keys for 
 the
 slice 'indexes', what if the keys are strings?

I'd say opSize, ala STL. They got it right. Should .size for arrays too, not .length. "Size" is a word that generalizes pretty well, "length" is not.

size doesn't work for slices that don't use sequential integers as index. i.e. imagine a sorted map (such as tree map) slice: TreeMap!(char[], char[]) tm; // create a slice of the treemap auto slice = tm["one".."two"]; Replace the second with 'length' or 'size', and it looks weird: auto slice = tm["one"..length] auto slice = tm["one"..size] I much prefer 'end' or 'last'. It reads natural. From the "one" element to the end.

Ok, so you want to change the meaning of $ altogether from being a number to something container dependent? I guess that may generalize better... But then shouldn't it evaluate to an iterator? Argh! :-)

I think it should evaluate to the same type as you would specify as the first argument to the slice. If that happens to be an integer, it's an integer, if it happens to be a string, it should be a string :) If iterators are supported for a given container, it makes logical sense that slicing based on iterators should be supported. I support slicing based on 'cursors,' which are basically iterators, in dcollections (well, only for ArrayList now, but I plan to do it for LinkedList and the tree types). opLength/opSize implies that it should ALWAYS be an integer. 'sall I'm sayin. -Steve
Sep 12 2008