Smooth transition to D2 for Tango users?

[Bruce Adams]

On Sat, 20 Sep 2008 15:18:38 +0100, Jason House  
<jason.james.house at gmail.com> wrote:

> <posted & mailed>
>
> Bruce Adams wrote:
>
>> On Wed, 17 Sep 2008 18:31:02 +0400, Jason House
>> <jason.james.house at gmail.com> wrote:
>>
>> > I'd like to see a smooth transition for Tango, not just the users! I
>> > made several posts on the topic. The latest was titled "forward
>> > compatibility" -- Making the D1 compiler tolerant of code that looks
>> > like D2, but not adding new functionality...
>>
>> The thing is what you are asking for is a major change to the D1.0 spec.
>> D1.0 is frozen. Bug fixes (to the spec) are permitted but major  
>> additions
>> are not.
>
> That means almost nothing to me.  Is the spec on how users should write
> their D1 code or a spec on how compiler writers should handle D1 code?   
> If
> it's the former, my suggestion poses no problems because old D1 code will
> still compile and execute the exact same way it always did.  If it's the
> latter, I don't see much of a problem since all alternative D1 compilers
> base their execution on dmd's front end source code.
>
Maybe I've misunderstood but what I thought was being asked for was for  
the D1.0
language to be changed to accept D2.0 syntax and ignore it at some point  
within blocks
marked as D1.0 versions.
This would mean that for a D1.0 compiler vendor to comply with the  
standard the
D1.0 compiler would have to extended to parse D2.0.
A bit like asking a C compiler to ignore C++ class definitions.
Having D2.0 compilers accept D1.0 syntax in D1.0 version sections makes  
more sense.

Now I think I understand what people are saying. You want different  
version sections
to not report errors for versions of the language they do not support.
By default the compiler parses code in all version sections.
One purpose of the version statement is so that you can always tell your  
code is syntactically
correct for all versions.
Another possible solution is to add an option to the compiler that  
modifies this behaviour so
the compiler doesn't bother parsing the other version block. This defeats  
the purpose above.
Still I think it is probably the correct thing to do (by default) for D1  
compilers to accept
D2 code and for D2 compilers to accept D3 code.
For a D2 compiler it would be down to the vendor as to whether to have a  
D1.0 parser builtin
as well and switch modes within version blocks or simply ignore them. But  
there is going to be
significant code bloat in having a compiler support every variant of the  
language so at some
point your going to have to say ignore code in other version blocks.
The parser needs a way of identifying the end of the version block without  
doing too much
analysis on the code inbetween which is a bit gnarly.

>
>> Moreoever this addition does not add any functionality. So while
>> it
>> may seem like a sensible thing to do from a pragmatic programmer's point
>> of view
>>  from a language design point of view its very silly indeed.
>
> You're absolutely right that it depends on the point of view.  While I  
> may
> like the pragmatic programmer's point of view, I'm motivated by the  
> library
> maintainer's point of view and the library users' point of view.
>
> Users would want freedom to choose their D version and the libraries that
> they use.  The more incompatibilities that exist, the more it splits  
> apart
> the D community.  Such splits leave a sour taste for current users and  
> for
> prospective users of D.  Users will also want to read through library  
> code
> from time to time, and the last thing they want to see is code that's
> littered with preprocessor directives.
>
> Library maintainers are left with the task of maintaining code.  They  
> need
> to have code with little or no duplication.  Library maintainers are also
> users, and I bet that they were attracted to D by its elegance and
> simplicity.
>
A separate pre-processing step actually helps this. Users can look at the
source code in the version of the language they are using.
Library developers have the choice of using version statements or some kind
of annotation whichever they find cleaner.
There is overhead and complexity which may not be justified but if you want
flexibility sometimes you have to pay for it.
>
>
>> You need to find a difficult way to tackle the problem.
>
> One time difficulty or increased difficulty for all library writers and
> users?  Either way, a solution needs to be found that the community at
> large supports.
>
I think I meant different not difficult. The tricky unconscious at work  
there :)
>
>
>> * strip const's and invariants from the source in appropriate contexts
>
> I've suggested this before too :)
>
I thought someone had. I only piped up because I sick of seeing it  
discussed
without being resolved :).
>
>
>> * use source code annotations specific to your Doneificator program
>
> You mean add an unofficial D preprocessor?  IMHO, if there's a need for
> this, it should be part of the D specification.
>
I agree that's a bad idea. If you want to do something that your tool  
doesn't
support and your tool vendor doesn't look likely to implement then your  
options are
limited.
Source code transformation isn't inherantly evil though. You just need a  
very good
reason to justify the expense of doing it.

>
>
>> Have a configure script which checks which versions of the compiler you
>> have available.
>
> ick.  I can guarantee there are many here who have explicitly tried to  
> avoid
> that kind of thing when coming to D.

Regardless of how you handle multiple language versions in the source code  
you need some way
to set the flags that say what you are going to build and how you are  
going to build it.
You can only avoid having something doing the job of a configure script if  
you only plan on
having a single configuration. If you know you will have a D2.0 compiler  
you shouldn't need
to worry.