www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D compilers compatibility

reply Alex Besogonov <Alex_member pathlink.com> writes:
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!
Jun 23 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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
Jun 24 2004
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"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.
Jun 24 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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
Jun 24 2004
next sibling parent "Bent Rasmussen" <exo bent-rasmussen.info> writes:
 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
Jun 24 2004
prev sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"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.)
Jun 24 2004
parent reply =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
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
Jun 24 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"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>.
Jun 24 2004
parent reply Matthias Becker <Matthias_member pathlink.com> writes:
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++.


Hehe, so you're finding out the basics of functional progrmming, every SML or
LISP-coder already knows.
Jun 26 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cbj8pr$1q8t$1 digitaldaemon.com>, Matthias Becker says...


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


One thing I would ask, as it's important in things like localization - can you
give us a way to get at the nth, rather than next, parameter. For instance,
something like:



would print the right values in the right order.

Also, I assume there will be also be functions like:





because obviously UTF-32 is going to be faster than UTF-8, once you go beyond
ASCII, and it would seem dumb to have to push everything through a UTF-8
bottleneck when you don't have to.

Arcane Jill
Jun 26 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cbjald$1ssp$1 digitaldaemon.com...

 One thing I would ask, as it's important in things like localization - can


you

 give us a way to get at the nth, rather than next, parameter. For


instance,

 something like:



 would print the right values in the right order.


Can you give an example where this would be necessary?


 Also, I assume there will be also be functions like:





 because obviously UTF-32 is going to be faster than UTF-8, once you go


beyond

 ASCII, and it would seem dumb to have to push everything through a UTF-8
 bottleneck when you don't have to.


Win9x is a UTF-8 system internally, Win32 is UTF-16, and linux is a UTF-8
system. I.e., there's going to be a translation going on somewhere anyway.
(In Win32, the first thing the 'A' functions do internally is convert the
strings to 'W'. In Win9x, it's the reverse, the 'W' functions' first step is
to convert the strings to 'A'.)

While it does look like UTF-32 might be faster than UTF-8, in practice,
things don't seem so straightforward. I've written a front to back UTF-32
string processing server program, and it consumed so much memory that the gc
time and the hard disk swap time ate up more than any savings in CPU
operations.

This requires most every library function to have 3 versions, one for each
string type. That would bulk things up quite a bit.

So I decided to make the library primarilly focussed on UTF-8, with the easy
ability to convert to/from UTF-16 and UTF-32. There's nothing preventing
anyone, however, from taking the lib sources and making UTF-16/32 versions
with little effort.
Jun 26 2004
next sibling parent Andy Friesen <andy ikagames.com> writes:
Walter wrote:

 "Arcane Jill" <Arcane_member pathlink.com> wrote in message
 news:cbjald$1ssp$1 digitaldaemon.com...
 

One thing I would ask, as it's important in things like localization - can


 
 you
 

give us a way to get at the nth, rather than next, parameter. For


 
 instance,
 

something like:



would print the right values in the right order.


 
 
 Can you give an example where this would be necessary?


Different languages need to place verbs and nouns in different orders. 
If the program can just say that %1 is the object and %2 is the action, 
then the language strings can just say "%1 is a %2".  Languages for 
which it is more natural to place %2 before %1 can do the obvious thing.

  -- andy
Jun 26 2004
prev sibling next sibling parent reply Daniel Horn <hellcatv hotmail.com> writes:
Why not use templates, walter :-)you can alias them if you wish, but 
templates are the sane answer here
Walter wrote:

 "Arcane Jill" <Arcane_member pathlink.com> wrote in message
 news:cbjald$1ssp$1 digitaldaemon.com...
 

One thing I would ask, as it's important in things like localization - can


 
 you
 

give us a way to get at the nth, rather than next, parameter. For


 
 instance,
 

something like:



would print the right values in the right order.


 
 
 Can you give an example where this would be necessary?
 
 

Also, I assume there will be also be functions like:





because obviously UTF-32 is going to be faster than UTF-8, once you go


 
 beyond
 

ASCII, and it would seem dumb to have to push everything through a UTF-8
bottleneck when you don't have to.


 
 
 Win9x is a UTF-8 system internally, Win32 is UTF-16, and linux is a UTF-8
 system. I.e., there's going to be a translation going on somewhere anyway.
 (In Win32, the first thing the 'A' functions do internally is convert the
 strings to 'W'. In Win9x, it's the reverse, the 'W' functions' first step is
 to convert the strings to 'A'.)
 
 While it does look like UTF-32 might be faster than UTF-8, in practice,
 things don't seem so straightforward. I've written a front to back UTF-32
 string processing server program, and it consumed so much memory that the gc
 time and the hard disk swap time ate up more than any savings in CPU
 operations.
 
 This requires most every library function to have 3 versions, one for each
 string type. That would bulk things up quite a bit.
 
 So I decided to make the library primarilly focussed on UTF-8, with the easy
 ability to convert to/from UTF-16 and UTF-32. There's nothing preventing
 anyone, however, from taking the lib sources and making UTF-16/32 versions
 with little effort.
Jun 26 2004
parent "Walter" <newshound digitalmars.com> writes:
"Daniel Horn" <hellcatv hotmail.com> wrote in message
news:cbkjnd$kn6$1 digitaldaemon.com...

 Why not use templates, walter :-)you can alias them if you wish, but
 templates are the sane answer here


You might be right.
Jun 26 2004
prev sibling next sibling parent Arcane Jill <Arcane_member pathlink.com> writes:
In article <cbkapi$8nj$1 digitaldaemon.com>, Walter says...



 would print the right values in the right order.


Can you give an example where this would be necessary?


Not a real one, no, because the only language I can speak is English. But in
other languages, word order in a sentence can be different. So, let's make up an
add hoc example.
















Now, you can see that the statement:



will print the correctly localized text for both languages - but only IF we can
access the printf arguments by random access.

Jill
Jun 26 2004
prev sibling next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cbkapi$8nj$1 digitaldaemon.com>, Walter says...


While it does look like UTF-32 might be faster than UTF-8, in practice,
things don't seem so straightforward. I've written a front to back UTF-32
string processing server program, and it consumed so much memory that the gc
time and the hard disk swap time ate up more than any savings in CPU
operations.


I'm not sure you'd be saying that if your native language were Chinese.



This requires most every library function to have 3 versions, one for each
string type. That would bulk things up quite a bit.


Templates?

I have the same problem actually. Should Unicode functions like
getUppercaseMapping() (which returns a string) return UTF-8 chars, UTF-16 wchars
or UTF-32 dchars? Or all three? I'm starting to think that templates are the
only answer - choose your own char type.



There's nothing preventing
anyone, however, from taking the lib sources and making UTF-16/32 versions
with little effort.


I didn't realize we were allowed to do that.

Jill
Jun 26 2004
parent "Walter" <newshound digitalmars.com> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cbkqvu$vn2$1 digitaldaemon.com...

 In article <cbkapi$8nj$1 digitaldaemon.com>, Walter says...

While it does look like UTF-32 might be faster than UTF-8, in practice,
things don't seem so straightforward. I've written a front to back UTF-32
string processing server program, and it consumed so much memory that the




gc

time and the hard disk swap time ate up more than any savings in CPU
operations.


 I'm not sure you'd be saying that if your native language were Chinese.


The core D language itself is agnostic over whether char[], wchar[] or
dchar[] is preferred. The library, however, is char[] to reduce the
complexity of it and to recognize the fact that the overwhelming majority of
string processing programs are going to be dealing with ASCII with a
smattering of multibyte unicode characters. This will be true even if you're
a native Chinese speaker - the requirements for the server program I wrote
did not mention what language I spoke <g>.

The important thing for now is that Unicode works right, not that it be
optimized for all programs.


This requires most every library function to have 3 versions, one for




each

string type. That would bulk things up quite a bit.


 Templates?
 I have the same problem actually. Should Unicode functions like
 getUppercaseMapping() (which returns a string) return UTF-8 chars, UTF-16


wchars

 or UTF-32 dchars? Or all three? I'm starting to think that templates are


the

 only answer - choose your own char type.



There's nothing preventing
anyone, however, from taking the lib sources and making UTF-16/32




versions

with little effort.


 I didn't realize we were allowed to do that.


Yes, you are.
Jun 26 2004
prev sibling next sibling parent reply " (write-my-first-name-here).info" <""contact\" (write-my-first-name-here).info"> writes:
Walter wrote:

would print the right values in the right order.


 
 Can you give an example where this would be necessary?


My small contribution (I read this newsgroup a bit for some time, but 
this is just my second post, so I'll be modest *g*).

I have already worked translating software, and this is a real issue. If 
you check gettext and other i18n projects, it will become clear that a 
printf which supports positional parameters is really desired. GNU Libc 
implemented it, aiding this big wound in i18n, GLib (which has its own 
gettext interface embedded) ported it to other platforms, and Java did 
the same thing (in its own way).

The way it is done in C is probably much more complex than the way it 
will ever be in D, since in C we do not know for sure which argument 
types were passed in the function call. The format string is parsed once 
and all positional arguments (eg: "%1$s") are inferred and indexed in an 
internal table with their type. All arguments are read (in fact, their 
pointers are copied to that table) and the string is parsed again, now 
assembling the output with what we collected before.

In a positinal-parameter-enabled printf, you can do:

    printf("%1$s %2$s", adjective, noun);

and in a, for example, portuguese phrase, you can swap both names 
accordingly to make the correct sense:

    printf("%2$s %1$s", adjective, noun);

No need to change adjective and noun parameters, no need to change the 
compiled code; you need just to pass the format string to gettext (or 
other i18n API) and printf will assemble it. Note that this has a major 
drawback: all parameters must be in the format string, because printf 
must know the type and size of each one in the stack. If not, it will 
predict to be an int (or void*, not sure now). So this may work:

    printf("%1$s %3$s", "AAA", 1, "BBB");   // result: "AAA BBB"

But this certainly not:

    printf("%1$s %3$s", "AAA", 1.0, "BBB");

This kind of problem that an implementation like this on D won't have, 
since `_arguments´ already have the information we need to create the 
internal table with all the arguments, we need to parse the format 
string just once.

I also think that format type specifiers will be pointless in D. It 
won't have much sense to check, for example, if the corresponding 
argument for a %s is really a string, although having many formats for 
float (e, E, f, F, g, G) and integer (d, o, x) would be nice. This 
probably makes a printf-compatible syntax a bad idea.

Any thoughts?

BTW, D is really great!! :-D

Cheers,
Juliano.
Jun 26 2004
parent "Walter" <newshound digitalmars.com> writes:
Some good information here, I didn't know glib did this. -Walter

" (write-my-first-name-here).info"
<""contact\" (write-my-first-name-here).info"> wrote in message
news:cblbj3$1ne1$1 digitaldaemon.com...

 Walter wrote:

would print the right values in the right order.


 Can you give an example where this would be necessary?


 My small contribution (I read this newsgroup a bit for some time, but
 this is just my second post, so I'll be modest *g*).

 I have already worked translating software, and this is a real issue. If
 you check gettext and other i18n projects, it will become clear that a
 printf which supports positional parameters is really desired. GNU Libc
 implemented it, aiding this big wound in i18n, GLib (which has its own
 gettext interface embedded) ported it to other platforms, and Java did
 the same thing (in its own way).

 The way it is done in C is probably much more complex than the way it
 will ever be in D, since in C we do not know for sure which argument
 types were passed in the function call. The format string is parsed once
 and all positional arguments (eg: "%1$s") are inferred and indexed in an
 internal table with their type. All arguments are read (in fact, their
 pointers are copied to that table) and the string is parsed again, now
 assembling the output with what we collected before.

 In a positinal-parameter-enabled printf, you can do:

     printf("%1$s %2$s", adjective, noun);

 and in a, for example, portuguese phrase, you can swap both names
 accordingly to make the correct sense:

     printf("%2$s %1$s", adjective, noun);

 No need to change adjective and noun parameters, no need to change the
 compiled code; you need just to pass the format string to gettext (or
 other i18n API) and printf will assemble it. Note that this has a major
 drawback: all parameters must be in the format string, because printf
 must know the type and size of each one in the stack. If not, it will
 predict to be an int (or void*, not sure now). So this may work:

     printf("%1$s %3$s", "AAA", 1, "BBB");   // result: "AAA BBB"

 But this certainly not:

     printf("%1$s %3$s", "AAA", 1.0, "BBB");

 This kind of problem that an implementation like this on D won't have,
 since `_arguments´ already have the information we need to create the
 internal table with all the arguments, we need to parse the format
 string just once.

 I also think that format type specifiers will be pointless in D. It
 won't have much sense to check, for example, if the corresponding
 argument for a %s is really a string, although having many formats for
 float (e, E, f, F, g, G) and integer (d, o, x) would be nice. This
 probably makes a printf-compatible syntax a bad idea.

 Any thoughts?

 BTW, D is really great!! :-D

 Cheers,
 Juliano.
Jun 26 2004
prev sibling parent Jonathan Leffler <jleffler earthlink.net> writes:
In article <cbkapi$8nj$1 digitaldaemon.com>, Walter says...

"Arcane Jill" <Arcane_member pathlink.com> wrote:

 One thing I would ask, as it's important in things like localization -
 can you give us a way to get at the nth, rather than next, parameter.
 For instance, something like:



 would print the right values in the right order.


Can you give an example where this would be necessary?


I'm joining in this thread very late, but I've not seen an answer to Walter's
question, but Jill raises a valid issue.

In an English message, you would need words in the order <adjective> <noun>.
In French, amongst other languages, you would need words in the order <noun>
<adjective>.

red fox

renard rouge

If you had messages in a file, and read different files for different languages,
but the formatting code was the same for all, then you'd benefit from having the
English message containing:

The %1$s %2$s is coming.

And the French message containing:

Le %2$s %1$s arrivant.

(Apologies for the butchered French, lack of accents, and probable problems with
gender - but it is a motivational example, not a production system.  A better
example would use two nouns - the subject and object of a sentence - where in
one language, the best phrase needed the subject to come before the object and
another language needed the reverse order.  One of the systems I work on has a
feature request for that, but the second language is Korean and I don't know
enough Korean to give you a semi-decent example.)

In C, the calling code might be:

snprintf(buffer, sizeof(buffer), fmtstr, adj, noun);

Where buffer is where the output is placed, fmtstr was read from a file and
contained the %n$s notations, and adj and noun are variables containing the
adjective and noun.  The D notation would be somewhat different - someone better
versed in the ways to do it should define that for me.

The POSIX standard for sprintf() et al supports the n$ notation that I used.

See: http://www.opengroup.org/onlinepubs/009695399/functions/fprintf.html

At the very least, this gives a standardized precedent.

Jonathan Leffler                   #include <disclaimer.h>
Email: jleffler earthlink.net, jleffler us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
Jul 08 2004
prev sibling next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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)
Jun 24 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
 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

background, if you wish. :)



 Jill
 (NOT trying to start a splinter group)


Is that the PPFJ, or the JPF?

Nee!

Dr Shrubbery
Jun 24 2004
next sibling parent reply =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
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
Jun 24 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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.
Jun 24 2004
next sibling parent reply =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
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
Jun 24 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"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.)
Jun 24 2004
parent reply John Reimer <jjreimer telus.net> writes:
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? ;-)
Jun 24 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"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.
Jun 24 2004
parent reply John Reimer <jjreimer telus.net> writes:
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
Jun 24 2004
next sibling parent =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
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
Jun 25 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"John Reimer" <jjreimer telus.net> wrote in message
news:cbfivf$2inn$1 digitaldaemon.com...

 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.


That was done so often that those circumventions (such as TSR's) became part
of the DOS standard.


 Windows XP doesn't run those one's so well, I don't think.


Maybe not, but it's still an impressive run of compatibility.
Jun 26 2004
prev sibling parent reply Andy Friesen <andy ikagames.com> writes:
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
Jun 24 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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.
Jun 24 2004
next sibling parent Rex Couture <Rex_member pathlink.com> writes:
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.
Jun 24 2004
prev sibling parent reply Rex Couture <Rex_member pathlink.com> writes:
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.)
Jun 24 2004
next sibling parent Rex Couture <Rex_member pathlink.com> writes:
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?
Jun 24 2004
prev sibling parent reply "me" <memsom interalpha.co.uk> writes:
 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
Jun 25 2004
parent Rex Couture <Rex_member pathlink.com> writes:
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
Jun 25 2004
prev sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"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 ...
Jun 24 2004
parent reply =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
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
Jun 25 2004
parent reply Andy Friesen <andy ikagames.com> writes:
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
Jun 25 2004
parent reply Daniel Horn <hellcatv hotmail.com> writes:
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 :-)
Jun 25 2004
next sibling parent Rex Couture <Rex_member pathlink.com> writes:
Yes, yes, a warning!
Jun 25 2004
prev sibling parent reply Andy Friesen <andy ikagames.com> writes:
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
Jun 25 2004
parent reply Rex Couture <Rex_member pathlink.com> writes:
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?
Jun 25 2004
parent reply Rex Couture <Rex_member pathlink.com> writes:
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.
Jun 25 2004
next sibling parent reply Andy Friesen <andy ikagames.com> writes:
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
Jun 25 2004
parent reply Rex Couture <Rex_member pathlink.com> writes:
In article <cbifmt$nre$1 digitaldaemon.com>, Andy Friesen says...

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



In the end, users get the only votes that count.

I just don't think anyone has had a reasonable look at the only compromise I can
identify that actually meets all objections.
Jun 26 2004
parent reply Andy Friesen <andy ikagames.com> writes:
Rex Couture wrote:


 In article <cbifmt$nre$1 digitaldaemon.com>, Andy Friesen says...
 

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


 
 In the end, users get the only votes that count.


At its core, D is Walter's vision of what a C++like language should be. 
  It's absolutely phenominal that he's as receptive to ideas and input 
as he is, but, in the end, Walter's vision gets more votes than any of 
us, and I think that is a good thing.  That unified vision, despite 
being uniquely aggrivating on this specific issue, has gone a long, long 
way towards keeping D consistent and orthogonal.

As another example, I feel rather secure saying that none of us are 
nearly as concerned about the implementability of the compiler as 
Walter.  This has kept template argument deduction out of our reach, but 
is likely the sole reason why DMD is as fast as it is.  (it's kind of 
interesting to watch it plow through 100 source files--27000 lines of 
code--in less than a second)


 I just don't think anyone has had a reasonable look at the only compromise I
can
 identify that actually meets all objections.


Is this the one?
<news://news.digitalmars.com:119/cbfu81$16p$1 digitaldaemon.com>

One:  Walter does not like compile-time warnings because they indicate a 
weakness in the language design and because they inevitably wind up 
being nothing more than a nuisance.  Compiling GDC on GCC 3.x raises 
literally hundreds of completely pointless warnings. (most are of the 
"enum value 'BORK' not used in switch block" variety)

Most programmers either supress them, or they add hacks to the code just 
to shut the compiler up.

Two: Walter does not like pragmas that change the nature of the 
language.  This one is a no-brainer; it's makes for a hidously 
inconsistent language with far too many 'magical' syntactical oddities.

I myself would love a pedantic, anally retentive boolean type, but the 
current situation really isn't that bad.  With the exception of 
Object.opEquals, (which I have to assume is a bug) things that look as 
though they are boolean values behave as though they are boolean values. 
  Further, as luck would have it, arithmetic operations on this type are 
disallowed.

It's not what I call ideal, but I have yet to suffer a bug which a 
strict boolean type would have caught.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD Mildly Bitter and Mostly Offtopic 
Rant//EN">
<rant>
This type (bit) will probably not see much use beyond the context of 
boolean logic anyway.  Its main selling point arises from arrays and 
slices of bits, which were originally incorporated into the language 
before operator overloading made implementing such a construct within 
the language itself feasable. (not unlike associative arrays, in fact, 
but much moreso)
</rant>

  -- andy
Jun 26 2004
parent reply Rex Couture <Rex_member pathlink.com> writes:
In article <cbkokj$sb0$1 digitaldaemon.com>, Andy Friesen says...


That unified vision, despite 
being uniquely aggrivating on this specific issue, has gone a long, long 
way towards keeping D consistent and orthogonal.
...(it's kind of 
interesting to watch it plow through 100 source files--27000 lines of 
code--in less than a second)


Thanks for your thoughtful reply.  I never thought I'd get one.  I appreciate
your thoughts, but I'm stubborn too.

I'm still mystified by his peculiar vision on this one.  Do you suppose he will
cave in and give us strict booleans after version 1 is stable, or will the
language then be frozen, lest it break too much code?

I know nothing about building compilers, but I've seen too many counterexamples
to believe that a strict boolean type would significantly affect compilation
time.



 I just don't think anyone has had a reasonable look at the only compromise I
can identify that actually meets all objections.


Is this the one?
<news://news.digitalmars.com:119/cbfu81$16p$1 digitaldaemon.com>


Well, there were several messages, so let me just explain it again.  I suggest
one of the following:
1. strict boolean, with a switch or pragma or compiler directive to turn on
extended (integer, bit, etc.) boolean types.
2. a strict boolean type built into the language, with a mandatory warning if a
bit, bool, or integer type is used in a conditional statement.  The warning
could be turned off, so Walter and others can do their funny little speed
tricks.



One:  Walter does not like compile-time warnings because they indicate a 
weakness in the language design and because they inevitably wind up 
being nothing more than a nuisance.
Most programmers either supress them, or they add hacks to the code just 
to shut the compiler up.
Two: Walter does not like pragmas that change the nature of the 
language.  This one is a no-brainer; it's makes for a hidously 
inconsistent language with far too many 'magical' syntactical oddities.


1. But a weakness in the language is even more indicative of a weakness in the
language.  No need to suppress warnings if you just stick to strict booleans, as
you probably should 99% of the time.

2.  A boolean type called "bit" isn't a syntactical oddity?  Walter already sort
of endorsed pragmas.  His words:  "That might work."  I don't like pragmas
either, but switches and compiler directives (what do you call
them--meta-instructions?) work fine.  That one's not my call.



It's not what I call ideal, but I have yet to suffer a bug which a 
strict boolean type would have caught.


I actually had a program suddenly fail after years of working correctly, because
of a language quirk.  Sooner or later, someone's code is going to fail af some
inopportune time after being debugged, because the compiler didn't catch what
should have been a type error.  That's what causes patients to die and gazillion
dollar space probes to fail.

If it can happen, it will.  Your compiler is either type-safe or it isn't.
Jun 26 2004
parent Andy Friesen <andy ikagames.com> writes:
Rex Couture wrote:

 Thanks for your thoughtful reply.  I never thought I'd get one.  I appreciate
 your thoughts, but I'm stubborn too.


To be perfectly frank, I agree that a strict boolean type is a good 
thing.  I just happen to think that the current semantics are workable 
enough that I can move on.


 I'm still mystified by his peculiar vision on this one.  Do you suppose he will
 cave in and give us strict booleans after version 1 is stable, or will the
 language then be frozen, lest it break too much code?


I'm not too optimistic.  Pretty much everybody seems to be in favour of 
this except Walter.  It didn't take nearly that sort of response to sway 
him in any other issue, (as far as I can recall) yet he remains unmoved 
on this issue.


 I know nothing about building compilers, but I've seen too many counterexamples
 to believe that a strict boolean type would significantly affect compilation
 time.


It wouldn't.  I was just pointing out one of the benefits of having 
Walter as our BDFL*.


 1. ... a weakness in the language is even more indicative of a weakness in the
 language.


Yup.


 2.  A boolean type called "bit" isn't a syntactical oddity?  Walter already
sort
 of endorsed pragmas.  His words:  "That might work."  I don't like pragmas
 either, but switches and compiler directives (what do you call
 them--meta-instructions?) work fine.  That one's not my call.


I think Walter's comment was more with respect to elegantly dealing with 
future changes to the core language and code written for a particular 
revision of the language.

A pragma feels right for this purpose, since it's more or less the 
perfect textbook example of an annotation as opposed to actually 
carrying meaning on its own. (I'll be the first to admit that my opinion 
on this matter is largely based on intuition)


     * BDFL: Benevolent Dictator For Life.  (see also: Guido van Rossum 
of Python fame)

  -- andy
Jun 26 2004
prev sibling next sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Rex Couture" <Rex_member pathlink.com> wrote in message
news:cbiekf$mel$1 digitaldaemon.com...

 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.


You're wasting your breath. There will not be a strongly typed boolean in 1.0
Jun 25 2004
prev sibling parent Derek <derek psyc.ward> writes:
On Sat, 26 Jun 2004 00:05:35 +0000 (UTC), 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.


Because the argument has been thrashed about for ages with many views
coming out. The final position (so far) is that Walter is not going to
change anything, re Bool, no matter how hard others cry for change. Its not
in his philosophy so why waste our time again.

I hope I'm very wrong.
-- 
Derek
Melbourne, Australia
Jun 25 2004
prev sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"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
Jun 24 2004
prev sibling parent Arcane Jill <Arcane_member pathlink.com> writes:
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

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....?
Jun 24 2004
prev sibling parent "me" <memsom interalpha.co.uk> writes:
 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
Jun 24 2004
prev sibling parent Alex Besogonov <Alex_member pathlink.com> writes:
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!
Jun 24 2004
prev sibling next sibling parent reply Andy Friesen <andy ikagames.com> writes:
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
Jun 24 2004
parent Alex Besogonov <Alex_member pathlink.com> writes:
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!
Jun 24 2004
prev sibling next sibling parent reply "Zz" <Zz Zz.com> writes:
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!
Jun 24 2004
parent reply Alex Besogonov <Alex_member pathlink.com> writes:
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!
Jun 24 2004
parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
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!
Jun 24 2004
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Jun 24 2004
parent Alex Besogonov <Alex_member pathlink.com> writes:
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!
Jun 24 2004
prev sibling next sibling parent reply "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
"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
Jun 24 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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.
Jun 24 2004
parent "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
"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:-)
Jun 24 2004
prev sibling parent reply Alex Besogonov <Alex_member pathlink.com> writes:
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!
Jun 24 2004
parent "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
"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
Jun 25 2004
prev sibling next sibling parent reply "=?iso-8859-1?Q?Robert_M._M=FCnch?=" <robert.muench robertmuench.de> writes:
On Thu, 24 Jun 2004 06:57:07 +0000 (UTC), Alex Besogonov  
<Alex_member pathlink.com> wrote:


 Currently, as far as I understand, there is no standard on name mangling


Hi, shouldn't this be standarized? I think that's on of the bad decision  
in C++ implementaitons. You always need speical compiled libs for your  
compiler. A lot of problems araised in my problems with all the different  
mangeling schemes... And it's quite easy to avoid... Robert
Jun 27 2004
parent "Alex Besogonov" <alexy izh.com> writes:
Good <time-of-day>!

"Robert M. Münch" <robert.muench robertmuench.de> wrote in message
news:opr98z3hgoheztw6 news.digitalmars.com...

 Currently, as far as I understand, there is no standard on name mangling


 Hi, shouldn't this be standarized? I think that's on of the bad decision
 in C++ implementaitons. You always need speical compiled libs for your
 compiler. A lot of problems araised in my problems with all the different
 mangeling schemes... And it's quite easy to avoid...


It's the whole can of worms.... You'll need support for GC interoperability,
and now I don't see easy ways to interoperate between different types
of GC.

I don't think we'll need such a standard for D 1.0

With respect,
            Alex Besogonov (alexy izh.com)
Jun 27 2004
prev sibling parent %u <casper18_830603 yahoo.com> writes:
can you plz help me doing a program using a TERMINATE STAY
RESIDENT(TSR)....
just only simple program were doing just only indicate our name in the
4 corner of our monitor while we enter the invalid letter or any
keyboard that we press..... plz help me plz we need to submit  it next
week........ TNX 4 reading my message wish and pray that you can help me
doing this program........BYE tnx..........
by the way im RYAN LIM frm  BAUANG, LA UNION a 4th YEAR colleges taking
up a computer engineering........wish you can help me doing this TSR
bye wish you reply as soon as possible if you can.......we use a dos
program a MASM or TASM....
Sep 18 2006