"Walter" <newshound@digitalmars.com> wrote in message news:cbfif0$2ic2$1@digitaldaemon.com...
> 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.

I realize that, and I know you have put quite an effort into the frontend. But you have working with a very dynamic design of both the language and the compiler. In this case, the feature set of D is fixed, and a reference implementation of the frontend is already provided by you. There would not be much analysis or design to do - we would reuse your work (and help fixing documumentation problems). Reimplementing the frontend in D given these premises, I think, is not hard to do. The hard part is already done, and an effective team might even compare to you in calender-time :-) We are also helped by your compiler that is essential for boot-strapping.


Regards,
Martin

(and thanks for D:-)

It seems that there is a large number of people who really, really want a typesafe boolean type (or bool, or whatever it's called).  And they are adamant that they are going to get it sooner or later.

I guess Walter wants to retain the present boolean philosophy because it gives him the speed and flexibility he wants, it looks and smells like C, and besides, he probably doesn't want to make any changes.

Perhaps there is a compromise that would work for everyone.  I suggest a boolean type, called "boolean" or "bool", which is defined as part of the language.  Use of a nonboolean expression in a conditional statement could draw a mandatory compiler warning.

There is at least another possibility.  I kind of like the solution suggested by "me" on 24 Jun 2004 at 15:44.

So what do you say, Walter?  You always said this is a practical language, not for purists.  If you're going to break a little code, now is the time to do it. Fix it cleanly, once and for all, or fix it many times later.

Egad, what have I written?

You don't have to break any code -- or practically none -- to give everyone what they want.  How about a pragma or switch if you want to turn off strict boolean typing, and let the rest of us have our strict boolean type?

That's my preferred solution, but I could also go for a mandatory compiler warning (which could be explicitly turned off).

Walter has already ruled out a solution similar to that proposed by "me", since he wants values of 0 and not 0 instead of 0 and 1.  OK, fine, but we really want a strict boolean type.

(If this message doesn't quite make sense, it may have been posted before the one it's supposed to come after.  The Forum server is exceedingly slow to post tonight.)

Ah, yes, after catching up on messages, I see it.  Of course, there are more urgent things.  But could we simply have a strong boolean type defined as the coming standard?

In article <cbeom3$1a7l$1@digitaldaemon.com>, Zz says...
>Just the compiler or a full development system including IDE?
Currently we don't plan to create full IDE support (compiler is a hard task itself). But it shouldn't be really hard to add D support to Eclipse. After all, there is C++ support in Eclipse.

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

Hi Alex,

Your "somewhat poor English" is far superior to my non-existent Russian.

You've mentioned "we" a couple of times; can you be more explicit about who this group is composed of please? I'm just interested ...

Sapienti sat!: http://www.telekritika.kiev.ua/tv_week/?id=10460

- Kris

"Alex Besogonov" <Alex_member@pathlink.com> wrote in message news:cbgg3r$q4k$1@digitaldaemon.com...
> In article <cbeom3$1a7l$1@digitaldaemon.com>, Zz says...
> >Just the compiler or a full development system including IDE?
> Currently we don't plan to create full IDE support (compiler is a hard
task
> itself). But it shouldn't be really hard to add D support to Eclipse.
After all,
> there is C++ support in Eclipse.
>
> >"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!
> >
> >
>
>

In article <cbfbu9$27lp$1@digitaldaemon.com>, Martin M. Pedersen says...
>"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.
IMHO, what we need now is _libraries_. Right now there is no decent XML/XSLT libraries, no decent RPC libraries, etc.

>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.
Language-to-language translation is messy and resulting code is very hard to debug. Besides, our precise GC and exceptions support require some tricks with stack.

Building a frontend for GCC is now the simplest way to go.

>What does people think about a combined effort in this direction?
Combined effort is always good, but the direction is questionable.

--Sapienti sat!

In article <cbf3pr$1qpi$1@digitaldaemon.com>, Stewart Gordon 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 :(
>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
I was writing the similar list :) Problems with unions can be resolved by "discriminant" field or by prohibiting to use pointers in unions. Also we need a notion of a "fixed" pointer - that can resolve lots of problems.

--Sapienti sat!

> Walter has already ruled out a solution similar to that proposed by "me",
since
> he wants values of 0 and not 0 instead of 0 and 1.  OK, fine, but we
really want
> a strict boolean type.

If you are easily offended by people who criticise C, please stop reading here...

Well, this is a big legacy hangover from C. Surely boolean is True or False, it's not True or some shade of False (or vice versa). If a *true* Boolean is to be used, it can _only_ be True or False. Otherwise it's not really a Boolean, it's a legacy "hack". Using Boolean to convey error or additional information is, IMHO, inappropriate. Surely this is what status_t is for in C? Return an error/status integer if that floats your boat, but Boolean should be, well, Boolean. This is one thing Pascal has _right_ over C and it's offspring.

To quote Yoda, "Do or do not, there is no try."

All of this stems from C's lack of real enumeration. As I described, in Pascal a enum is a distinct type. It does not represent a bunch of numbers aliased to constant names. You can find it's logical order (as it is an ordinal type), but it is not a real number. This makes an awful lot of sense (and causes zero ambiguity when coding because you are unable to use integers in place of enums without casting) especially when using sets. I suspect D supports some kind of sets; bits? Haven't delved that far into the docs... Sets rule!

type
  TFontStyle = (fsBold, fsItalic, fsUnderline, ...);
  TFontStyles = set of TFontStyle;

var
  fs: TFontStyles;
begin
  fs := [fsBold, fsItalic];

  if (fsBold in fs) then .... ; //True

  if (fsUnderline in fs) then ... ; //False

  fs := fs - [fsBold] + [fsUnderline];

  if ( not(fsBold in fs) and (fsUnderline in fs) ) then ....; //True
end;

That's not even scratching the intersection, subset, superset, equality and inequality operators.

Matt

I agree completely, but how do we get Walter's -- or anyone's -- attention?

It's weird.  One moment people were demanding a strongly typed boolean.  As soon as we propose solutions (on the same day), there is a resounding silence.

I should explain what sounded like a criticism of your elegant solution (and it really is elegant and simple -- I like it).  Boolean types were discussed at lengths a few weeks ago, and Walter firmly defended boolean types as either an integer, a bit type, or "bool", which is an alias for a bit type.  The real boolean type is to be called "bit"!  He wanted to be able to represent a boolean as an integer 0 (false) or not 0 (true), rather than 0 or 1.  Walter explained that the reason for choosing the former is that it saves 3 computer instructions over the latter, and for sorting, that makes a significant difference.

I must add that except for bug fixes, I have never had any success with suggesting a change in any compiler or any other kind of computer program, no matter how broken it was.

In article <cbh2n3$1mof$1@digitaldaemon.com>, me says...
>
>> Walter has already ruled out a solution similar to that proposed by "me",
>since
>> he wants values of 0 and not 0 instead of 0 and 1.  OK, fine, but we
>really want
>> a strict boolean type.
>
>If you are easily offended by people who criticise C, please stop reading here...
>
>Well, this is a big legacy hangover from C. Surely boolean is True or False, it's not True or some shade of False (or vice versa). If a *true* Boolean is to be used, it can _only_ be True or False. Otherwise it's not really a Boolean, it's a legacy "hack". Using Boolean to convey error or additional information is, IMHO, inappropriate. Surely this is what status_t is for in C? Return an error/status integer if that floats your boat, but Boolean should be, well, Boolean. This is one thing Pascal has _right_ over C and it's offspring.
>
>To quote Yoda, "Do or do not, there is no try."
>
>All of this stems from C's lack of real enumeration. As I described, in Pascal a enum is a distinct type. It does not represent a bunch of numbers aliased to constant names. You can find it's logical order (as it is an ordinal type), but it is not a real number. This makes an awful lot of sense (and causes zero ambiguity when coding because you are unable to use integers in place of enums without casting) especially when using sets. I suspect D supports some kind of sets; bits? Haven't delved that far into the docs... Sets rule!
>
>type
>  TFontStyle = (fsBold, fsItalic, fsUnderline, ...);
>  TFontStyles = set of TFontStyle;
>
>var
>  fs: TFontStyles;
>begin
>  fs := [fsBold, fsItalic];
>
>  if (fsBold in fs) then .... ; //True
>
>  if (fsUnderline in fs) then ... ; //False
>
>  fs := fs - [fsBold] + [fsUnderline];
>
>  if ( not(fsBold in fs) and (fsUnderline in fs) ) then ....; //True
>end;
>
>That's not even scratching the intersection, subset, superset, equality and inequality operators.
>
>Matt
>