"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d0nup9$ei4$1@digitaldaemon.com...
> (btw, I'm now moving away from $ after having been a great supporter. And feeling a little guilty that my former enthusiasm may have helped influence Walter to go down this cul-de-sac <g>)

No worries, I deliberately put it in on a trial basis. It appears to be a sinking ship, though. I wouldn't be sorry to see it go.

BTW, there's a subtlety here that has been largely overlooked. Suppose one creates a class that overloads [] and wants to look like an array? What's $ then? For length, it was simple. The 'this' pointer for the class reference is added to the scope on the opening [, and removed on the closing ]. Then, if the class declares a 'length' property, that length will be found and used.

Of course, I can bash the compiler to make $ look up a classes' length property, too, but that just strikes me as uuugly.

Maybe we're just going at this all wrong. I really like length as the implicitly declared array length, for the reason it is straightforward and it just looks visually appealing in use. Having it be __length is ugly, and $length isn't much better. Both of the latter would also require the this.length lookup hack.

Maybe the right answer is to just make it illegal to declare a local variable with the name 'length'. Fields, functions, etc., could still be named 'length'. It's still a bit of a hack, but language design is rarely free of that stuff.

Matthew wrote:

> 
> 
> and now you've lost me completely.
> 
> You seem to be saying that familiarity with some languages is fine and with others it's not. That may be so, but drawing the line is always going to be an arbitrary decision. Have I missed anything beyond that?
> 

All I am saying is that C-isms are probably a lot more familiar to D users than Python-isms, Perlisms, et al.  There is no $ operator that I'm familiar with in C, so I think it is a bad choice.

Would the syntax be useful to some? Sure it would. And it would be totally confusing to anyone trying to learn the language and shrug off the C++ syntactical complexities.

-David

Walter wrote:

> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message
> news:d0nup9$ei4$1@digitaldaemon.com...
> 
>>(btw, I'm now moving away from $ after having been a great supporter.
>>And feeling a little guilty that my former enthusiasm may have helped
>>influence Walter to go down this cul-de-sac <g>)
> 
> 
> No worries, I deliberately put it in on a trial basis. It appears to be a
> sinking ship, though. I wouldn't be sorry to see it go.
> 
> BTW, there's a subtlety here that has been largely overlooked. Suppose one
> creates a class that overloads [] and wants to look like an array? What's $
> then? For length, it was simple. The 'this' pointer for the class reference
> is added to the scope on the opening [, and removed on the closing ]. Then,
> if the class declares a 'length' property, that length will be found and
> used.
> 
> Of course, I can bash the compiler to make $ look up a classes' length
> property, too, but that just strikes me as uuugly.
> 
> Maybe we're just going at this all wrong. I really like length as the
> implicitly declared array length, for the reason it is straightforward and
> it just looks visually appealing in use. Having it be __length is ugly, and
> $length isn't much better. Both of the latter would also require the
> this.length lookup hack.
> 
> Maybe the right answer is to just make it illegal to declare a local
> variable with the name 'length'. Fields, functions, etc., could still be
> named 'length'. It's still a bit of a hack, but language design is rarely
> free of that stuff.
> 
> 
Did you consider my suggestion just to allow arrays to use the with() syntax, Walter?

with( a ) x[] = a[0..length-1];

I suppose it could lead to some weird things like:

int[] a = new int[100];
int[] x;
with(a) x = dup;

but it would still be pretty clean and not require new syntax.

"David Medlock" <amedlock@nospam.com> wrote in message news:d0o5mk$l7o$1@digitaldaemon.com...
> Matthew wrote:
>
>>
>>
>> and now you've lost me completely.
>>
>> You seem to be saying that familiarity with some languages is fine and with others it's not. That may be so, but drawing the line is always going to be an arbitrary decision. Have I missed anything beyond that?
>>
>
> All I am saying is that C-isms are probably a lot more familiar to D users than Python-isms, Perlisms, et al.  There is no $ operator that I'm familiar with in C, so I think it is a bad choice.
>
> Would the syntax be useful to some? Sure it would. And it would be totally confusing to anyone trying to learn the language and shrug off the C++ syntactical complexities.

Ok, well that is what I thought you meant. But I think it's a fatuous point because (i) syntactic familiarity can be a double-edged sword, and (ii) there's plenty in D to confuse a C-language oldie who's new to D.

And now I think we're entering the pointless territory, so I'll shut up. Feel free to have the last word ... :-)

"Walter" <newshound@digitalmars.com> wrote in message news:d0o4ji$k7k$1@digitaldaemon.com...
>
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d0nup9$ei4$1@digitaldaemon.com...
>> (btw, I'm now moving away from $ after having been a great supporter. And feeling a little guilty that my former enthusiasm may have helped influence Walter to go down this cul-de-sac <g>)
>
> No worries, I deliberately put it in on a trial basis. It appears to
> be a
> sinking ship, though. I wouldn't be sorry to see it go.
>
> BTW, there's a subtlety here that has been largely overlooked. Suppose
> one
> creates a class that overloads [] and wants to look like an array?
> What's $
> then? For length, it was simple. The 'this' pointer for the class
> reference
> is added to the scope on the opening [, and removed on the closing ].
> Then,
> if the class declares a 'length' property, that length will be found
> and
> used.
>
> Of course, I can bash the compiler to make $ look up a classes' length property, too, but that just strikes me as uuugly.
>
> Maybe we're just going at this all wrong. I really like length as the
> implicitly declared array length, for the reason it is straightforward
> and
> it just looks visually appealing in use. Having it be __length is
> ugly, and
> $length isn't much better. Both of the latter would also require the
> this.length lookup hack.

I'm not convinced that $length is bad, and that's partly because I _like_ the idea of it doing property lookups. I don't see any real difference between an array having a length property and a Vector having a length property or a std.openrj.Record having a length property.

But this brings us onto a much broader debate about properties, and my desire to make properties much less implicit than they are, and that's a huge 'nother debate that can wait. (I'm saving 'em up, so as I can be mean to you constantly for the next 3 months <g>.)

May I suggest that the way forward is to remove _all_ shortcuts for length, and just require people to do the non-too-taxing-if-we're-honest business of prefixing .length with the thing it's the length of?

Then, from that more basic standpoint we can take a little time to identity how much of a problem really exists.

(After all, we don't want to end up like Perl, do we? It amuses me a little to note that of all the "I like feature X from language Y" that we all occasionally do, no-one ever sets Y=Perl. <g>)

> Maybe the right answer is to just make it illegal to declare a local
> variable with the name 'length'. Fields, functions, etc., could still
> be
> named 'length'. It's still a bit of a hack, but language design is
> rarely
> free of that stuff.

No. I strongly disagree with this. It's either a keyword (and therefore reserved from identifiers) or it's not. Otherwise, we're in .HACK land.

"David Medlock" <amedlock@nospam.com> wrote in message news:d0o5s1$l7o$2@digitaldaemon.com...
> Did you consider my suggestion just to allow arrays to use the with()
> syntax, Walter?
>
> with( a ) x[] = a[0..length-1];
>
> I suppose it could lead to some weird things like:
>
> int[] a = new int[100];
> int[] x;
> with(a) x = dup;
>
> but it would still be pretty clean and not require new syntax.

I think it works for singly dimensioned arrays, but not for multiply dimensioned ones.

In article <d0o5s1$l7o$2@digitaldaemon.com>, David Medlock says...
>
>Walter wrote:
>> Maybe the right answer is to just make it illegal to declare a local variable with the name 'length'. Fields, functions, etc., could still be named 'length'. It's still a bit of a hack, but language design is rarely free of that stuff.
>> 
>> 
>Did you consider my suggestion just to allow arrays to use the with() syntax, Walter?
>
>with( a ) x[] = a[0..length-1];
>
>I suppose it could lead to some weird things like:
>
>int[] a = new int[100];
>int[] x;
>with(a) x = dup;
>
>but it would still be pretty clean and not require new syntax.

::sound of hand smacking on own forehead::

It's so simple.  I feel downright foolish for backing the '$' solution at this point.

From the docs: "The with statement is a way to simplify repeated references to the same object."

I tried it for fun, and dmd 0.116 does indeed kick back an error complaining that 'a' isn't an object.  Seems to me this is broken anyway since with() would make just as much sense with anything with 'properties' attached to it (which covers the entirely language really).

int i;
with(i) writefln("maxint is: %d",max); // useless but this *should* be valid

Not only will it fix all this array '$' business, but it'll make things more consistent.

- EricAnderton at yahoo

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d0nv4f$ett$1@digitaldaemon.com...
>
> "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d0nlai$302$1@digitaldaemon.com...
>>
>> "David Medlock" <amedlock@nospam.org> wrote in message news:d0niiq$31d5$1@digitaldaemon.com...
>>> <snip>
>>>
>>> I think the $ is a bad choice.
>>>
>>> What does a dollar sign have to do with length of an array?
>>> We use '.' and [] because C/C++ uses them.
>>> What is the precedence for '$'?
>>> It lowers readability and doesn't add much at all to the language.
>>>
>>> This similar to some choices made durings C++'s lifetime(C too! see trigraphs) which makes for cluttered code, lots of special syntaxes to rememeber, and general inconsistency.  Not this one decision, but add them all up and you get a mess.
>>>
>>> All my opinion, of course.
>>> -David
>>>
>>
>> I agree. Using an identifier is something people recognize and can understand. Seeing $ will confuse people and think there is more magic in there than there is.  When I see $ used for this (or even when I imagine $length, $arguments, etc) I can't relate it to any other C-like language construct that I know.
>
> Hmm. That actually gets a big "So what?". I mean, seeing char[], aa declaration syntax, opThis and opThat, are all foreign/unfamiliar.
>
> To me it seems not the slightest bizarre. But then I am a big fan of Ruby, which has such things by the bucketload.
>
>> It actually looks to me like a preprocessor hook of some kind or shell-like environment variable expansion.
>
> Is that a bad thing? I think the opposite. If we adopt this $xyz thing - i.e. we can find significant use, and it can have good unambiguous semantics - then the distinctness of it is precisely what's required.
>
>
>

When initializing a static array, the : (colon) is used to refer to a specific index. Perhaps this could be adapted to refer to the length when inside the brackets. It wouldn't look too foreign.

    items[0 .. :length]
    items[:length - 1]

and so on.

It's also reminicent of the C++ scope operator (::) - whether that's a good thing or bad I'll not comment on.

On Wed, 9 Mar 2005 16:27:00 -0800, "Walter" <newshound@digitalmars.com> wrote:

>Maybe the right answer is to just make it illegal to declare a local variable with the name 'length'. Fields, functions, etc., could still be named 'length'. It's still a bit of a hack, but language design is rarely free of that stuff.

Personally, I think the best way would be to make it illegal to use the length property without the name of the array/object to which it belongs. For example...

   // illegal, unless "length" has been declared as a variable
   int[] slice = full[x .. length];

...would be illegal, and would be replaced by...

   int[] slice = full[x .. full.length];

...or, in cases where the array has been poorly_named_to_begin_with, you could do something like this...

   int len = idioticly_long_variable_name.length;
   int[] slice = idioticly_long_variable_name[x .. len];

It's slightly less syntactically-sugary than using "length" without a prefix, or using a "$" token, but the headaches avoided by doing so would be worth it, in my opinion.

--Benji Smith

> That may be so, but that's a piss poor rationale for a criticism. Were it as black and white as that, then ignorance of regex would be the thing to address. It's not exactly a useless skill to have ...

To tell the truth, I've never even seen regular expressions before I came across D, and I haven't exactly lived under a rock.  It seems like anyone who uses a Posix-based OS has knowledge of them, and I'm not sure why, as I've personally never used Linux or the like.

> Ok, that's opinion. Gotcha. Now, how about some substantiation?

Sorry, I have nothing to prove.