> In article <cbe0sg$7q0$1@digitaldaemon.com>, Matthew says...
> > Or are you trying to foment a splinter
> > dialect of D?
>
> Whoa. Hey - chill out.

Not unchilled. (I didn't use the word "arse" <g>)

> I only expressed enthusiasm for something. You make it sound like I just proposed armageddon or something.

Well, you're a frequent and vocal contributor, and people seem to be paying attention to much of what you say.

What you said was something that was more serious than just general language discussions. I'm not saying you're a *very bad person*, or anything, of course, but suggesting that newer compilers introduce significant language incompatibilities is a *very bad thing*, and that needed to be pointed out asap in case someone might actually act on it.

> We're all friends here, and
> all working towards the same goal - to make D great. Yes?

Correctamundo, Vincent.

> Let's be nice to each
> other.

I wasn't aware I wasn't. Remember, no "arse".

In any case, I thought you were a fellow pommie? All that heated debate over tea and scones in the dorm room, what, what??

Being serious, I meant no offence, and I don't believe I gave any. But I do not resile from my criticisms of your suggestion.

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

> I guess I was
> just keen for that day to be sooner rather than later.

... although I am just as keen, if not more so, than you to see one. It'll just have to be an item #1 in "Imperfect D". You can help me with historical background, if you wish. :)


> Jill
> (NOT trying to start a splinter group)

Is that the PPFJ, or the JPF?

Nee!

Dr Shrubbery

Matthew wrote:
> "Arcane Jill" <Arcane_member@pathlink.com> wrote in message
> news:cbeanq$lm8$1@digitaldaemon.com...
> 
>>In article <cbe0sg$7q0$1@digitaldaemon.com>, Matthew says...
>>
>>>How can that be? The interconvertibility of boolean and integral types is a
>>>defined characteristic of the language. Only implementation-defined and
> 
> undefined
> 
>>>features may legitimately differ between implementations.
>>
>>Given the majority in favor of a separate boolean type, I would argue that
> 
> DMD's
> 
>>interconvertability of boolean and integral types is itself nothing more than
> 
> an
> 
>>implementation detail, and one which will eventually become very non-standard.
> 
> 
> Much as I'd love to agree, I think your logic if flawed. It's an important,
> almost ubiquitous, aspect of the language, and one which would dramatically
> change the compilability of code from differing implementations. I really cannot
> see how this would ever be considered an implementation-defined or undefined
> feature.

Agreed here too. AFAICS any provider can provide non-standard (and the standard for the time being *is* DMD, whether you like it or not) behaviour through pragmas, that *are* part of the standard. But obviously, you can't expect your code to compile on every D compiler, as it should.

TBH, I don't think any standards comittee would benefit D much at this stage. Walter does have a vision with D, so to speak, that seems to attract many, and would become marred in a standards comittee at this time. Not many people 'think' in D, and thus it would inevitably degenerate into a blending competition where every member wants the features from his/her favourite language.

I'd wait for D spec 2.0, and the occurence of multiple compilers based on different sources (both DMD and GDC are atm based on DMD), before starting on about standards committees.

Cheers,
Sigbjørn Lund Olsen

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.

Cheers,
Sigbjørn Lund Olsen

Just the compiler or a full development system including IDE?

Zz

"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,
> instead of conservative Boehm GC. Possibly, with heap compacting as in
modern
> Java virtual machines.
>
> Currently, as far as I understand, there is no standard on name mangling
and GC
> interoperability. Besides, language itself is not very suited for precise
GC :(
>
> PS: please excuse me for my somewhat poor English :)
>
> --Sapienti sat!

> > Excellent. Just make sure it supports a non-integer bool type and I'll
switch!
>
> How can that be? The interconvertibility of boolean and integral types is
a
> defined characteristic of the language. Only implementation-defined and
undefined
> features may legitimately differ between implementations.

Object Pascal uses a seperate Boolean type... life still continues ;-)

In Object Pascal all enums are a type of their own, not simply numbers as they are in C/C++. Indeed it wasn't till the advent of Delphi 8/Kylix 1 that enums could be created to have out of sequence logical values.

Indeed, defining an enum in Object Pascal:

type a = (a1, a2, a3, a4, a5, a6, a7);

the Ord() of a1 is 0, as all Object Pascal enums default to this, and Delphi
5 and previous _only_ exhibit this behaviour. (and we survive with this
restriction too!)

All D needs to support the old school C style boolean is the function Ord().

e.g.

Boolean a;

a = true;

int b;

b = a; //error!!

b = Ord(a); // b now contains the ordinal value of a

//alternatively

b = a.Ord();

Therefore, boolean contains the equiv of: {false, true}, and (Ord(false) ==
0); (Ord(true) == 1)

The only time this is painful is when you integrate a lot of C into your apps.

Matt

Alex Besogonov wrote:

> We're going to create yet another D compiler, but now with precise GC support,
> instead of conservative Boehm GC. Possibly, with heap compacting as in modern
> Java virtual machines.
> 
> Currently, as far as I understand, there is no standard on name mangling and GC
> interoperability. Besides, language itself is not very suited for precise GC :(

Yes, on one hand it seems to claim copying/heap compacting GC is valid, while on the other hand it would clearly screw some things up.

http://www.digitalmars.com/drn-bin/wwwnews?D/26273

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

"Sigbjørn Lund Olsen" <sigbjorn@lundolsen.net> wrote in message news:cben78$186s$1@digitaldaemon.com...
> > Much as I'd love to agree, I think your logic if flawed. It's an
important,
> > almost ubiquitous, aspect of the language, and one which would
dramatically
> > change the compilability of code from differing implementations. I
really cannot
> > see how this would ever be considered an implementation-defined or
undefined
> > feature.

Speaking from my experience with attempting to fix things I consider are egregious errors in the C++ standard, it does nobody any good to do so. Having a standard conforming compiler is better, despite the irritation at having to implement things I believe are obviously wrong.

That said, there is also a place for compilers to innovate new language features, to try them out and gain experience before proposing changes to the standard.

> Agreed here too. AFAICS any provider can provide non-standard (and the standard for the time being *is* DMD, whether you like it or not) behaviour through pragmas, that *are* part of the standard. But obviously, you can't expect your code to compile on every D compiler, as it should.
>
> TBH, I don't think any standards comittee would benefit D much at this stage. Walter does have a vision with D, so to speak, that seems to attract many, and would become marred in a standards comittee at this time. Not many people 'think' in D, and thus it would inevitably degenerate into a blending competition where every member wants the features from his/her favourite language.
>
> I'd wait for D spec 2.0, and the occurence of multiple compilers based on different sources (both DMD and GDC are atm based on DMD), before starting on about standards committees.

I agree that a standards committee needs to eventually happen, but is premature now. The reason, besides what you wrote, is that we're all now discovering what the right way to write programs in D is. For example, I've been working on a printf replacement, and am discovering some interesting ways to use nested functions to simplify things. The more D I write, the less and less it tends to look like C++. Sometimes I feel like Lewis & Clark exploring how to use all this new stuff. Until we're comfortable with the territory, it's probably premature to enter the multiyear bureaucratic standardization process.

I don't want to follow the path of Ada, which was standardized years before it was ever implemented, and kind of became a language people used only if they were forced to <g>.

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

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.

I agree that there ought to be a convincing reason to break backwards compatability, but I think it is important that we do not end up in a position where we cannot make needed changes because the acquis states we can't do that. That's when D++ / E / F / G / H ad infinitum will pop up.

We upgrade our hardware, OSs, libraries, our cellular phones, cars, and so forth. Why is it so hard for people to accept that they may need to upgrade their source code in the future? I've always learned that programming is 1% writing new code, and 99% maintaining old code.

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.

It really ought to be in a preamble to any D spec: "This standard will evolve."

Cheers,
Sigbjørn Lund Olsen

In article <cbejc2$12g8$1@digitaldaemon.com>, Matthew says...

>Well, you're a frequent and vocal contributor,

Um. It's a fair cop.


>and people seem to be paying
>attention to much of what you say.

Now, I wouldn't go THAT far.


>What you said was something that was more serious than just general language discussions. I'm not saying you're a *very bad person*, or anything, of course, but suggesting that newer compilers introduce significant language incompatibilities is a *very bad thing*, and that needed to be pointed out asap in case someone might actually act on it.

All I said was, if someone were to release a bool/int-typesafe compiler, I would use it. This remains true. And the reason is very simple - typesafe compilers find bugs which non-typesafe compilers do not. And since typesafe code will compile on a type-unsafe compiler, I really don't see a problem. I'm a practical person. If someone gives me a way of finding more bugs at compile-time than I could before, then I'm going to take advantage of that. That's not a significant language incompatibility - to get that you'd have to introduce a feature which WOULDN'T compile under DMD.




>In any case, I thought you were a fellow pommie? All that heated debate over tea and scones in the dorm room, what, what??

Not to worry, I'm drinking tea as we speak. Scones, I had the other day.


>Actually, sadly, I don't think we'll ever get a strongly typed boolean type in D,

Care to place a bet? "Ever" is a long time. The only way I see you being right on this one is if D is ultimately unsuccessful and dies, and I hope that does not happen.


>... although I am just as keen, if not more so, than you to see one. It'll just have to be an item #1 in "Imperfect D". You can help me with historical background, if you wish. :)

Er, how? (I did notice the smiley there, and I'm not completely sure if that was
serious).


>Dr Shrubbery

:)

This new logic amazes me, Sir Bedevere. Explain again how sheep's bladders may be employed to prevent earthquakes....?