Ketil wrote (quoting Ken) [snip]
On most machines, Char will be a wrapper around Word8. (This contradicts the present language standard.)
Can you point out any machine where this is not the case? One with a Haskell implementation, or likely to have one in the future [snip] That's easy enough. On Sun/Solaris (which I use and which came out as being very popular on the Haskell survey) characters are SIGNED, so the values run from -128 to 127 and the wrapper would be not Word8 but Int8.
I think this demonstrates the perils of saying "It's safe to assume everytning is 8 bit because everything is now". Although it is the case now that the overwhelming majority of computers use data sizes based on powers of 2, it is nothing other than speculation to say that this will always be the case.
George Russell <ger@tzi.de> writes:
Ketil wrote (quoting Ken)
On most machines, Char will be a wrapper around Word8. (This contradicts the present language standard.)
Can you point out any machine where this is not the case? One with a Haskell implementation, or likely to have one in the future
That's easy enough. On Sun/Solaris (which I use and which came out as being very popular on the Haskell survey) characters are SIGNED, so the values run from -128 to 127 and the wrapper would be not Word8 but Int8.
How does the file system know the difference? I think you mean that C chars on Solaris are signed, not that files and sockets don't contain octets.
I think this demonstrates the perils of saying "It's safe to assume everything is 8 bit because everything is now".
I don't think it does so at all. There may be a peril in assuming octet IO, but frankly I think trying to anticipate different futures will only make things messy, and have a great likelyhood of turning out useless anyway. Remember, worse is better. -kzm -- If I haven't seen further, it is by standing in the footprints of giants
"Ketil Z. Malde" wrote:
George Russell <ger@tzi.de> writes:
Ketil wrote (quoting Ken)
On most machines, Char will be a wrapper around Word8. (This contradicts the present language standard.)
Can you point out any machine where this is not the case? One with a Haskell implementation, or likely to have one in the future
That's easy enough. On Sun/Solaris (which I use and which came out as being very popular on the Haskell survey) characters are SIGNED, so the values run from -128 to 127 and the wrapper would be not Word8 but Int8.
How does the file system know the difference? I think you mean that C chars on Solaris are signed, not that files and sockets don't contain octets.
Well, you can define the files to contain only directed graphs if it makes you feel any happier, but the fact is that the standard access functions return characters*, and on Solaris the default representation of a characters is as a signed quantity. *. Though in fact it must be admitted that some, such as fgetc, actually return an integer usually containing an _unsigned_ char, so that negative values can be preserved for other information. Life can be very complicated sometimes.
George Russell <ger@tzi.de> writes: >> How does the file system know the difference? I think you mean that >> C chars on Solaris are signed, not that files and sockets don't >> contain octets. > Well, you can define the files to contain only directed graphs if it makes > you feel any happier, but the fact is that the standard access functions > return characters*, What "standard access functions"? The functions found in C libraries? >From Solaris man pages, the "read" system call reads bytes into a void * buffer. I would propose that the standard access functions in *Haskell* return Word8, *regardless* of operating system or C libraries. As long as you have primitives to do octet IO, this should be straightforward, regardless of whether the OS (or other programming languages or libraries) thinks the octet is signed or not. > and on Solaris the default representation of a characters is as a > signed quantity. Why should we care? -kzm -- If I haven't seen further, it is by standing in the footprints of giants
George Russell <ger@tzi.de> writes:
"Ketil Z. Malde" wrote: [snip]
and on Solaris the default representation of a characters is as a signed quantity.
Why should we care?
If you want to talk to any C libraries or C programs which use characters, which some of us do. GNU readline and regex come to mind.
Yes, which is why we all agree on CChar for FFI purposes. But we were discussing IO, weren't we? -kzm -- If I haven't seen further, it is by standing in the footprints of giants
Ketil Z Malde wrote:
George Russell <ger@tzi.de> writes:
"Ketil Z. Malde" wrote: [snip]
and on Solaris the default representation of a characters is as a signed quantity.
Why should we care?
If you want to talk to any C libraries or C programs which use characters, which some of us do. GNU readline and regex come to mind.
Yes, which is why we all agree on CChar for FFI purposes. But we were discussing IO, weren't we?
Well for example I mentioned regex. Using a different sort of char will potentially break regex, since it means the meaning of a range of characters [A..B] will change if A and B have different signs. So either RegexString will have to do complicated transformations of the regular expression string to fix this (you will need to buy Simon Marlow several drinks) or else the manual will have to admit that the ordering used by RegexString differs from that used anywhere else. This is just something that comes to mind, there are probably lots of other cases where C libraries we might want to interface to provide things which depend on the order of char.
Can we stop the pedantry and have some people go off in a corner and produce a design which: 1) Solves some of the internationalization issues notably those involving unicode and locales. 2) Will work on a decent range of existing and plausible future Windows and Unix boxes. (Embedded systems, mainframes, PDAs, etc. are also worthwhile but since we would not run the full Haskell libraries on them they are of secondary importance.) That is, follow a standard spec if you can but when the spec becomes impossible to use because of some wild generalization which covers situations that will never come up, make a few assumptions based on what real systems do. 3) Can support nearly all of the current Haskell '98 libraries without change and as much as possible of the Hugs-GHC/hslibs/hierarchial libraries with slight changes. This is partly because, for all its faults, the current interface has the virtue of being simple. I envisage a veneer which implements the old interface on top of the new design. That is, the new design might expose all kinds of information about the encoding in the typesystem or through conversion functions or whatever but this complexity could be hidden behind an interface which reads and writes characters and does something plausible when it encounters UTF-32 and friends. 4) Relies on (and plays well with) Haskell'98 and approved addenda. (It's possible to meet this goal by lobbying for other common extensions to become approved addenda.) 5) Someone is going to produce a decent quality implementation for. (Talk is cheap and all that...) This is much easier now that both Hugs and GHC are working from the same source tree for libraries (with suggestions that NHC will follow suit). -- Alastair Reid alastair@reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/
fre 2002-08-09 klockan 21.46 skrev Alastair Reid:
Can we stop the pedantry and have some people go off in a corner and produce a design which [...]
I think this has gone on long enough on the Haskell mailing list, and if I wasn't interested I would probably have dropped of long ago. Looking at my original post (UTF-8 library), I never expected this much traffic :) Can't we make a mailing list for these issues? haskell-i18n@haskell.org is my proposal, who can create such a list? I'm interested in participating in a working group to solve these issues. Regards, Martin -- Martin Norbäck d95mback@dtek.chalmers.se Kapplandsgatan 40 +46 (0)708 26 33 60 S-414 78 GÖTEBORG http://www.dtek.chalmers.se/~d95mback/ SWEDEN OpenPGP ID: 3FA8580B
participants (5)
-
Alastair Reid -
George Russell -
Ketil Z Malde -
ketil＠ii.uib.no
-
Martin Norbäck