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