Jeroen van Bemmel wrote:
> My thought was that the D compiler could do the same for version sections,
> unless Walter had other reasons to do parsing of the sections (see his
> posting)

For a recursive descent, hand-written parser there is no problem. But for other compilers, which may be based off a perser generator (such as Bison used by Gnu) this would be a problem.

The difference, preprocessor does not do complete parsing. It only does lexing. And the logic to reject tokens is handwritten, bolted on top of the lexer. But since we don't want to have a preprocessor, but instead to parse the source directly...

-eye

> > PS - Sorry if I'm stating the obvious.
>
> Stating the obvious is always a good idea, because often one misses the obvious.

Wow, this is a nice one, straight
from the Book of Ethernal Wisdom! ;)

Cheers,
Sz.

> For a recursive descent, hand-written parser there is no problem. But for other compilers, which may be based off a perser generator (such as Bison used by Gnu) this would be a problem.
>
> The difference, preprocessor does not do complete parsing. It only does lexing. And the logic to reject tokens is handwritten, bolted on top of the lexer. But since we don't want to have a preprocessor, but instead to parse the source directly...
>

Yes, this all makes sense. I just wanted to understand the reasoning behind
some of these design choices, and I think it is important to document them
explicitly
(although D documentation is in pretty good shape already)

It follows then that the design lets potential other compiler versions
extend the language semantically (by adding pragma identifiers), but not
syntactically (by adding keywords) ?

Jeroen van Bemmel wrote:
> It follows then that the design lets potential other compiler versions
> extend the language semantically (by adding pragma identifiers), but not
> syntactically (by adding keywords) ?

Wrong. You cannot prohobit anyone to make syntactic additions or add new  keywords. It's just that the users would need to think twice before they use such extentions, because they would radically disallow the source to be compiled by other compilers.

It would thus make sense for a compiler vendor, to provide extensions (possibly additionally) in the form of pragmas, so that the source can be reused for multiple different compilers. This particularly makes sense when writing code, which would be targeted at different machines with different compilers, but would only need the extensions within one of the targets.

Besides, if anyone makes a syntactic addition, it may break someone's code - so there should be a possibility to turn all such extensions off. Adding a pragme doesn't break any existing code, and need not be turned off for any reason.

-eye

"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:bta7m8$2np9$1@digitaldaemon.com...
> Jeroen van Bemmel wrote:
> > It follows then that the design lets potential other compiler versions
> > extend the language semantically (by adding pragma identifiers), but not
> > syntactically (by adding keywords) ?

Yes.

> Wrong. You cannot prohobit anyone to make syntactic additions or add new
>   keywords.

While you are technically correct, the idea is to provide vendors a sensible way to add extensions that is endorsed by the D community and would be backward compatible with D tools. Market pressure would presumably be the enforcement tool, as it is with C/C++ standards compliance.

> It's just that the users would need to think twice before
> they use such extentions, because they would radically disallow the
> source to be compiled by other compilers.
> It would thus make sense for a compiler vendor, to provide extensions
> (possibly additionally) in the form of pragmas, so that the source can
> be reused for multiple different compilers. This particularly makes
> sense when writing code, which would be targeted at different machines
> with different compilers, but would only need the extensions within one
> of the targets.

Yes.

> Besides, if anyone makes a syntactic addition, it may break someone's code - so there should be a possibility to turn all such extensions off. Adding a pragme doesn't break any existing code, and need not be turned off for any reason.

Yes. Vendors need to be able to add extensions for special purposes for their customers. Pragmas give them a way to do it that doesn't break other D tools.

That seems as if it would conflict with ?: operator.

But you guys are on the right track, IMHO.

Sean

"Robert" <no@spam.ne.jp> wrote in message news:bt9u5g$29tj$1@digitaldaemon.com...
> I've thought the similar idea.
> I think following syntax:
>
> int x = max?(a, b);
>
> ! denotes explicit and ? denotes implicit.
>
>
> "davepermen" <davepermen_member@pathlink.com> wrote in message news:bt992p$1b32$1@digitaldaemon.com...
> > the current "implicit" way is to specify the type based on some
> parameter..
> > thanks to typeof, that works
> >
> > int x = max!(typeof(a))(a,b);
> >
> > not _that_ implicit, but at least, you don't have to know the type..
> > ...
> > int x = max!!(a,b);
> >
> > just do the typeof(a) yourself..
> >
> > so if you call a templated method with two !!, and no () in between, it
> just
> > takes the argumentlist (in this case, a,b) and takes typeof till all
> template
> > parameters are filled
> >
> >
> > would be implicit enough for me, i guess

I don't like this !!, !()!, ... stuff. Eigther leav it as it is or use the ?
addition.

> > Jeroen van Bemmel wrote:
> > > It follows then that the design lets potential other compiler versions extend the language semantically (by adding pragma identifiers), but
not
> > > syntactically (by adding keywords) ?
>
> Yes.
>
> > Wrong. You cannot prohobit anyone to make syntactic additions or add new
> >   keywords.
>
> While you are technically correct, the idea is to provide vendors a
sensible
> way to add extensions that is endorsed by the D community and would be backward compatible with D tools. Market pressure would presumably be the enforcement tool, as it is with C/C++ standards compliance.

Of course anybody can write any parser they would like, I was referring to the design intention of the 'pragma' feature.

This calls for a "100% pure D" certification program, with a syntax-only checker that can approve compliant source files (i.e. without added keywords) ;)

> This calls for a "100% pure D" certification program, with a syntax-only checker that can approve compliant source files (i.e. without added keywords) ;)

Whoops, misspelt it. That should be "100% pureD"

Walter wrote:
> Lots of new additions. Didn't get to most of the bug reports; I wanted to
> get D to be 'feature complete' first, the next version will be bug
> polishing. I'm setting sights on releasing D 1.0 by March.

If I were you, I'd wait until 4/4/04 - a unique date.  Also, Mars is the fourth planet...  too much coffee today.