June 26, 2004 Re: D compilers compatibility | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Rex Couture | 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 | |||
Permalink
ReplyJune 26, 2004 printf (was Re: D compilers compatibility) | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Walter | In article <cbkapi$8nj$1@digitaldaemon.com>, Walter says... > >> # printf("a = %2, b = %1\n", b, a); >> >> 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. # // Given... # char[] color; # char[] building; # char[] description; # # // Initialization for English: # color = "red"; # building = "house"; # description = "The %1 %2"; # # // Initialization for French: # color = "rouge"; # building = "maison"; # description = "La %2 %1"; Now, you can see that the statement: # printf(description, color, building); will print the correctly localized text for both languages - but only IF we can access the printf arguments by random access. Jill | |||
June 26, 2004 Re: D compilers compatibility | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Walter | 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 | |||
June 27, 2004 Re: D compilers compatibility | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Arcane Jill | "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. | |||
June 27, 2004 printf | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Walter | 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.
| |||
June 27, 2004 Re: D compilers compatibility | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Andy Friesen | 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. | |||
June 27, 2004 Re: D compilers compatibility | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Rex Couture | 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 | |||
June 27, 2004 Re: printf | ||||
|---|---|---|---|---|
| ||||
Posted in reply to @(write-my-first-name-here).info | 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. | |||
June 27, 2004 Re: D compilers compatibility | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Alex Besogonov | 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
| |||
June 27, 2004 Re: D compilers compatibility | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Robert M. Münch | 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) | |||
Copyright © 1999-2021 by the D Language Foundation