View mode: basic / threaded / horizontal-split · Log in · Help
July 17, 2008
Re: Porting D2 code to D1
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.
July 18, 2008
Re: Porting D2 code to D1
"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.
July 18, 2008
Re: Porting D2 code to D1
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.
July 18, 2008
Re: Porting D2 code to D1
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
July 18, 2008
Re: Porting D2 code to D1
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?
July 18, 2008
Re: Porting D2 code to D1
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
July 18, 2008
Re: Porting D2 code to D1
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
July 18, 2008
Re: Porting D2 code to D1
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
July 18, 2008
Re: Porting D2 code to D1
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
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home