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

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).
>> 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.

That's a nice trick! But shhh, let's convince Walter do the right thing while he's bent on making ranges work.

Andrei

"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:
<snip>

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. 

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:
> <snip>
> 
> 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

"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:
>> <snip>
>>
>> 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

"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:gabkfm$2q5j$1@digitalmars.com...
> "Tomas Lindquist Olsen" wrote
<snip>
>> 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.
<snip>

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. 

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:
>>> <snip>
>>>
>>> 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

"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:
>>>> <snip>
>>>>
>>>> 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

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

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