June 26, 2004 Re: D compilers compatibility | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rex Couture | "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 |
June 26, 2004 Re: D compilers compatibility | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rex Couture | 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 |
June 26, 2004 Re: D compilers compatibility | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | >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.
|
June 26, 2004 Re: D compilers compatibility | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthias Becker | 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: # printf("a = %2, b = %1\n", b, a); would print the right values in the right order. Also, I assume there will be also be functions like: # sprintf(out char[] r, char[] format, ...) // UTF-8 # sprintf(out wchar[] r, wchar[] format, ...) // UTF-16 # sprintf(out dchar[] r, dchar[] format, ...) // UTF-32 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 |
June 26, 2004 Re: D compilers compatibility | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Reimer | "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. |
June 26, 2004 Re: D compilers compatibility | ||||
---|---|---|---|---|
| ||||
Posted in reply to Arcane Jill | "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: > > # 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? > Also, I assume there will be also be functions like: > > # sprintf(out char[] r, char[] format, ...) // UTF-8 > # sprintf(out wchar[] r, wchar[] format, ...) // UTF-16 > # sprintf(out dchar[] r, dchar[] format, ...) // UTF-32 > > 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. |
June 26, 2004 Re: D compilers compatibility | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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:
>>
>># 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?
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
|
June 26, 2004 Re: D compilers compatibility | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter |
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:
>>
>># 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?
>
>
>>Also, I assume there will be also be functions like:
>>
>># sprintf(out char[] r, char[] format, ...) // UTF-8
>># sprintf(out wchar[] r, wchar[] format, ...) // UTF-16
>># sprintf(out dchar[] r, dchar[] format, ...) // UTF-32
>>
>>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.
>
>
|
June 26, 2004 Re: D compilers compatibility | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andy Friesen | 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. |
June 26, 2004 Re: D compilers compatibility | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Horn | "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. |
Copyright © 1999-2021 by the D Language Foundation