www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Keywords, Symbols, Syntax, and Semantics

reply Benji Smith <dlanguage xxagg.com> writes:
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
Mar 07 2005
next sibling parent xs0 <xs0 xs0.com> writes:
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

Mar 07 2005
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
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.
Mar 07 2005
parent reply xs0 <xs0 xs0.com> writes:
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.
 
 

Mar 07 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"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.
Mar 07 2005
parent reply xs0 <xs0 xs0.com> writes:
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
Mar 07 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"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

Mar 07 2005
parent xs0 <xs0 xs0.com> writes:
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 :-(

Mar 08 2005
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
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
Mar 07 2005
prev sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"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.)
Mar 08 2005