New mailing list: haskell-i18n (was: RE: Yet more text pedantry)
tis 2002-08-13 klockan 11.57 skrev Simon Marlow: Can't we make a mailing list for these issues? [EMAIL PROTECTED] is my proposal, who can create such a list? I'll set up the list. Anyone wish to volunteer to moderate it? Does it have to be moderated? This will make things progress more slowly. Not necessarily fully moderated, but there needs to be a list admin ([EMAIL PROTECTED]) who is responsible for dealing with the messages that Mailman flags for auto-moderation, and user queries, etc. I'm already the admin for way too many lists on haskell.org, otherwise I'd volunteer myself :-) Thanks everyone who volunteered to admin the list. We now have an admin, and the haskell-i18n list has been created. Please go to http://www.haskell.org/mailman/listinfo/haskell-i18n to join. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Yet more text pedantry
Can't we make a mailing list for these issues? [EMAIL PROTECTED] is my proposal, who can create such a list? I'll set up the list. Anyone wish to volunteer to moderate it? Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Yet more text pedantry
tis 2002-08-13 klockan 11.57 skrev Simon Marlow: Can't we make a mailing list for these issues? [EMAIL PROTECTED] is my proposal, who can create such a list? I'll set up the list. Anyone wish to volunteer to moderate it? Does it have to be moderated? This will make things progress more slowly. Regards, Martin -- Martin Norbäck [EMAIL PROTECTED] Kapplandsgatan 40 +46 (0)708 26 33 60 S-414 78 GÖTEBORG http://www.dtek.chalmers.se/~d95mback/ SWEDEN OpenPGP ID: 3FA8580B signature.asc Description: PGP signature
RE: Yet more text pedantry
tis 2002-08-13 klockan 11.57 skrev Simon Marlow: Can't we make a mailing list for these issues? [EMAIL PROTECTED] is my proposal, who can create such a list? I'll set up the list. Anyone wish to volunteer to moderate it? Does it have to be moderated? This will make things progress more slowly. Not necessarily fully moderated, but there needs to be a list admin ([EMAIL PROTECTED]) who is responsible for dealing with the messages that Mailman flags for auto-moderation, and user queries, etc. I'm already the admin for way too many lists on haskell.org, otherwise I'd volunteer myself :-) Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Yet more text pedantry
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? [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Kapplandsgatan 40 +46 (0)708 26 33 60 S-414 78 GÖTEBORG http://www.dtek.chalmers.se/~d95mback/ SWEDEN OpenPGP ID: 3FA8580B signature.asc Description: PGP signature
Re: Yet more text pedantry
Fri, 09 Aug 2002 15:24:55 +0200, George Russell [EMAIL PROTECTED] pisze: 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. Only because of a messy history. No need to transfer the silly concept of signed and unsigned characters into Haskell, Haskell doesn't need to sit on top of C - C is just a language. IMHO the best way to view binary file data is Word8. Network protocols and file formats are expressed in terms of octets, so programs which want to cooperate with the rest of the world must be somehow able to read/write them anyway. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^http://qrnik.knm.org.pl/~qrczak/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Yet more text pedantry
George Russell [EMAIL PROTECTED] 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 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Yet more text pedantry
Ketil Z. Malde wrote: George Russell [EMAIL PROTECTED] 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. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Yet more text pedantry
George Russell [EMAIL PROTECTED] 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 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Yet more text pedantry
Ketil Z. Malde wrote: [snip] and on Solaris the default representation of a characters is as a signed quantity. Why should we care? [snip] 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. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Yet more text pedantry
George Russell [EMAIL PROTECTED] 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 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Yet more text pedantry
Ketil Z Malde wrote: George Russell [EMAIL PROTECTED] 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. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Yet more text pedantry
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 [EMAIL PROTECTED] Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
