"Alex Besogonov" <Alex_member@pathlink.com> wrote in message news:cbghkq$s6t$1@digitaldaemon.com...
> Building a frontend for GCC is now the simplest way to go.

I understand that you aim for something else - no problem.

> Combined effort is always good, but the direction is questionable.

I don't think so. First, GCC is not available everywhere. For instance, S/390 is only supported as a cross-compiler target. It is limited to Unix-inspired systems. I mention this, because I have been developing applications for such systems myself, and GCC has not been an option. There are probably other important platforms. Second, a D implementation is a proof-of-concept for the language, and allows the compiler developer to take advantage of the many nice features of the language.

Regards,
Martin M. Pedersen

John Reimer wrote:
> 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.

Did anyone ever use any feature of DOS? IIRC, DOS's immense popularity was only parallelled by its complete and utter nullity.

Cheers,
Sigbjørn Lund Olsen

Matthew wrote:

> "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 ...
> 
> 

Agreed, at first blush it seems a fine idea, and it was something that sprang to my mind. However, I'm wondering how code from several different D versions would operate. Consider, when we finally get our typesafe boolean, how does Dversion 2 code calling a Dversion 1 function returning a so-called "boolean" interface with the integer its given?

Cheers,
Sigbjørn Lund Olsen

Sigbjørn Lund Olsen wrote:
> Matthew wrote:
> 
>> "Andy Friesen" <andy@ikagames.com> wrote in message
>> news:cbf9s2$23vb$1@digitaldaemon.com...
>>
>>> 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 ...
> 
> Agreed, at first blush it seems a fine idea, and it was something that sprang to my mind. However, I'm wondering how code from several different D versions would operate. Consider, when we finally get our typesafe boolean, how does Dversion 2 code calling a Dversion 1 function returning a so-called "boolean" interface with the integer its given?

In this specific case, a D 1.0 'bool' simply does not exist.  The D 2.0 code would have to perform an explicit conversion from bit/int/whatever.

What's trickier is the reverse case, but even that's not all that complicated, since the compiler can be relied upon to handle the 2.0 spec.  The safest approach to this situation is probably to give the implementation the choice of either performing an implicit conversion to bit or causing an error. (the key being that the behaviour is optional, but well defined and therefore portable)

 -- andy

Andy Friesen wrote:
> Sigbjørn Lund Olsen wrote:
> 
>> Matthew wrote:
>>
>>> "Andy Friesen" <andy@ikagames.com> wrote in message
>>> news:cbf9s2$23vb$1@digitaldaemon.com...
>>>
>>>> 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 ...
>>
>>
>> Agreed, at first blush it seems a fine idea, and it was something that sprang to my mind. However, I'm wondering how code from several different D versions would operate. Consider, when we finally get our typesafe boolean, how does Dversion 2 code calling a Dversion 1 function returning a so-called "boolean" interface with the integer its given?
> 
> 
> In this specific case, a D 1.0 'bool' simply does not exist.  The D 2.0 code would have to perform an explicit conversion from bit/int/whatever.
> 
> What's trickier is the reverse case, but even that's not all that complicated, since the compiler can be relied upon to handle the 2.0 spec.  The safest approach to this situation is probably to give the implementation the choice of either performing an implicit conversion to bit or causing an error. (the key being that the behaviour is optional, but well defined and therefore portable)
> 
>  -- andy
how about a good ole fashioned warning :-)

Yes, yes, a warning!

Daniel Horn wrote:

> how about a good ole fashioned warning :-)

bleh.  Warnings are a symptom of a leaky design.  It's either good or it's not.

 -- andy

In article <cbi8gg$dqr$1@digitaldaemon.com>, Andy Friesen says...
>
>Daniel Horn wrote:
>
>> how about a good ole fashioned warning :-)
>
>bleh.  Warnings are a symptom of a leaky design.  It's either good or it's not.
>
>  -- andy


Ahem.  If we can't get a strong boolean type, we have to settle for what we can get.  How about it, Walter?  Walter?  Are you there?

Where are all the people who just hours ago were clammering for a strong boolean type?  Is anyone out there?  Why can't I get a comment?  Especially from professionals?

If we can't get a whole loaf, is there any chance we can get half a loaf?  If I'm nuts, at least tell me so, so I can stop writing these messages.

Rex Couture wrote:
> Where are all the people who just hours ago were clammering for a strong boolean
> type?  Is anyone out there?  Why can't I get a comment?  Especially from
> professionals?
> 
> If we can't get a whole loaf, is there any chance we can get half a loaf?  If
> I'm nuts, at least tell me so, so I can stop writing these messages.

Pieces were said, votes were cast, and in the end, Walter gets more votes than us. :)

 -- andy