Walter wrote:

> "Sigbjørn Lund Olsen" <sigbjorn@lundolsen.net> wrote in message
> news:cbenfm$18kv$1@digitaldaemon.com...
> 
>>I, for one, am willing to accept that I may have to go
>>over my D spec 1.0 code when a D 2.0 spec is finished.
> 
> 
> I've been thinking about this problem. I think the best way will be to
> create a 1.0 compiler, and fork it. The 1.0 compiler will continue to be
> supported and get bug fixes/improvements, but the focus for 1.0 will be
> stability and reliability. The 2.0 compiler will get new features. We'll
> really try not to break compatibility with 1.0, much in the same manner as
> C++ tries to add new features without breaking things.

Something that might be handy is to establish a standard pragma that describes the spec for which the code was written.  Compilers could use such a pragma to 'switch gears' and compile an older version of the language, or merely to issue a warning/error if that version is not supported.

pragma(Dversion, 1);      // 1.x only
pragma(Dversion, 1, 2);   // 1.x through 2.x
pragma(Dversion, 1, ...); // anything post 1.0
pragma(Dversion, ..., 2); // anything up until 2.x

 -- andy

"Sigbjørn Lund Olsen" <sigbjorn@lundolsen.net> wrote in message news:cbf8ga$21t3$1@digitaldaemon.com...
> Yet still instead of choosing the path of least resistance (modifying a language, breaking only what is needed, but not refraining from breaking everything that needs to be broken) then we choose a stance where 5-15 years from now we'll be porting everything into a new language that is more convenient and expressive than D.

That will happen anyway.

You cannot build a large user base for D if the language keeps breaking existing code. Although to us it is simple to upgrade the source, it is impractical for J. Random User to download some D project off the internet and then go tweaking the source - he needs it to compile cleanly and run. If it doesn't, he won't fix it, he'll just trash it.

(One reason Microsoft achieved such success with their operating systems is they went to enormous lengths to support existing code - DOS 1.0 apps will still run just fine on Windows XP.)

Walter wrote:

> (One reason Microsoft achieved such success with their operating systems is they went to enormous lengths to support existing code - DOS 1.0 apps will still run just fine on Windows XP.)

You mean "legal" DOS 1.0 apps? ;-)

"Andy Friesen" <andy@ikagames.com> wrote in message news:cbf9s2$23vb$1@digitaldaemon.com...
> Something that might be handy is to establish a standard pragma that describes the spec for which the code was written.  Compilers could use such a pragma to 'switch gears' and compile an older version of the language, or merely to issue a warning/error if that version is not supported.
>
> pragma(Dversion, 1);      // 1.x only
> pragma(Dversion, 1, 2);   // 1.x through 2.x
> pragma(Dversion, 1, ...); // anything post 1.0
> pragma(Dversion, ..., 2); // anything up until 2.x

That might work.

"Alex Besogonov" <Alex_member@pathlink.com> wrote in message news:cbdu03$2ef$1@digitaldaemon.com...
> We're going to create yet another D compiler, but now with precise GC
support,

What I really want to see, is a D compiler written in D. The language is clearly targeted purposes like that (among others). Yet, it has not proven itself. Now, when the feature set is fixed, it might be the time to try this out. I for one would like to have it implemented in D with focus on portability and compiliance. I suggest using a C compiler as backend, so there would be very little platform specific code. Perhaps, it could support precise GC too.

What does people think about a combined effort in this direction?

Regards,
Martin

"Sigbjørn Lund Olsen" <sigbjorn@lundolsen.net> wrote in message news:cbenfm$18kv$1@digitaldaemon.com...
> Matthew wrote:
>
> >>In article <cbe0sg$7q0$1@digitaldaemon.com>, Matthew says...
>
> >>History will give us the bool one day. All we have to do is wait.
> >
> >
> > Actually, sadly, I don't think we'll ever get a strongly typed boolean type
in D,
> > ....
>
> Only if we refuse at a later date to go back and fix flaws in the language based on 'so much source has already been written'. It's a resounding argument against change, true, and should be weighted heavily. But lets not forget that D exists much due to a willingness to let backwards compatability go in return for other, more significant improvements. I, for one, am willing to accept that I may have to go over my D spec 1.0 code when a D 2.0 spec is finished.

Sure. I want it. I just don't think it'll happen

"Andy Friesen" <andy@ikagames.com> wrote in message news:cbf9s2$23vb$1@digitaldaemon.com...
> Walter wrote:
>
> > "Sigbjørn Lund Olsen" <sigbjorn@lundolsen.net> wrote in message news:cbenfm$18kv$1@digitaldaemon.com...
> >
> >>I, for one, am willing to accept that I may have to go
> >>over my D spec 1.0 code when a D 2.0 spec is finished.
> >
> >
> > I've been thinking about this problem. I think the best way will be to create a 1.0 compiler, and fork it. The 1.0 compiler will continue to be supported and get bug fixes/improvements, but the focus for 1.0 will be stability and reliability. The 2.0 compiler will get new features. We'll really try not to break compatibility with 1.0, much in the same manner as C++ tries to add new features without breaking things.
>
> Something that might be handy is to establish a standard pragma that describes the spec for which the code was written.  Compilers could use such a pragma to 'switch gears' and compile an older version of the language, or merely to issue a warning/error if that version is not supported.
>
> pragma(Dversion, 1);      // 1.x only
> pragma(Dversion, 1, 2);   // 1.x through 2.x
> pragma(Dversion, 1, ...); // anything post 1.0
> pragma(Dversion, ..., 2); // anything up until 2.x

At first blush, that seems a fine idea.

Arguments please ...

"Martin M. Pedersen" <martin@moeller-pedersen.dk> wrote in message news:cbfbu9$27lp$1@digitaldaemon.com...
> "Alex Besogonov" <Alex_member@pathlink.com> wrote in message news:cbdu03$2ef$1@digitaldaemon.com...
> > We're going to create yet another D compiler, but now with precise GC
> support,
>
> What I really want to see, is a D compiler written in D. The language is clearly targeted purposes like that (among others). Yet, it has not proven itself. Now, when the feature set is fixed, it might be the time to try
this
> out. I for one would like to have it implemented in D with focus on portability and compiliance. I suggest using a C compiler as backend, so there would be very little platform specific code. Perhaps, it could
support
> precise GC too.

One problem with doing the front end in D is the Digital Mars back end is written in C++. Hence there's a bit of a compatibility problem. Not insurmountable, just more work.

"John Reimer" <jjreimer@telus.net> wrote in message news:cbfbmh$250l$1@digitaldaemon.com...
> Walter wrote:
>
> > (One reason Microsoft achieved such success with their operating systems is they went to enormous lengths to support existing code - DOS 1.0 apps will still run just fine on Windows XP.)
>
> You mean "legal" DOS 1.0 apps? ;-)

I finally acquired an original DOS 1.0 distribution disk. Amazingly, it could still be read.

Walter wrote:

> 
> "John Reimer" <jjreimer@telus.net> wrote in message news:cbfbmh$250l$1@digitaldaemon.com...
>> Walter wrote:
>>
>> > (One reason Microsoft achieved such success with their operating systems is they went to enormous lengths to support existing code - DOS 1.0 apps will still run just fine on Windows XP.)
>>
>> You mean "legal" DOS 1.0 apps? ;-)
> 
> I finally acquired an original DOS 1.0 distribution disk. Amazingly, it could still be read.

*sigh* so much for trying to sound clever....

Sorry, we were obviously thinking two different thoughts.  I meant "legal" as in DOS applications that don't try to circumvent system calls and generally mess with the system as old DOS programs were prone to do. Windows XP doesn't run those one's so well, I don't think.

I would never have thought to question you about "legal" in the other sense of the word.

Later,

John