Jason House Wrote:

> Jarrett Billingsley Wrote:
> 
> > "Jason House" <jason.james.house@gmail.com> wrote in message news:g5nhb4$r9d$1@digitalmars.com...
> > > Jarrett Billingsley Wrote:
> > >
> > >> "Jason House" <jason.james.house@gmail.com> wrote in message news:g5lib0$23ju$1@digitalmars.com...
> > >>
> > >> > I can't imagine any library maintainer being willing to do that just
> > >> > for
> > >> > portability between D versions.  It'd be nice if D2 code could have
> > >> > something like version(d1){} and version(d2){} for this purpose.
> > >> > That'd
> > >> > then allow the d2 compiler to ignore version(d1){} and allow the
> > >> > converter
> > >> > to strip out version(d2){}
> > >>
> > >> I've always been dubious about using the version construct for various
> > >> language versions.  It's great for program options, but since the stuff
> > >> in
> > >> the version block has to be syntactically legal, it makes it worthless
> > >> for
> > >> supporting multiple versions of D.
> > >
> > >
> > > Who says what's in version(d1) has to be legal D1 code? ;)  I'd vote that the code would still look like D2 code and would be converted in the same way as all other code.
> > 
> > Oh, oh, I see what you're saying now.  Those version blocks would just be dealt with by the converter, not the compiler.
> > 
> > 
> 
> Done right, the code could compile as D2 code out of the box.  Using my ad hoc example, that'd require version=d2 to be included in the source.  The version(d1) would silently (and correctly) be ignored.  I don't know if this is best, but it certainly seems simple enough to do
> 

Could a language construct be created in D1 and D2 to allow for a "lazy" version? As Far as I understand, the compiler would have to lexically analyze the code after the version is evaluated, but string mixins already have to be lexed after evaluation.  I imagine the "{" and "}" operators would be ambiguous, so a new operators would have to be created to signify lazy syntax.   "{{" and "}}", just for example:

version(d1)
{{
      ...
}}
version(d2)
{{
      ...
}}

The code within the blocks would be treated something like string literals at the lexical stage, and kept as static data until the version statement is evaluated, then code would be inserted much like string mixins already do, but without the need to stringify the code.

"Ryan Bloomfield" <_sir_maniacREMOVE_ME@yahoo.com> wrote in message news:g5oct3$2vpl$1@digitalmars.com...

> Could a language construct be created in D1 and D2 to allow for a "lazy" version? As Far as I understand, the compiler would have to lexically analyze the code after the version is evaluated, but string mixins already have to be lexed after evaluation.  I imagine the "{" and "}" operators would be ambiguous, so a new operators would have to be created to signify lazy syntax.   "{{" and "}}", just for example:
>
> version(d1)
> {{
>      ...
> }}
> version(d2)
> {{
>      ...
> }}
>
> The code within the blocks would be treated something like string literals at the lexical stage, and kept as static data until the version statement is evaluated, then code would be inserted much like string mixins already do, but without the need to stringify the code.

To be honest, I kind of wish this were the case with version statements all the time.

Jarrett Billingsley Wrote:

> "Ryan Bloomfield" <_sir_maniacREMOVE_ME@yahoo.com> wrote in message news:g5oct3$2vpl$1@digitalmars.com...
> 
> > Could a language construct be created in D1 and D2 to allow for a "lazy" version?
> 
> To be honest, I kind of wish this were the case with version statements all the time.
> 
> 

    I disagree. I think it's good for all version blocks to compile under normal circumstances.  If it didn't do that, uncompilable code could creep in.   It would be especially bad if it involves machine-specific code.  Coding between different versions of D is clearly going to be used less then the other intended uses of 'version'.

   Nevertheless,  in my humble opinion, I do think the ability to ignore, or relax syntax rules needs to happen.  Without it, any compiler or version specific feature could never be included in portable code.  And compiler specific features seem to be the norm for C and C++ compilers.

Ryan Bloomfield wrote:
> Jarrett Billingsley Wrote:
> 
>> "Ryan Bloomfield" <_sir_maniacREMOVE_ME@yahoo.com> wrote in message news:g5oct3$2vpl$1@digitalmars.com...
>>
>>> Could a language construct be created in D1 and D2 to allow for a "lazy" version? 
>> To be honest, I kind of wish this were the case with version statements all the time. 
>>
>>
> 
>     I disagree. I think it's good for all version blocks to compile under normal circumstances.  If it didn't do that, uncompilable code could creep in.   It would be especially bad if it involves machine-specific code.  Coding between different versions of D is clearly going to be used less then the other intended uses of 'version'.  

But it doesn't really solve the problem.  So you have syntactically correct code.  Yippee.  You still can't say whether it's semantically valid until you actually compile it.  So it provides protection from code rot some of the time.  But if you're worried about code rot, syntactic validity is not enough.  There's no substitute for actually compiling and testing the code you want to have work.

If you're not worried about code rot then it's just a nuisance that gets in the way of legitimate goals like making code portable between major versions of D.

>    Nevertheless,  in my humble opinion, I do think the ability to ignore, or relax syntax rules needs to happen.  Without it, any compiler or version specific feature could never be included in portable code.  And compiler specific features seem to be the norm for C and C++ compilers.

In light of what I said above, I don't really see any point in forcing versioned-out code to be syntactically valid like D does.  It doesn't protect you from what is probably the biggest classes of code rot issues, which are things like variables getting renamed or functions changing their number of parameters, etc.

--bb

Bill Baxter Wrote:

> Ryan Bloomfield wrote:
> > Jarrett Billingsley Wrote:
> >> To be honest, I kind of wish this were the case with version statements all the time.
> >>
> >>
> > 
> >     I disagree. I think it's good for all version blocks to compile under normal circumstances.  If it didn't do that, uncompilable code could creep in.   It would be especially bad if it involves machine-specific code.  Coding between different versions of D is clearly going to be used less then the other intended uses of 'version'.
> 
> But it doesn't really solve the problem.  So you have syntactically correct code.  Yippee.  You still can't say whether it's semantically valid until you actually compile it.  So it provides protection from code rot some of the time.  But if you're worried about code rot, syntactic validity is not enough.  There's no substitute for actually compiling and testing the code you want to have work.

I thought about the limitations of syntactic validity when I was writing it.   I suppose I should have included that thought.  I think the following is still an issue:

Nothing within version blocks can be guaranteed to be syntactically correct for any form of syntax analysis, without semantically determining the actual values set with 'version=...'.

This also appears breaks the rule: "a source file can be syntactically analyzed without needing any semantic information"  from the following interview:

http://www.bitwisemag.com/copy/programming/d/interview/d_programming_language.html

I may just be rambling on here, does this make sense?

Ryan Bloomfield wrote:
> Bill Baxter Wrote:
> 
>> Ryan Bloomfield wrote:
>>> Jarrett Billingsley Wrote:
>>>> To be honest, I kind of wish this were the case with version statements all the time. 
>>>>
>>>>
>>>     I disagree. I think it's good for all version blocks to compile under normal circumstances.  If it didn't do that, uncompilable code could creep in.   It would be especially bad if it involves machine-specific code.  Coding between different versions of D is clearly going to be used less then the other intended uses of 'version'.  
>> But it doesn't really solve the problem.  So you have syntactically correct code.  Yippee.  You still can't say whether it's semantically valid until you actually compile it.  So it provides protection from code rot some of the time.  But if you're worried about code rot, syntactic validity is not enough.  There's no substitute for actually compiling and testing the code you want to have work.
> 
> I thought about the limitations of syntactic validity when I was writing it.   I suppose I should have included that thought.  I think the following is still an issue:
> 
> Nothing within version blocks can be guaranteed to be syntactically correct for any form of syntax analysis, without semantically determining the actual values set with 'version=...'. 
> 
> This also appears breaks the rule: "a source file can be syntactically analyzed without needing any semantic information"  from the following interview:
> 
> http://www.bitwisemag.com/copy/programming/d/interview/d_programming_language.html
> 
> I may just be rambling on here, does this make sense?

I think I get your gist.  The syntactic validity requirement is not so much for catching programming errors as it is for keeping parsing simple for tools.  That makes sense, and I think I've actually heard that argument before but just forgot about it.

I don't like special cases in general, but maybe an exception can be made here.  Version blocks that specify a version of the D language would be treated specially.  That is, the D 1 and 2 specs could be amended to say that any version matching the pattern "D_Version[0-9]+" is special, and the contents of the following block should be ignored by a compiler or tool that does not support that version of the language.

--bb

Bill Baxter Wrote:
> I think I get your gist.  The syntactic validity requirement is not so much for catching programming errors as it is for keeping parsing simple for tools.  That makes sense, and I think I've actually heard that argument before but just forgot about it.
> 
> I don't like special cases in general, but maybe an exception can be made here.  Version blocks that specify a version of the D language would be treated specially.  That is, the D 1 and 2 specs could be amended to say that any version matching the pattern "D_Version[0-9]+" is special, and the contents of the following block should be ignored by a compiler or tool that does not support that version of the language.
> 
> --bb

That would solve the portability issue with D version standards.  What if a standards compliant compiler adds an additional feature that is syntactically incompatible?  Would a special type of version statement be more useful?  As an example 'dversion(__GNUD__) { ... }', or maybe 'version(D_VERSION,__GNUD__){ ... }'.

This could even be used to conditionally compile specifically by feature:

version(D_VERSION,__forany__)
{
    forany(...)
        ...
}
else
{
    foreach(...)
        ...
}

just my 2 cents

Ryan Bloomfield wrote:
> Bill Baxter Wrote:
>> I think I get your gist.  The syntactic validity requirement is not so much for catching programming errors as it is for keeping parsing simple for tools.  That makes sense, and I think I've actually heard that argument before but just forgot about it.
>>
>> I don't like special cases in general, but maybe an exception can be made here.  Version blocks that specify a version of the D language would be treated specially.  That is, the D 1 and 2 specs could be amended to say that any version matching the pattern "D_Version[0-9]+" is special, and the contents of the following block should be ignored by a compiler or tool that does not support that version of the language.
>>
>> --bb
> 
> That would solve the portability issue with D version standards.  What if a standards compliant compiler adds an additional feature that is syntactically incompatible?  Would a special type of version statement be more useful?  As an example 'dversion(__GNUD__) { ... }', or maybe 'version(D_VERSION,__GNUD__){ ... }'.  
> 
> This could even be used to conditionally compile specifically by feature:
> 
> version(D_VERSION,__forany__)
> {
>     forany(...)
>         ...
> }
> else
> {
>     foreach(...)
>         ...
> }
> 
> just my 2 cents


I think preventing the proliferation of vendor-specific language extensions is considered a feature of the current system.  There is always "pragma" for non-language extensions.

--bb

Bill Baxter, el 18 de julio a las 17:50 me escribiste:
> >That would solve the portability issue with D version standards.  What if a
> >standards compliant compiler adds an additional feature that is syntactically
> >incompatible?  Would a special type of version statement be more useful?  As an
> >example 'dversion(__GNUD__) { ... }', or maybe 'version(D_VERSION,__GNUD__){ ...
> >}'.  This could even be used to conditionally compile specifically by feature:
> >version(D_VERSION,__forany__)
> >{
> >    forany(...)
> >        ...
> >}
> >else
> >{
> >    foreach(...)
> >        ...
> >}
> >just my 2 cents
> 
> 
> I think preventing the proliferation of vendor-specific language extensions is considered a feature of the current system.  There is always "pragma" for non-language extensions.

That's true, but I think this opens a new posibility to D to introduce new small backward incompatible features in a stable version giving the user some time to update (or keep the old behavior), like Python's __future__ module[1].

That would make D evolving much easier...

[1] http://www.python.org/dev/peps/pep-0236/

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
SATANAS EN COMISARIA
	-- Crónica TV