Currently, D supports the special symbol $ to mean the end of a container/range.

However, there is no analogous symbol to mean "beginning of a container/range".  For arrays, there is none necessary, 0 is always the first element.  But not all containers are arrays.

I'm running into a dilemma for dcollections, I have found a way to make all containers support fast slicing (basically by imposing some limitations), and I would like to support *both* beginning and end symbols.

Currently, you can slice something in dcollections via:

coll[coll.begin..coll.end];

I could replace that end with $, but what can I replace coll.begin with?  0 doesn't make sense for things like linked lists, maps, sets, basically anything that's not an array.

One thing that's nice about opDollar is I can make it return coll.end, so I control the type.  With 0, I have no choice, I must take a uint, which means I have to check to make sure it's always zero, and throw an exception otherwise.

Would it make sense to have an equivalent symbol for the beginning of a container/range?

In regex, ^ matches beginning of the line, $ matches end of the line -- would there be any parsing ambiguity there?  I know ^ is a binary op, and $ means nothing anywhere else, so the two are not exactly equivalent.  I'm not very experienced on parsing ambiguities, but things like ~ can be unambiguous as binary and unary ops, so maybe it is possible.

So how does this look:  coll[^..$];

Thoughts? other ideas?

-Steve

== Quote from Steven Schveighoffer (schveiguy@yahoo.com)'s article
> Currently, D supports the special symbol $ to mean the end of a
> container/range.
> However, there is no analogous symbol to mean "beginning of a
> container/range".  For arrays, there is none necessary, 0 is always the
> first element.  But not all containers are arrays.
> I'm running into a dilemma for dcollections, I have found a way to make
> all containers support fast slicing (basically by imposing some
> limitations), and I would like to support *both* beginning and end symbols.
> Currently, you can slice something in dcollections via:
> coll[coll.begin..coll.end];
> I could replace that end with $, but what can I replace coll.begin with?
> 0 doesn't make sense for things like linked lists, maps, sets, basically
> anything that's not an array.
> One thing that's nice about opDollar is I can make it return coll.end, so
> I control the type.  With 0, I have no choice, I must take a uint, which
> means I have to check to make sure it's always zero, and throw an
> exception otherwise.
> Would it make sense to have an equivalent symbol for the beginning of a
> container/range?
> In regex, ^ matches beginning of the line, $ matches end of the line --
> would there be any parsing ambiguity there?  I know ^ is a binary op, and
> $ means nothing anywhere else, so the two are not exactly equivalent.  I'm
> not very experienced on parsing ambiguities, but things like ~ can be
> unambiguous as binary and unary ops, so maybe it is possible.
> So how does this look:  coll[^..$];
> Thoughts? other ideas?
> -Steve

I like it, if only for its happy aesthetic properties.

 Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> So how does this look:  coll[^..$];
>
> Thoughts? other ideas?
>
> -Steve

I like ^ for this usage, due (as you said) to its symmetry with
regexes. Other possible symbols would be # and ?, I believe.

There should be no ambiguities with the caret as far as I can see.

-- 
Simen

On Fri, 14 May 2010 09:32:31 -0400, Simen kjaeraas <simen.kjaras@gmail.com> wrote:

>   Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>
>> So how does this look:  coll[^..$];
>>
>> Thoughts? other ideas?
>>
>> -Steve
>
> I like ^ for this usage, due (as you said) to its symmetry with
> regexes. Other possible symbols would be # and ?, I believe.
>
> There should be no ambiguities with the caret as far as I can see.
>

? is the ternary operator
# is being used as to denote compiler Special Token Sequences

Robert Jacques <sandford@jhu.edu> wrote:

> On Fri, 14 May 2010 09:32:31 -0400, Simen kjaeraas <simen.kjaras@gmail.com> wrote:
>
>>   Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>>
>>> So how does this look:  coll[^..$];
>>>
>>> Thoughts? other ideas?
>>>
>>> -Steve
>>
>> I like ^ for this usage, due (as you said) to its symmetry with
>> regexes. Other possible symbols would be # and ?, I believe.
>>
>> There should be no ambiguities with the caret as far as I can see.
>>
>
> ? is the ternary operator
> # is being used as to denote compiler Special Token Sequences

Yeah, I found that the mesh wouldn't work. What should be no
problem, though.

-- 
Simen

On 2010-05-14 09:20:10 -0400, "Steven Schveighoffer" <schveiguy@yahoo.com> said:

> So how does this look:  coll[^..$];
> 
> Thoughts? other ideas?

	coll[µ..$];

The funny thing is that you can probably make it work today if you want since 'µ' is a valid identifier. Unfortunately you can't use €. :-)

Other characters you could use: ø, Ø, ß...

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On Fri, 14 May 2010 10:25:23 -0400, Michel Fortin <michel.fortin@michelf.com> wrote:

> On 2010-05-14 09:20:10 -0400, "Steven Schveighoffer" <schveiguy@yahoo.com> said:
>
>> So how does this look:  coll[^..$];
>>  Thoughts? other ideas?
>
> 	coll[µ..$];
>
> The funny thing is that you can probably make it work today if you want since 'µ' is a valid identifier. Unfortunately you can't use €. :-)

Not exactly, µ would have to be a global with the same type/meaning everywhere.  I want to control the type per container, so the compiler would still have to treat it special, or I would have to use coll[coll.µ..$].

If I didn't want to control the type, I could of course use 0 to that same effect.

Besides, I can't type that character or any of those others (had to copy-paste), so I don't see it being a viable alternative :)

-Steve

Steven Schveighoffer wrote:
> So how does this look:  coll[^..$];

nooooooooo <g>

> Thoughts? other ideas?

I'd just go with accepting the literal 0. Let's see how far that goes first.

"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:op.vco5zwhreav7ka@localhost.localdomain...
> Currently, D supports the special symbol $ to mean the end of a container/range.
>
> However, there is no analogous symbol to mean "beginning of a container/range".  For arrays, there is none necessary, 0 is always the first element.  But not all containers are arrays.
>
> I'm running into a dilemma for dcollections, I have found a way to make all containers support fast slicing (basically by imposing some limitations), and I would like to support *both* beginning and end symbols.
>
> Currently, you can slice something in dcollections via:
>
> coll[coll.begin..coll.end];
>
> I could replace that end with $, but what can I replace coll.begin with? 0 doesn't make sense for things like linked lists, maps, sets, basically anything that's not an array.
>
> One thing that's nice about opDollar is I can make it return coll.end, so I control the type.  With 0, I have no choice, I must take a uint, which means I have to check to make sure it's always zero, and throw an exception otherwise.
>
> Would it make sense to have an equivalent symbol for the beginning of a container/range?
>
> In regex, ^ matches beginning of the line, $ matches end of the line -- would there be any parsing ambiguity there?  I know ^ is a binary op, and $ means nothing anywhere else, so the two are not exactly equivalent.  I'm not very experienced on parsing ambiguities, but things like ~ can be unambiguous as binary and unary ops, so maybe it is possible.
>
> So how does this look:  coll[^..$];
>
> Thoughts? other ideas?
>

I think 0 makes perfect sense for any ordered container, or, really, anything for which $ makes sense (plus some things for which $ doesn't make sense, like an right-infinite range). However, the rest of your argument convinced me.

Michel Fortin <michel.fortin@michelf.com> wrote:

> On 2010-05-14 09:20:10 -0400, "Steven Schveighoffer" <schveiguy@yahoo.com> said:
>
>> So how does this look:  coll[^..$];
>>  Thoughts? other ideas?
>
> 	coll[µ..$];
>
> The funny thing is that you can probably make it work today if you want since 'µ' is a valid identifier. Unfortunately you can't use €. :-)
>
> Other characters you could use: ø, Ø, ß...

Sadly, ¢ is not on the list.

-- 
Simen