Porting D2 code to D1

[Ryan Bloomfield]

Jason House Wrote:

> Jarrett Billingsley Wrote:
> 
> > "Jason House" <jason.james.house at gmail.com> wrote in message 
> > news:g5nhb4$r9d$1 at digitalmars.com...
> > > Jarrett Billingsley Wrote:
> > >
> > >> "Jason House" <jason.james.house at gmail.com> wrote in message
> > >> news:g5lib0$23ju$1 at 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.