March 06, 2005
I've seen len used at least as often as length as a variable name...

-[Unknown]


> Seems like my former post about this went unnoticed, since all three responses  seemed to completely ignore my words. Therefore again:
> 
> How about using 'len' as a keyword with the meaning of the currently proposed '$'?
> 
> It is much easier to type and not much longer than the '$'.
> 
> Also it spares the problem of wasting the character $ on such a profane purpose.
> 
> Finally, the word 'length' could still be used to define the routine, while 'len' could be an operator keyword. (Any existing code using len as local variable would break: not silently but with a unmisunderstandable error message.
> 
> 
> 
> 
> Walter schrieb:
> 
>> [Starting a new thread on this, because the original is old and wandered off
>> topic too far]
>>
>> "Derek Parnell" <derek@psych.ward> wrote in message
>> news:cu90r1$1e7t$1@digitaldaemon.com...
>>
>>> Agreed. I have always supported the use of a symbol rather than an English
>>> word to represent the array's length property. I'm keen to promote the
>>> readibilty of source code by humans, so an extra 'dot' seems counter
>>> productive to that aim.
>>
>>
>>
>>
>> The $ idea for the length is a good one. The reason I didn't adopt it was
>> because I am trying to save $ for something big. I have a lot of thoughts
>> (inspired by some emails from Andrei A.) that $ could be very, very useful
>> in a future metaprogramming feature. Using $ as a length is a minor use, too
>> minor for such an important symbol!
>>
>> So the options are:
>>
>> 1) Make it illegal for length within [ ] to hide another length in an outer
>> scope. This would essentially preclude length being used as a global, or
>> even as a class member.
>>
>> 2) Same as (1), but only restrict it if length is a variable local to a
>> function.
>>
>> 3) Make length a keyword. This is not that much different from (1).
>>
>> 4) Change length to another identifier. Nothing stands out as being
>> obviously right.
>>
>> 5) Invent a token for it that is other than '$'.
>>
>>
March 06, 2005
"Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:d0e8od$2b1e$1@digitaldaemon.com...
> I've seen len used at least as often as length as a variable name...

That's far less important than the relative frequencies as property/method names.

Nonetheless, I don't think 'len' is any more of a go-er than 'length'


>
> -[Unknown]
>
>
>> Seems like my former post about this went unnoticed, since all three responses  seemed to completely ignore my words. Therefore again:
>>
>> How about using 'len' as a keyword with the meaning of the currently proposed '$'?
>>
>> It is much easier to type and not much longer than the '$'.
>>
>> Also it spares the problem of wasting the character $ on such a profane purpose.
>>
>> Finally, the word 'length' could still be used to define the routine, while 'len' could be an operator keyword. (Any existing code using len as local variable would break: not silently but with a unmisunderstandable error message.
>>
>>
>>
>>
>> Walter schrieb:
>>
>>> [Starting a new thread on this, because the original is old and wandered off topic too far]
>>>
>>> "Derek Parnell" <derek@psych.ward> wrote in message news:cu90r1$1e7t$1@digitaldaemon.com...
>>>
>>>> Agreed. I have always supported the use of a symbol rather than an English word to represent the array's length property. I'm keen to promote the readibilty of source code by humans, so an extra 'dot' seems counter productive to that aim.
>>>
>>>
>>>
>>>
>>> The $ idea for the length is a good one. The reason I didn't adopt it was because I am trying to save $ for something big. I have a lot of thoughts (inspired by some emails from Andrei A.) that $ could be very, very useful in a future metaprogramming feature. Using $ as a length is a minor use, too minor for such an important symbol!
>>>
>>> So the options are:
>>>
>>> 1) Make it illegal for length within [ ] to hide another length in an outer scope. This would essentially preclude length being used as a global, or even as a class member.
>>>
>>> 2) Same as (1), but only restrict it if length is a variable local to a
>>> function.
>>>
>>> 3) Make length a keyword. This is not that much different from (1).
>>>
>>> 4) Change length to another identifier. Nothing stands out as being obviously right.
>>>
>>> 5) Invent a token for it that is other than '$'.
>>>
>>> 


March 07, 2005
On Sat, 05 Mar 2005 15:24:27 +0100, Norbert Nemec <Norbert@Nemec-online.de> wrote:
> Seems like my former post about this went unnoticed, since all three responses  seemed to completely ignore my words. Therefore again:
>
> How about using 'len' as a keyword with the meaning of the currently proposed '$'?
>
> It is much easier to type and not much longer than the '$'.
>
> Also it spares the problem of wasting the character $ on such a profane purpose.
>
> Finally, the word 'length' could still be used to define the routine, while 'len' could be an operator keyword. (Any existing code using len as local variable would break: not silently but with a unmisunderstandable error message.

I dislike it. I think 'len' is common, it would annoy me greatly to have to rename all my 'len' vars.
I think any word solution suffers this problem of collision, as such any symbol solution is 'better'.

Regan


> Walter schrieb:
>> [Starting a new thread on this, because the original is old and wandered off
>> topic too far]
>>  "Derek Parnell" <derek@psych.ward> wrote in message
>> news:cu90r1$1e7t$1@digitaldaemon.com...
>>
>>> Agreed. I have always supported the use of a symbol rather than an English
>>> word to represent the array's length property. I'm keen to promote the
>>> readibilty of source code by humans, so an extra 'dot' seems counter
>>> productive to that aim.
>>    The $ idea for the length is a good one. The reason I didn't adopt it was
>> because I am trying to save $ for something big. I have a lot of thoughts
>> (inspired by some emails from Andrei A.) that $ could be very, very useful
>> in a future metaprogramming feature. Using $ as a length is a minor use, too
>> minor for such an important symbol!
>>  So the options are:
>>  1) Make it illegal for length within [ ] to hide another length in an outer
>> scope. This would essentially preclude length being used as a global, or
>> even as a class member.
>>  2) Same as (1), but only restrict it if length is a variable local to a
>> function.
>>  3) Make length a keyword. This is not that much different from (1).
>>  4) Change length to another identifier. Nothing stands out as being
>> obviously right.
>>  5) Invent a token for it that is other than '$'.
>>

March 07, 2005
On Sat, 05 Mar 2005 15:24:27 +0100, Norbert Nemec wrote:

> Seems like my former post about this went unnoticed, since all three responses  seemed to completely ignore my words. Therefore again:
> 
> How about using 'len' as a keyword with the meaning of the currently proposed '$'?

I guess that the probability of clashing with existing identifiers is
higher than acceptable.

> It is much easier to type and not much longer than the '$'.

How about a 3-letter token that is not likely to clash? maybe 'qzz', or '_l_' or 'xyx', or ...  ;-)

Or maybe we could use a non-English word? Arabic or Chinese (Mandarin)
might be good.

> Also it spares the problem of wasting the character $ on such a profane purpose.

Yes, the $ should be used for currency literals  ;-)

> Finally, the word 'length' could still be used to define the routine, while 'len' could be an operator keyword. (Any existing code using len as local variable would break: not silently but with a unmisunderstandable error message.

Each new keyword placed into a language reduces the number of unique identifier names available for coders, thus to do so would have to have overwhelming benefit. I'm not yet convinced that 'len' as a keyword has that much benefit for us.

-- 
Derek
Melbourne, Australia
7/03/2005 11:07:42 AM
March 07, 2005
Derek Parnell wrote:

>>Also it spares the problem of wasting the character $ on such a profane purpose.
> 
> Yes, the $ should be used for currency literals  ;-)

I thought I would be using € for those shortly here, but we voted no.

But I guess $ would work for the US/CA/AZ currency... Or for Perl :-)

--anders
March 08, 2005
"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:d0bbc5$2m4r$1@digitaldaemon.com...
> "Walter" <newshound@digitalmars.com> wrote:
>
> [...]
> > Context free means you can parse it without looking up the identifiers in the symbol table.
> [...]
>
> Do you mean this as a definition, or as an example for a grammar that is not context free?

It's not a formal definition, but it's a practical one.


1 2 3 4 5 6 7
Next ›   Last »