View mode: basic / threaded / horizontal-split · Log in · Help
March 07, 2005
Keywords, Symbols, Syntax, and Semantics
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
March 07, 2005
Re: Keywords, Symbols, Syntax, and Semantics
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
March 07, 2005
Re: Keywords, Symbols, Syntax, and Semantics
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.
March 08, 2005
Re: Keywords, Symbols, Syntax, and Semantics
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
March 08, 2005
Re: Keywords, Symbols, Syntax, and Semantics
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.
> 
>
March 08, 2005
Re: Keywords, Symbols, Syntax, and Semantics
"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.
March 08, 2005
Re: Keywords, Symbols, Syntax, and Semantics
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
March 08, 2005
Re: Keywords, Symbols, Syntax, and Semantics
"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
March 08, 2005
Re: Keywords, Symbols, Syntax, and Semantics
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 :-(
March 08, 2005
Re: Keywords, Symbols, Syntax, and Semantics
"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.)
Top | Discussion index | About this forum | D home