March 04, 2005
In article <d07p4g$fp4$1@digitaldaemon.com>, Walter says...
>
>
>"U.Baumanis" <U.Baumanis_member@pathlink.com> wrote in message news:d06gf7$231k$1@digitaldaemon.com...
>> In article <d05as5$qei$1@digitaldaemon.com>, Walter says...
>> >
>> >
>> >"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:42261AE9.2080708@nospam.org...
>> >> A throw-in-the-air idea, what if we used minus ("-")?
>> >
>> >Because then array[length - 1] becomes array[- - 1].
>> >
>> > :-(
>> >
>> How about @ for "something big" and $ for length?
>
>That's what Matthew suggested. I'm leaning that way at this point.

It isn't readable at all, though. It would look like someone pasted a chunk of
Perl accidentally into some nice D code:
z[$-1..$]=y[$-z[$-1]]
I can't think of any other symbol in D that a C coder wouldn't be able to guess
what it means.


March 04, 2005
"brad beveridge" <brad@nowhere.com> wrote in message news:d06ks2$2817$1@digitaldaemon.com...
> I agree.  Anyhow, the "D preprocessor" is an imaginary thing that may
> not ever be needed.
> I don't see why D should cater to a tool that
> doesn't exist.  If a preprocessor is required, it should conform to D,
> not the other way around.  I vote that # should be used to denote array
> length.

There's no point to writing a D preprocessor. I just wanted to leave the door open for those folks who really, really, really want a preprocessor and so can use the standalone C preprocessor on it.

The #line support in the language also makes it possible for any tool, not just the C preprocessor, to generate D code and yet have the error messages point properly back into the original non-D source. Tools like yacc and lex come to mind as working this way.

P.S. The C preprocessor started out as just that, a text macro preprocessor that had nothing at all to do with C. It was a separate program entirely. If one carefully reads the preprocessor stuff in the C standard, it is still possible to make it a separate program. The preprocessor and C were combined into one compiler for performance, not semantic, reasons. Digital Mars includes a standalone C preprocessor, spp.exe, that could be used for D source. If one really, really, really wanted to <g>.


March 04, 2005
> 5) Invent a token for it that is other than '$'.

In that case, I'd suggest something untypable on most, if not all, computer keyboards.  Perhaps the "top of integral sign" ? (ALT+244 in Windows) could mean "beginning of array," while "vertical line attached to two horizontal lines"? (ALT+213) could mean "end of array."  Even better, if the ALT+numbers facility doesn't exist in other OSes, the characters will be completely inaccessible without the use of some kind of character map, or just copying and pasting.  And with any luck, these characters will be different based upon character encodings and fonts.

Or, we COULD just use "length."


March 04, 2005
Walter wrote:

> P.S. The C preprocessor started out as just that, a text macro preprocessor
> that had nothing at all to do with C. It was a separate program entirely. If
> one carefully reads the preprocessor stuff in the C standard, it is still
> possible to make it a separate program. The preprocessor and C were combined
> into one compiler for performance, not semantic, reasons. Digital Mars
> includes a standalone C preprocessor, spp.exe, that could be used for D
> source. If one really, really, really wanted to <g>.

It's called "cpp" in GCC, by the way. Usually one uses "gcc -E", though.

People have been using various forms of preprocessors for Java, too...
Makes more sense there since Java does not have conditional compilation.


I have been generating some of my more tedious D "ports", using Perl. :)
Example: http://www.algonet.se/~afb/d/universalalphas/universalalphas.pl
Generate: http://www.algonet.se/~afb/d/universalalphas/universalalphas.d

So it's still kinda useful. Perhaps not as a language "feature", though?

--anders
March 04, 2005
>How about @ for "something big" and $ for length?

Why does it need to be a single character? Couldn't it be e.g. <> ? To me <> looks a bit like something that means "length", @ or $ don't.

-- Matthias Becker


March 04, 2005
>> What about the ` (backtick) character, I don't think that we use that
>> for anything right now.
>
>I tried that once. On too many fonts, it is indistinguishable from a forward tick. It's unusuable.

Off-Topic: I thought you can't enter forward ticks on american keyboards at all? I thougth only ` and ' is avialble, not ´. Am I wrong?

`'´`'´

-- Matthias Becker


March 04, 2005
On Fri, 04 Mar 2005 18:24:44 +0000, Matthias Becker wrote:

>>> What about the ` (backtick) character, I don't think that we use that
>>> for anything right now.
>>
>>I tried that once. On too many fonts, it is indistinguishable from a forward tick. It's unusuable.
> 
> Off-Topic: I thought you can't enter forward ticks on american keyboards at all? I thougth only ` and ' is avialble, not ´. Am I wrong?
> 
> `'´`'´
> 
> -- Matthias Becker

It's shares the same key as ~ on North American keyboards.```

-JJR
March 04, 2005
On Fri, 04 Mar 2005 04:05:13 -0800, John Reimer wrote:

> On Fri, 04 Mar 2005 18:24:44 +0000, Matthias Becker wrote:
> 
>>>> What about the ` (backtick) character, I don't think that we use that
>>>> for anything right now.
>>>
>>>I tried that once. On too many fonts, it is indistinguishable from a forward tick. It's unusuable.
>> 
>> Off-Topic: I thought you can't enter forward ticks on american keyboards at all? I thougth only ` and ' is avialble, not ´. Am I wrong?
>> 
>> `'´`'´
>> 
>> -- Matthias Becker
> 
> It's shares the same key as ~ on North American keyboards.```
> 
> -JJR

Oops!  I see your point... you seem to be correct.

- JJR

March 05, 2005
"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?

-manfred
March 05, 2005
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 '$'.
> 
>