My first thought was that # was a bad character to use (mental association with C/C++ pre-processor). That doesn't mean we can't use another character, or change the keywords themselves.

I haven't tried to use static if at all really, but I agree a good IDE will be able to color it and make it stand out. D is designed to be easily parsable, for this exact reason.


The epoch concept is interesting, I note 'static' currently appears in 2 epochs, compile and init. If we decide the epoch idea has merit then we need to fix that I reckon.

Regan

On Thu, 23 Jun 2005 18:29:56 +0000 (UTC), pragma <pragma_member@pathlink.com> wrote:
> In article <d97vjn$20lk$1@digitaldaemon.com>, James McComb says...
>>
>> What about this? Instead of:
>>
>> static if() {}
>> else
>>
>> What about:
>>
>> #if() {} // static if
>> #else () {} // static else
>>
>> If would be easy to write code mixing #if, if, #else and else without
>> confusing them.
>>
>> Other 'static functions' that evaluate compile-time expressions could
>> use this pragma-style syntax, e.g:
>>
>> #assert() {} // instead of static assert
>> #is() {} // instead of iftype, or the 'static' is
>>          // (there would be both is and #is)
>>
>> It would be easy to extend this so that other functions have both
>> compile-time and run-time versions.
>>
>> What do you think?
>>
>> James McComb
>>
>> P.S. Maybe these should change (for consistency):
>>
>> #pragma() {} // instead of pragma
>> #debug() {} // instead of debug
>> #version() {} // instead of version
>>
>
> I've been quiet during this conversation, as I wanted to see what fell out of
> the debate, if anything.
>
> To sum up: I don't think this is a good idea for D.
>
> I honestly feel this would be a step backwards for D.  D's syntax is cleaner
> than C's, and would certainly be harder to read with this use of the '#' symbol.
> I for one find the run-time/compile-time schism between statements to be very
> clear-cut and simply a part of the learning curve for the language.
>
> I'll add that its rare to see a language embrace different language *epochs with
> the same syntax, inside the same context.  Its less syntactic baggage you have
> to carry around with you as there are fewer rules to adhere to.
>
> If consistency is what the community craves, then we should at least have #line
> changed to a more d-like "pragma(line,123,`xyz`)".  This would be more
> consistent with the rest of the langauge.  Its certainly a far cry from using
> '#' everywhere else to match, which would only make implementation easier.
>
> Also, a good syntax highlighter can easily fix the recognition issues between
> which *epoch a statment evaluates/runs under.
>
>
> (*) One can dissect any programming language into several distinct "epochs",
> that span the software's life from compilation through run-time.  D's syntax
> organizes pretty well across three epochs (D has no preprocessor):
>
> - Compile Time: static if, static is, pragma, version, debug, template, mixin,
> class, struct, delegate, function, typedef, alias, <constant expressions>
> - Init Time: static this, <static data manipulations and init>
> - Run Time: <operators and expressions>
>
> Other epochs that D leaves out are the preprocessor, and runtime code-generation
> which are supported in other langauges.
>
> (I think '#line' is being handled by D's lexer, which technically makes it a
> preprocessor token. I could be wrong about this.)
>
> - EricAnderton at yahoo

On Fri, 24 Jun 2005 00:55:06 +0200, Dawid Ciężarkiewicz wrote:

> James McComb wrote:
>> What do you think?
> 
> _Personaly_ I find 'static' combinations incedibly intuitive. Each time I see "static assert", "static class" or "static if" I fell comfortable with them (I just know what they are suppose to mean without thinking). And IMHO '#' sign looks bad.

And to me, I see "static" and think "fixed in place, stationary" because that is the English meaning of it - opposite to "dynamic". To me it is a stretch to think of "static" as meaning activity done at compile-time only. However, its the two-word token aspect that is the most disturbing. "static_if" would be better than "static if", IMHO.

I do not care if the token is "static_if", "#if", "@if", "compiler_if" or whatever, so long as it improves comprehension when people are reading source code.

> There are things more important than "look" but if this change would be because of cosmetic reasons than I would be voiting 'no'.

If by "cosmetic" you mean that we get no real benefit from changing something then I'd agree, but this change is not cosmetic. We will all get a real benefit from it, even the compiler writer.

-- 
Derek
Melbourne, Australia
24/06/2005 9:52:30 AM

On Fri, 24 Jun 2005 08:10:30 +1000, Derek Parnell wrote:

> On Thu, 23 Jun 2005 15:03:40 -0700, Unknown W. Brackets wrote:
> 
>> Why?  So long as the highlighter supports tokens with spaces in them, no context is needed whatsoever.
>> 
>> Other languages, such as SQL, also have multiword tokens which highlighters don't fall on the floor and spill blood over either.
>> 
>> -[Unknown]
>> 
>>> It would have to be a good one to highlight "static if" and "if" correctly in context.
> 
> I must be using a poor highlighting editor then. It colors "static if" as if it was "static" and "if" even though I have three tokens defined for it, all for different colors - "if", "static" and "static if".

I just tried a different editor that allows better highlighting rules and I can now differentiate between "static", "if" and "static if" ;-)

-- 
Derek
Melbourne, Australia
24/06/2005 11:43:59 AM

"James McComb" <ned@jamesmccomb.id.au> wrote in message news:d97vjn$20lk$1@digitaldaemon.com...
> What about this? Instead of:
>
> static if() {}
> else
>
> What about:
>
> #if() {} // static if
> #else () {} // static else

While they are visually distinct, and that's a worthy goal, there are some significant problems with it:

1) It looks too much like the C/C++ macro preprocessor. If it looks like a macro preprocessor, people will expect it to behave like a macro preprocessor. If the C/C++ preprocessor wasn't so deeply embedded into our psyche, this wouldn't be an issue, but I think it would be one.

2) Currently, one can use the C/C++ standalone preprocessor to preprocess D. (That's why there's the #line in existence, as #line is emitted by the preprocessor.) Using #if, etc., for other things will make this impossible.

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opssujo0zy23k2f5@nrage.netwin.co.nz...
> I haven't tried to use static if at all really, but I agree a good IDE will be able to color it and make it stand out. D is designed to be easily parsable, for this exact reason.

Yup. I don't see static if as a problem for syntax highlighters.

On Thu, 23 Jun 2005 22:16:53 -0700, Walter wrote:

> "James McComb" <ned@jamesmccomb.id.au> wrote in message news:d97vjn$20lk$1@digitaldaemon.com...
>> What about this? Instead of:
>>
>> static if() {}
>> else
>>
>> What about:
>>
>> #if() {} // static if
>> #else () {} // static else
> 
> While they are visually distinct, and that's a worthy goal ...

Given that it is a worthy goal, will you be doing something about achieving that goal? And if so, will that be before or after v1.0?

-- 
Derek
Melbourne, Australia
24/06/2005 3:45:27 PM

"Derek Parnell" <derek@psych.ward> wrote in message news:1qe0lfjugx0a$.1rkfw7uwcfspt.dlg@40tude.net...
> On Thu, 23 Jun 2005 22:16:53 -0700, Walter wrote:
>
> > "James McComb" <ned@jamesmccomb.id.au> wrote in message news:d97vjn$20lk$1@digitaldaemon.com...
> >> What about this? Instead of:
> >>
> >> static if() {}
> >> else
> >>
> >> What about:
> >>
> >> #if() {} // static if
> >> #else () {} // static else
> >
> > While they are visually distinct, and that's a worthy goal ...
>
> Given that it is a worthy goal, will you be doing something about
achieving
> that goal? And if so, will that be before or after v1.0?

It's a worthy goal, but there are other, competing goals. It's also a worthy goal for all the features of D. But which one do we pick to stand out more? I think this is the kind of thing that a good syntax highlighting editor excells at, because it can use different colors, fonts, boldface, underline, etc., and is all under user control.

Walter wrote:

>>What about:
>>
>>#if() {} // static if
>>#else () {} // static else
> 
> While they are visually distinct, and that's a worthy goal, there are some
> significant problems with it:
> 
> 1) It looks too much like the C/C++ macro preprocessor. If it looks like a
> macro preprocessor, people will expect it to behave like a macro
> preprocessor. If the C/C++ preprocessor wasn't so deeply embedded into our
> psyche, this wouldn't be an issue, but I think it would be one.
> 
> 2) Currently, one can use the C/C++ standalone preprocessor to preprocess D.
> (That's why there's the #line in existence, as #line is emitted by the
> preprocessor.) Using #if, etc., for other things will make this impossible.

I accept both of these points, and they are probably enough to kill off the idea of using #. But are you averse to using other characters?

For example, $:

// S stands for static... $ kind of looks like S
$if() {}   // pronounced static if
$else() {} // pronounced static else

(This might remind you of Perl, but I'm using $ on keywords, not variables. Other characters might be worth a look as well.)

On Fri, 24 Jun 2005 00:13:27 -0700, Walter wrote:

> "Derek Parnell" <derek@psych.ward> wrote in message news:1qe0lfjugx0a$.1rkfw7uwcfspt.dlg@40tude.net...
>> On Thu, 23 Jun 2005 22:16:53 -0700, Walter wrote:
>>
>>> "James McComb" <ned@jamesmccomb.id.au> wrote in message news:d97vjn$20lk$1@digitaldaemon.com...
>>>> What about this? Instead of:
>>>>
>>>> static if() {}
>>>> else
>>>>
>>>> What about:
>>>>
>>>> #if() {} // static if
>>>> #else () {} // static else
>>>
>>> While they are visually distinct, and that's a worthy goal ...
>>
>> Given that it is a worthy goal, will you be doing something about
> achieving
>> that goal? And if so, will that be before or after v1.0?
> 
> It's a worthy goal, but there are other, competing goals. It's also a worthy goal for all the features of D. But which one do we pick to stand out more? I think this is the kind of thing that a good syntax highlighting editor excells at, because it can use different colors, fonts, boldface, underline, etc., and is all under user control.

So ... reading between the lines (as the actual question was not directly
answered - (ever think of going in to politics?) ) it seems that you are
saying ...

(A) There are many worth, competing goals for D and you have prioritized
them.
(B) You will not be doing anything to achieve this particular goal in the D
language.
(C) You recommend using another tool to achieve it instead.

I would like to point out that syntax highlighting does not work so well with commonly printed forms of source code. Color printing of source code is not yet economical enough for common use either in the work place or in published hard-copy works. Most code reviewing is done using printed (hard-copy) source code listings.

-- 
Derek
Melbourne, Australia
24/06/2005 5:23:45 PM

"James McComb" <ned@jamesmccomb.id.au> wrote in message news:d9gc2f$1ica$1@digitaldaemon.com...
> I accept both of these points, and they are probably enough to kill off the idea of using #. But are you averse to using other characters?
>
> For example, $:
>
> // S stands for static... $ kind of looks like S
> $if() {}   // pronounced static if
> $else() {} // pronounced static else
>
> (This might remind you of Perl, but I'm using $ on keywords, not variables. Other characters might be worth a look as well.)

Using $ for various purposes has come up many times. (Currently it is an alternative to 'length' inside array indices.) Sometimes, @ gets proposed, but it looks too awful.

Is static if that bad? Wouldn't using a syntax highlighting editor be a better solution?