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!

In article <cbdu03$2ef$1@digitaldaemon.com>, Alex Besogonov says...
>
>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!

Compatibility is important though, and this is difficult without a standard. If the two compilers give different results, it is currently not possible to argue that one is standards compliant and the other one isn't. That will come in time, and having two compilers is certainly a start, but I fear that, to begin with, we may have non-interoperable DMD-D and ALEX-D (sorry, I don't know what you plan to call your compiler). I guess it's just a phase we'll have to go through, until that standards committee comes into existence though.

Arcane Jill

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 :(
> 
> PS: please excuse me for my somewhat poor English :)

I don't know if this is what you were getting at, but if the D ABI specifies that object references are implemented as pointers, then there will be problems with compacting GCs.

At some point, I recall someone mentioning that MacOS (not sure which version) implemented object handles as void**s.  This gave the OS freedom to move objects around, provided that the proxy-handle remained stationary.

Maybe the D ABI should do something like this.

 -- andy

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cbdvdu$58u$1@digitaldaemon.com...
> In article <cbdu03$2ef$1@digitaldaemon.com>, Alex Besogonov says...
> >
> >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.

Do you not realise that boolean/integral interconvertitibility is *not* an implementation-defined/undefined feature? Or are you trying to foment a splinter dialect of D?

For all that I feel just as strongly about a strongly type boolean as yourself, splintering the language is a very bad idea, and won't benefit anybody.

> Compatibility is important though, and this is difficult without a standard. If the two compilers give different results, it is currently not possible to argue that one is standards compliant and the other one isn't. That will come in
time,
> and having two compilers is certainly a start, but I fear that, to begin with, we may have non-interoperable DMD-D and ALEX-D (sorry, I don't know what you plan to call your compiler). I guess it's just a phase we'll have to go
through,
> until that standards committee comes into existence though.

In article <cbdvdu$58u$1@digitaldaemon.com>, Arcane Jill says...
>
>In article <cbdu03$2ef$1@digitaldaemon.com>, Alex Besogonov says...
>>
>>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!
YADC (Yet Another D Compiler) is FAR from being finished. Currently we only have
working GC from another project (I have to wait for 6 more months to release
sources under OpenSource license).

>Compatibility is important though, and this is difficult without a standard. If the two compilers give different results, it is currently not possible to argue that one is standards compliant and the other one isn't. That will come in time, and having two compilers is certainly a start, but I fear that, to begin with, we may have non-interoperable DMD-D and ALEX-D (sorry, I don't know what you plan to call your compiler).
There is two comilers right now: DMD and GNU.D :) Three compilers without one standard is too much.

> I guess it's just a phase we'll have to go through,
> until that standards committee comes into existence though.
Yes, and I think it committee should come as soon as possible after D 1.0.

--Sapienti sat!

In article <cbe07k$6vl$1@digitaldaemon.com>, Andy Friesen says...
>
>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 :(
>> 
>> PS: please excuse me for my somewhat poor English :)
>I don't know if this is what you were getting at, but if the D ABI specifies that object references are implemented as pointers, then there will be problems with compacting GCs.
Having references implemented as pointers doesn't really prevent using of precise compacting GC. For example, in current JVMs object references are implemented as direct pointers to objects. The crucial part is the ability to distinguish between integer and pointer with 100% certainty.

Current D specification has lots of incompatibilities with precise GC. This is OK, because nobody is going to make precise GC support _soon_ but it WILL be a problem in a not-so-far future.

There will be problems even with different conservative GCs with the current ABI.

>At some point, I recall someone mentioning that MacOS (not sure which
>version) implemented object handles as void**s.  This gave the OS
>freedom to move objects around, provided that the proxy-handle remained
>stationary.
>Maybe the D ABI should do something like this.
Double indirection is too slow and is not really needed.

--Sapienti sat!

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.

I guess it boils down to "Who defines what is standard?". You can either have every single D complier on the planet slavishly following DMD, or every single D compiler conforming to "the standard". But currently, there is no "the standard". I guess we need that ISO committee.

Jill

> I guess it boils down to "Who defines what is standard?". You can either
have
> every single D complier on the planet slavishly following DMD, or every
single D
> compiler conforming to "the standard". But currently, there is no "the standard". I guess we need that ISO committee.

The D specification specifies what a D compiler is.

> Jill
>
>

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

Whoa. Hey - chill out. I only expressed enthusiasm for something. You make it sound like I just proposed armageddon or something. We're all friends here, and all working towards the same goal - to make D great. Yes? Let's be nice to each other.

History will give us the bool one day. All we have to do is wait. I guess I was just keen for that day to be sooner rather than later.

Jill
(NOT trying to start a splinter group)

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

> I guess it boils down to "Who defines what is standard?". You can either have every single D complier on the planet slavishly following DMD, or every single
D
> compiler conforming to "the standard". But currently, there is no "the standard". I guess we need that ISO committee.

There's a simple answer: Walter.

Until such time as the control of D is wrested from him by an ISO committee - and that'll be at least 5 years - that's going to be the case. So, by all means, don't give up hope of changing his mind on this, or other, issues, but splintering the language at any time is bad, and at this time would be either futile or fatal, neither of which will do anyone any service.

One thing that might be useful, however, would be for a different compiler, or a separate dlint tool, to be able to analyse and report on any implicit conversions. Then we could check these hidden nasties in our code without upsetting the general applecart.

(FWIW, Walter added the -wc warning to DMC++ at my behest, which is exceedingly useful when doing a code proofing compile. I know we can't get him to add warnings to dmd - and I pretty much agree - but we can hope that when big-W is producing DM commercial D tools, he'll be able to add testes for these kinds of things.)