www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - #if, #else, #assert and #is

reply James McComb <ned jamesmccomb.id.au> writes:
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
Jun 20 2005
next sibling parent Derek Parnell <derek psych.ward> writes:
On Tue, 21 Jun 2005 12:56:01 +1000, James McComb wrote:

 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
Yes, this is the sort of thing I was thinking of. It would enhance the legibility of code immensely. It quickly signals a compile-time activity and is hard to confuse with run-rime statements. It greps well too. -- Derek Melbourne, Australia 21/06/2005 1:07:45 PM
Jun 20 2005
prev sibling next sibling parent "Lionello Lunesu" <lio lunesu.removethis.com> writes:
I have to agree..

It's a great a idea to put this functionality in the language, instead of a 
seperate preprocess step, but to make it look like normal code is merely 
confusing.

Furthermore, any fancy IDE will want to use a different color for the 
highlighting of these 'preprocessor' commands, which might be tricky in the 
case of "static if ... else".

L.

"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
|
| 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
|
|
|
|
|
| 
Jun 21 2005
prev sibling next sibling parent Nod <Nod_member pathlink.com> writes:
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
Yes, I like this. Easier to both read and write imo. Very intuitive also, for anyone coming from C/C++. Although I cringe a bit every time I see that syntax, due to previous battles with the C preprocessor, I think D can change that mental image. -Nod-
Jun 21 2005
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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

 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
stuff stand out.
Jun 21 2005
parent reply clayasaurus <clayasaurus gmail.com> writes:
Jarrett Billingsley 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

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
stuff stand out.
I agree.
Jun 21 2005
parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
clayasaurus wrote:

 compile-time stuff stand out.
I agree.
Me too // like some brain-dead AOL-er -- Tomasz Stachowiak /+ a.k.a. h3r3tic +/
Jun 21 2005
parent James Dunne <james.jdunne gmail.com> writes:
In article <d99ilo$gag$1 digitaldaemon.com>, Tom S says...
clayasaurus wrote:

 compile-time stuff stand out.
I agree.
Me too // like some brain-dead AOL-er
You're about as useless as JPEGs to Helen Keller.
-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
Regards, James Dunne
Jun 22 2005
prev sibling next sibling parent Eugene Pelekhay <pelekhay gmail.com> writes:
James McComb wrote:
 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 had similar idea about this. As long as we already have #line Interesting how many positive posts must be in this thread to have this change implemented by Walter?
Jun 22 2005
prev sibling next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Personally, I don't like this.  Specifically because the minute this 
changes, people will start:

   - complaining about #if enforcing scope.  C/C++ didn't require this, 
they'll say.
   - aligning things to the far left like with a preprocessor, which is 
ugily.  I thought that was part of why D had these things in the language.
   - asking for things like #ifdef instead of #version, and no 
parenthesis or curly braces.

Why?  Because you make it look like the preprocessor if you make this 
change.  You also make it such that, in some cases, (where things are 
aligned left already) you cannot use a preprocessor correctly - unless 
you change everything:

#version = test;
#version(test)



Which still leaves:

const int x = 5;
#if (x == 5)  // <-- error, preprocessor doesn't know about x!

Etcetera.  It just separates it from the language, doesn't it?  Even if 
it still is part of the compiler.

-[Unknown]


 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
 
 
 
 
 
 
Jun 22 2005
next sibling parent reply Nod <Nod_member pathlink.com> writes:
In article <d9bstm$2as5$1 digitaldaemon.com>, Unknown W. Brackets says...
Personally, I don't like this.  Specifically because the minute this 
changes, people will start:

   - complaining about #if enforcing scope.  C/C++ didn't require this, 
they'll say.
   - aligning things to the far left like with a preprocessor, which is 
ugily.  I thought that was part of why D had these things in the language.
   - asking for things like #ifdef instead of #version, and no 
parenthesis or curly braces.

Why?  Because you make it look like the preprocessor if you make this 
change.  You also make it such that, in some cases, (where things are 
aligned left already) you cannot use a preprocessor correctly - unless 
you change everything:

#version = test;
#version(test)



Which still leaves:

const int x = 5;
#if (x == 5)  // <-- error, preprocessor doesn't know about x!

Etcetera.  It just separates it from the language, doesn't it?  Even if 
it still is part of the compiler.

-[Unknown]


 <snip>
I am not sure if you were merely making an example of how confusing it would be for C/C++ people or not, but to clarify: As I understand, the proposed change is meant to be purely syntactical, i.e. it doesn't separate anything from the language, it just makes compile-time code more eyecatching. This is prompted by the fact that the status quo is easily confusing when mixing compile-time and run-time code. Also, it de-overloads the static keyword a bit, which is also important. users, but sometimes you have to bite the bullet and just re-learn. What I would consider ideal, would be to have no visible distinction between compile- and run-time code, letting the compiler figure out which expressions are compile-time and not. For one reason or another, Walter chose not to take this route. So for improving what we have, a syntax change would help. Personally, I think available, and for better or for worse, C/C++ people already associates it with compile-time executed stuff. -Nod-
Jun 22 2005
next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Nod" <Nod_member pathlink.com> wrote in message 
news:d9c2po$2igp$1 digitaldaemon.com...
 In article <d9bstm$2as5$1 digitaldaemon.com>, Unknown W. Brackets says...
Personally, I don't like this.  Specifically because the minute this
changes, people will start:

   - complaining about #if enforcing scope.  C/C++ didn't require this,
they'll say.
   - aligning things to the far left like with a preprocessor, which is
ugily.  I thought that was part of why D had these things in the language.
   - asking for things like #ifdef instead of #version, and no
parenthesis or curly braces.

Why?  Because you make it look like the preprocessor if you make this
change.  You also make it such that, in some cases, (where things are
aligned left already) you cannot use a preprocessor correctly - unless
you change everything:

#version = test;
#version(test)



Which still leaves:

const int x = 5;
#if (x == 5)  // <-- error, preprocessor doesn't know about x!

Etcetera.  It just separates it from the language, doesn't it?  Even if
it still is part of the compiler.

-[Unknown]


 <snip>
I am not sure if you were merely making an example of how confusing it would be for C/C++ people or not, but to clarify: As I understand, the proposed change is meant to be purely syntactical, i.e. it doesn't separate anything from the language, it just makes compile-time code more eyecatching. This is prompted by the fact that the status quo is easily confusing when mixing compile-time and run-time code. Also, it de-overloads the static keyword a bit, which is also important. C/C++ users, but sometimes you have to bite the bullet and just re-learn. What I would consider ideal, would be to have no visible distinction between compile- and run-time code, letting the compiler figure out which expressions are compile-time and not. For one reason or another, Walter chose not to take this route. So for improving what we have, a syntax change would help. Personally, I think available, and for better or for worse, C/C++ people already associates it with compile-time executed stuff. -Nod-
120% agree. Andrew.
Jun 22 2005
prev sibling parent reply "Lionello Lunesu" <lio lunesu.removethis.com> writes:
| What I would consider ideal, would be to have no visible distinction 
between
| compile- and run-time code, letting the compiler figure out which 
expressions
| are compile-time and not. For one reason or another, Walter chose not to 
take
| this route.

Indeed! This makes perfect sense. Why do we even need a "static if"? I use 
"if(0)" a lot for skipping pieces of code during debugging, and I'll never 
write "statif if(0)", and shouldn't have to.

If the "is" (or other "operator") used inside the static if() has a 
different meaning because it's inside a static if, then maybe its name 
should be reconsidered instead. Or the "static" moved, ie if(static is....).

L. 
Jun 24 2005
next sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
IMHO, static if is more important not because it can't be determined, 
but because it proves it is determined.

It's just like type safety.  In scripting languages, one might say the 
compiler should be able to determine the type of the variable, for this 
example:

var x = 5;
x += 10;

Obviously it is an int.  Surely, we don't have to *TELL* the compiler 
that.  And, truth to tell, we don't - not in such simple cases.

But, sometimes it's good to be *sure*.  To know that this if is GOING TO 
BE STATIC.  And, if it's not - we'll get an error!  But, what about this:

var x = 5;
x += 10 ~ 1;

Oops.  Maybe in this imaginary (and dumb now) language, ~ might make 10 
and 1 strings, and concatenate them - resulting in 'x+= "101"', which 
would result in "5101".  A typo on our part, but it's why we have 
typesafety, isn't it?

The same goes for static if.  It's type safety, at least imho.

-[Unknown]


 | What I would consider ideal, would be to have no visible distinction 
 between
 | compile- and run-time code, letting the compiler figure out which 
 expressions
 | are compile-time and not. For one reason or another, Walter chose not to 
 take
 | this route.
 
 Indeed! This makes perfect sense. Why do we even need a "static if"? I use 
 "if(0)" a lot for skipping pieces of code during debugging, and I'll never 
 write "statif if(0)", and shouldn't have to.
 
 If the "is" (or other "operator") used inside the static if() has a 
 different meaning because it's inside a static if, then maybe its name 
 should be reconsidered instead. Or the "static" moved, ie if(static is....).
 
 L. 
 
 
Jun 24 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Lionello Lunesu" <lio lunesu.removethis.com> wrote in message
news:d9h6oj$2q2b$1 digitaldaemon.com...
 Indeed! This makes perfect sense. Why do we even need a "static if"? I use
 "if(0)" a lot for skipping pieces of code during debugging, and I'll never
 write "statif if(0)", and shouldn't have to.
That indeed was my original thought with this. Unfortunately, some limitations are: 1) if (0) introduces a new scope, static if(...) does not. Why does this matter? It matters if one wants to conditionally declare a new variable: static if (...) int x; else long x; x = 3; whereas: if (...) int x; else long x; x = 3; // error, x is not defined 2) False static if conditionals don't have to semantically work. For example, it may depend on a conditionally compiled declaration somewhere else: static if (...) int x; int test() { static if (...) return x; else return 0; } 3) Static if's can appear where only declarations are allowed: class Foo { static if (...) int x; } 4) Static if's can declare new type aliases: static if (0 || is(int T)) T x;
Jun 25 2005
parent "Lionello Lunesu" <lio lunesu.removethis.com> writes:
That explains a lot.. Thank you for the reply..

L. 
Jun 27 2005
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Unknown W. Brackets wrote:
 Personally, I don't like this.  Specifically because the minute this 
 changes, people will start:
 
   - complaining about #if enforcing scope.  C/C++ didn't require this, 
 they'll say.
   - aligning things to the far left like with a preprocessor, which is 
 ugily.  I thought that was part of why D had these things in the language.
   - asking for things like #ifdef instead of #version, and no 
 parenthesis or curly braces.
 
 Why?  Because you make it look like the preprocessor if you make this 
 change.
<snip top of upside-down reply> Taken the words out of my mouth there. Making it look as though D has a preprocessor'll go against what we're trying to throw at D programmers. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Jun 29 2005
prev sibling next sibling parent reply Matthias Becker <Matthias_member pathlink.com> writes:
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?
I like it. But what about e.g. templates? Some people use them as compiletime-functions so should it be #template and #mixin, ...?
Jun 23 2005
parent "Lionello Lunesu" <lio lunesu.removethis.com> writes:
| I like it.
|
| But what about e.g. templates? Some people use them as 
compiletime-functions so
| should it be #template and #mixin, ...?
|
|

Good point!

I think I'd be statisfied with staticif and staticassert, staticis; maybe 
with an underscore.

L. 
Jun 23 2005
prev sibling next sibling parent reply pragma <pragma_member pathlink.com> writes:
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 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 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
Jun 23 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 23 Jun 2005 18:29:56 +0000 (UTC), pragma 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 symbol.
being used. I think that point is simply that the current syntax increases the illegibility of D code and that an alternative would make reading and writing code more efficient. The main problems are that using multi-word tokens is confusing and that the compile-time nature of some aspects of the language is not obvious from a casual reading.
 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.  
That is to be highly commended. However, is there any reason while we cannot make it even easier for people to adopt D?
 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.
Exactly! And thus multi-word tokens are excess baggage. The lack of visual distinction between compile-time tokens and run-time tokens also increases the number of mental rules one has to carry around.
 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

That is also a reasonable suggestion. I don't think that the people something be done to help us read code more easily.
 Also, a good syntax highlighter can easily fix the recognition issues between
 which *epoch a statment evaluates/runs under.
It would have to be a good one to highlight "static if" and "if" correctly in context.
 
 (*) 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>
"Init Time"? Isn't this still work done by the compiler in order to generate the intended object code?
 Other epochs that D leaves out are the preprocessor, and runtime
code-generation
 which are supported in other langauges.
Agreed. If they aren't in D then we don't have to worry about those.
 (I think '#line' is being handled by D's lexer, which technically makes it a
 preprocessor token. I could be wrong about this.)
Simple rule: If it is only used to generate output during compilation/linking then it is a compile-time token otherwise it is a run-time token. -- Derek Parnell Melbourne, Australia 24/06/2005 7:34:56 AM
Jun 23 2005
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
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.
Jun 23 2005
parent reply Derek Parnell <derek psych.ward> writes:
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". -- Derek Parnell Melbourne, Australia 24/06/2005 8:08:18 AM
Jun 23 2005
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 24 Jun 2005 08:10:30 +1000, Derek Parnell <derek psych.ward> 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".
What order have you defined them in? perhaps re-ordering will help it. It seems it's not using any read-ahead, i.e. it sees "static" doesn't check if it's followed by an "if" colors static, then reads "if", colors that, etc. Regan
Jun 23 2005
prev sibling parent Derek Parnell <derek psych.ward> writes:
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
Jun 23 2005
prev sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:

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 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 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
Jun 23 2005
next sibling parent "Walter" <newshound digitalmars.com> writes:
"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.
Jun 23 2005
prev sibling parent pragma <pragma_member pathlink.com> writes:
In article <opssujo0zy23k2f5 nrage.netwin.co.nz>, Regan Heath says...

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.
I think Derek cleaned this up neatly for both of us: things are either run-time or compile-time. My use of "init time" was merely to draw distinction to the fact that 'static this' is technically a part of the runtime (code), but has a special place during the bootstrap of a program; hence that particular use of static has a special meaning. - EricAnderton at yahoo
Jun 24 2005
prev sibling next sibling parent reply Dawid =?ISO-8859-2?Q?Ci=EA=BFarkiewicz?= <arael fov.pl> writes:
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 There are things more important than "look" but if this change would be because of cosmetic reasons than I would be voiting 'no'. -- Dawid Ciężarkiewicz | arael
Jun 23 2005
parent Derek Parnell <derek psych.ward> writes:
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
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
Jun 23 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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.
Jun 23 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
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
Jun 23 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"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.
Jun 24 2005
parent reply Derek Parnell <derek psych.ward> writes:
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
Jun 24 2005
parent "Walter" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:199skhy1f5i6n$.tcqfukcs4a0a.dlg 40tude.net...
 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 add to that that 'static if' is not that bad.
 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.
I know. One can still use boldface, fonts, etc., even with b/w hardcopy. But I also suggest that one can use whitespace formatting and layout to emphasize or de-emphasize various aspects of the source code.
Jun 24 2005
prev sibling parent reply James McComb <ned jamesmccomb.id.au> writes:
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 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.)
Jun 24 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"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


 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?
Jun 24 2005
next sibling parent Dave <Dave_member pathlink.com> writes:
In article <d9gde9$1lls$1 digitaldaemon.com>, Walter says...
"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


 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?
editor. D changed that - Notepad works just fine for D. That's one of the things that makes D so comfortable.. IMHO, something along the lines of the idea above would be a worthy goal if it can be as quickly and simply implemented as the length symbol. It just makes for easier to read code IMO, because it is easier to distinguish than 'static' in plain old black and white. - Dave
Jun 24 2005
prev sibling parent reply "Lionello Lunesu" <lio lunesu.removethis.com> writes:
| Is static if that bad? Wouldn't using a syntax highlighting editor be a
| better solution?

I have yet to encounter a IDE that can highlight "static if" differently 
from <static> <space> <if>.

Granted, I don't use many different IDEs, so there probably is one out there 
that can do it.

But what about the "else" appearing after the "static if { ...}"?  Must be 
some fancy highlighter to know it should be coloured 'statically'.. I guess 
this means that if "static" is changed into some prefix, it should also be 
applied to "else":

$version(x) {...} $else { ...}
#version(x) {...} #else { ...}

Or whatever. I truly hope we don't get another "what symbol is better" 
discussion. : S

L. 
Jun 24 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 24 Jun 2005 17:48:38 +0300, Lionello Lunesu  
<lio lunesu.removethis.com> wrote:
 | Is static if that bad? Wouldn't using a syntax highlighting editor be a
 | better solution?

 I have yet to encounter a IDE that can highlight "static if" differently
 from <static> <space> <if>.

 Granted, I don't use many different IDEs, so there probably is one out  
 there that can do it.
Derek found one: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/25749
 But what about the "else" appearing after the "static if { ...}"?  Must  
 be some fancy highlighter to know it should be coloured 'statically'..
That's a good point.
 I guess
 this means that if "static" is changed into some prefix, it should also  
 be applied to "else":

 $version(x) {...} $else { ...}
 #version(x) {...} #else { ...}

 Or whatever. I truly hope we don't get another "what symbol is better"
 discussion. : S
Those are never productive. Regan
Jun 26 2005