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.

Perhaps you are right that the # symbol is poised to create confusion for 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 the # symbol is as good as any for this purpose. It's readable, writeable, available, and for better or for worse, C/C++ people already associates it with compile-time executed stuff.

-Nod-

"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.
>
> Perhaps you are right that the # symbol is poised to create confusion for
> 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
> the # symbol is as good as any for this purpose. It's readable, writeable,
> available, and for better or for worse, C/C++ people already associates it
> with
> compile-time executed stuff.
>
> -Nod-
>

120% agree.

Andrew.

>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, ...?

| 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.

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 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 than C's, and would certainly be harder to read with this use of the '#' symbol.

I think you might have missed the point. It is not about the '#' character 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 '#' everywhere else to match, which would only make implementation easier.

That is also a reasonable suggestion. I don't think that the people agreeing are adamant that the '#' character be used, but just that 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

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.

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

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.

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

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