I gotta say, I strongly strongly strongly dislike the current proposal on the table to use a single-character symbol (like $ or @ or #) to represent the length of an array.

I don't like it at all.

In my opinion, there needs to be some consistency in the use of keywords and symbols to convey both the syntax and semantics of the language.

Up until now, that usage has been pretty consistent. Symbolic characters have (so far) been used exclusively as operators. Whenever the language has needed a way to express properties, it has used keywords.

The separation is nice...

symbols --> syntax
keywords --> semantics

The use of a single symbolic character in a semantic context, to denote the "length" property is undesirable not because it's "ugly" or because it "looks like perl" but because it violates the existing conventions of syntactical and semantic expression in the language.

To me, a proposal like this seems like a knee-jerk reaction to a small problem (collision with some existing variable names) rather than reflecting a well-thought-out design.

On the other hand, if we want to introduce @#$^ characters as prefixes for properties, I might support that kind of syntax...

      int[] slice = full_array[x .. ^length];

...but I really really really dislike the inconsistency introduced into the language if we start using symbol characters as shortcuts for properties.

And that's all I've got to say.

Thaks,

--Benji Smith

I fully agree and again express support for $length, $args and the rest of the bunch.

I feel that $ is most appropriate because (in random order)
- it's most similar to a letter and looks best (at least to me)
- it is used in other languages for variables (Java, PHP, Perl), so is
  still potentially familiar
- is not legal in a normal identifier in D, so it shows that $vars
  are 'special'


xs0


Benji Smith wrote:
> I gotta say, I strongly strongly strongly dislike the current proposal
> on the table to use a single-character symbol (like $ or @ or #) to
> represent the length of an array.
> 
> I don't like it at all.
> 
> In my opinion, there needs to be some consistency in the use of
> keywords and symbols to convey both the syntax and semantics of the
> language.
> 
> Up until now, that usage has been pretty consistent. Symbolic
> characters have (so far) been used exclusively as operators. Whenever
> the language has needed a way to express properties, it has used
> keywords.
> 
> The separation is nice...
> 
> symbols --> syntax
> keywords --> semantics
> 
> The use of a single symbolic character in a semantic context, to
> denote the "length" property is undesirable not because it's "ugly" or
> because it "looks like perl" but because it violates the existing
> conventions of syntactical and semantic expression in the language.
> 
> To me, a proposal like this seems like a knee-jerk reaction to a small
> problem (collision with some existing variable names) rather than
> reflecting a well-thought-out design.
> 
> On the other hand, if we want to introduce @#$^ characters as prefixes
> for properties, I might support that kind of syntax...
> 
>       int[] slice = full_array[x .. ^length];
> 
> ....but I really really really dislike the inconsistency introduced
> into the language if we start using symbol characters as shortcuts for
> properties.
> 
> And that's all I've got to say.
> 
> Thaks,
> 
> --Benji Smith

One note on 'length' - it makes it easy for a class to have array semantics, as the 'length' will be looked up as a property of the class instance.

On Mon, 07 Mar 2005 16:28:07 -0700, Benji Smith wrote:

> I gotta say, I strongly strongly strongly dislike the current proposal on the table to use a single-character symbol (like $ or @ or #) to represent the length of an array.
> 
> I don't like it at all.
> 
> In my opinion, there needs to be some consistency in the use of keywords and symbols to convey both the syntax and semantics of the language.
> 
> Up until now, that usage has been pretty consistent. Symbolic characters have (so far) been used exclusively as operators. Whenever the language has needed a way to express properties, it has used keywords.
> 
> The separation is nice...
> 
> symbols --> syntax
> keywords --> semantics
> 
> The use of a single symbolic character in a semantic context, to denote the "length" property is undesirable not because it's "ugly" or because it "looks like perl" but because it violates the existing conventions of syntactical and semantic expression in the language.
> 
> To me, a proposal like this seems like a knee-jerk reaction to a small problem (collision with some existing variable names) rather than reflecting a well-thought-out design.
> 
> On the other hand, if we want to introduce @#$^ characters as prefixes for properties, I might support that kind of syntax...
> 
>       int[] slice = full_array[x .. ^length];
> 
> ...but I really really really dislike the inconsistency introduced into the language if we start using symbol characters as shortcuts for properties.
> 
> And that's all I've got to say.
> 
> Thaks,
> 
> --Benji Smith

Well said and well argued. When I sit down and think about it, my only criteria are that it be short, legible, meaningful, and doesn't clash with any identifiers. So I'd back something like $len, #len, ^len, or @len. But I guess $length, et al would also suffice.

    result_array[$len] = full_array[$len - var .. index_array[$len]]

to me is tidier than

    result_array[result_array.length] = full_array[full_array.length - var
                   .. index_array[index_array.length]]

-- 
Derek
Melbourne, Australia
8/03/2005 10:40:12 AM

Yup, but isn't length an issue only inside [], because it introduces a new scope and overrides other variables called 'length'?


xs0


Walter wrote:
> One note on 'length' - it makes it easy for a class to have array semantics,
> as the 'length' will be looked up as a property of the class instance.
> 
> 

"xs0" <xs0@xs0.com> wrote in message news:d0iq5j$mev$2@digitaldaemon.com...
> Yup, but isn't length an issue only inside [], because it introduces a new scope and overrides other variables called 'length'?

Yup.

Hmm, now that I think about it, it would be neat to have $ call length() on classes?

I still hope you'll change $ to $len or $length.. $&1?2:3 just doesn't look very nice to me :)


xs0

"xs0" <xs0@xs0.com> wrote in message news:d0iv7h$rqf$1@digitaldaemon.com...
> Hmm, now that I think about it, it would be neat to have $ call length()
> on classes?

It could, it's just more junk in the compiler :-(

> I still hope you'll change $ to $len or $length.. $&1?2:3 just doesn't look very nice to me :)
>
>
> xs0

Well, it's your call, but I think it would fit the classes-can-have-array-semantics strategy.. otoh, I guess it's not that important (as in, it is not strictly necessary, because one can always use obj.length).. it would allow use of $ in templates (that can accept either arrays or array-like objects), though..

Anyway, if it takes 5 minutes (for you to implement it), I guess it's worth it, if it takes 2 hours, I guess it's not (at least at this time).


xs0


Walter wrote:
> "xs0" <xs0@xs0.com> wrote in message news:d0iv7h$rqf$1@digitaldaemon.com...
> 
>>Hmm, now that I think about it, it would be neat to have $ call length()
>>on classes?
> 
> 
> It could, it's just more junk in the compiler :-(

"Benji Smith" <dlanguage@xxagg.com> wrote in message news:21op21541aju6v0j4b8giivhdfv6g9fjp4@4ax.com...
>I gotta say, I strongly strongly strongly dislike the current proposal
> on the table to use a single-character symbol (like $ or @ or #) to
> represent the length of an array.
>
> I don't like it at all.
>
> In my opinion, there needs to be some consistency in the use of keywords and symbols to convey both the syntax and semantics of the language.
>
> Up until now, that usage has been pretty consistent. Symbolic characters have (so far) been used exclusively as operators. Whenever the language has needed a way to express properties, it has used keywords.
>
> The separation is nice...
>
> symbols --> syntax
> keywords --> semantics
>
> The use of a single symbolic character in a semantic context, to denote the "length" property is undesirable not because it's "ugly" or because it "looks like perl" but because it violates the existing conventions of syntactical and semantic expression in the language.
>
> To me, a proposal like this seems like a knee-jerk reaction to a small problem (collision with some existing variable names) rather than reflecting a well-thought-out design.
>
> On the other hand, if we want to introduce @#$^ characters as prefixes for properties, I might support that kind of syntax...
>
>      int[] slice = full_array[x .. ^length];
>
> ...but I really really really dislike the inconsistency introduced into the language if we start using symbol characters as shortcuts for properties.
>
> And that's all I've got to say.

Largely agree. I'm now off the idea of $ as a standalone 'keyword', but rather as a local-context modifier, whatever that means.

For the record, I think @ should be reserved for future insights by Walter.

# is already reserved as preprocessor stuff (albiet only used by #line)

^ is an arithmetic operator, so not suitable. (It also looks like that awful C++.NET syntax.)