Dirty handle...
When tryin to remove the buffering for stdout with hSetBuffering stdout NoBuffering as part of a ghc-0.29 compiled program, running the prgram fails with Fail: I/O error: UnsupportedOperation: can't set buffering for a dirty handle What is the problem? -- Stephan Tobies, Student of Computer Science, RWTH Aachen mailto:[EMAIL PROTECTED] ## There is much pleasure to be gained from useless knowledge - B. Russel ##
Re: Haskell 1.4 and Unicode
Carl R. Witty wrote (to the Haskell mailing list): [..] The Report could give up and say that column numbers in the presence of \u escapes are explicitly implementation-defined. [..] [This] sounds pretty bad (effectively prohibiting layout in portable programs using Unicode characters); I do agree that an implementation defined rule is undesirable, but it is possible to write portable programs with the layout rule. Just make sure you only use tabs at the beginning of a line. This has a few advantages. The tab size of the editor and the implementation don't have to correspond and you can use proportional fonts (or a Unicode aware editor). Disadvantage is that the program will get longer. I don't mind this, I like white space. Cheers, Ronny Wichers Schreur
Arrays and definedness
Apologies if this is an issue which has been debated before - I'm a relative newcomer to Haskell. The specification of arrays allows for indices for which the corresponding element in the array is undefined. There are also functions which get all of the indices, elements or associations in the array. They appear (in hugs, at least) to deliver all the members of the array whether defined or not. So for example if I create an array with foo = array (1,3) [(1,"one"),(3,"three")] then indices foo is [1,2,3], and both elems foo and assocs foo blow up if I try to (say) use trace to look at the results. Perhaps it would be useful to have versions of indices, elems and assocs which deliver just the defined members, or (for elems and assocs) use Maybe's to indicate definedness. Is this sensible/desireable? -- David Elworthy ___ David Elworthy [EMAIL PROTECTED] Canon Research Centre Europe Ltd., Guildford, Surrey, UK URL: http://www.cre.canon.co.uk/ Phone: +44 1483 448844; Fax: +44 1483 448845
SV: Haskell 1.4 and Unicode
Hi! 1. I don't seem to get my messages to this list echoed back to me... (Which I consider a bug.) 2. As I tried to explain in detail in my previous message, (later) options 1 and 2 **do not make any sense**. Option 3 makes at least some sense, even though it has some problems. You could generalize option 4 to make sense too. The layout rule does not generalise well. I still think that one should not give up entirely on it. One way may be to require that "where", and other layout starters, are to have only spaces (U+0020), no-break spaces (U+00A0) and tabs (U+0009) in front of them on the same line, keeping the width rule for the tabs relative to the spaces. (I know, present Haskell programs are not written that way.) 3. (In reply to Hans Aberg (Aberg?)) The easiest way of thinking of Unicode is perhaps as a font encoding; a font using this encoding would add such things as typeface family, style, size, kerning (but Unicode probably does not have ligatures), etc., which As everyone (getting) familiar with Unicode should know, Unicode is **NOT** a font encoding. It is a CHARACTER encoding. The difference shows up mostly for 'complex scripts', such as Arabic and Devanagari (used for Hindi), but also in the processing of combining characters for 'latin'. Glyph (at a "font point") selection is based also on *neighbouring* characters. Unicode does have a number of compatability characters, but the explicit intent is that they should only be used for backwards compatability reasons. /kent k PS B.t.w. Did you know... that CR and LF should not be used in "newly produced" Unicode texts. One should use Line Separator (U+2028) and Paragraph Separator (U+2029) instead. Line Separator is the one expected to be used in program source files. -Ursprungligt meddelande- Fran: John C. Peterson [SMTP:[EMAIL PROTECTED]] Skickat: den 8 november 1997 03:25 Till: [EMAIL PROTECTED] Kopia:[EMAIL PROTECTED]; [EMAIL PROTECTED] Amne: Re: Haskell 1.4 and Unicode I had option 1 in mind when that part of the report was written. We should clarify this in the next revision. And thanks for your analysis of the problem! John
Re: SV: Haskell 1.4 and Unicode
At 12:45 +0100 97/11/10, Kent Karlsson [EMAIL PROTECTED] wrote: As everyone (getting) familiar with Unicode should know, Unicode is **NOT** a font encoding. It is a CHARACTER encoding. The difference shows up mostly for 'complex scripts', such as Arabic and Devanagari (used for Hindi), but also in the processing of combining characters for 'latin'. Glyph (at a "font point") selection is based also on *neighbouring* characters. Unicode does have a number of compatability characters, but the explicit intent is that they should only be used for backwards compatability reasons. I leave it to the experts to figure out what exactly Unicode is. I can only note that the idea of it as a character encoding thoroughly breaks down in a mathematical context. I think the safest thing is to only regard it as a set of glyphs, which are better, because ampler, than other encodings. I think figuring out the exact involved semantics of those glyphs is a highly complex issue which cannot fully be resolved. There is also a Unicode version of TeX called Omega, which can perhaps shed light on the font encoding issue for those interested. :-) B.t.w. Did you know... that CR and LF should not be used in "newly produced" Unicode texts. One should use Line Separator (U+2028) and Paragraph Separator (U+2029) instead. Line Separator is the one expected to be used in program source files. Yes. By using the Unicode Line Separator and Paragraph Separator characters, the file becomes platform independent. So oldstyle newlines should also probably only be used for compatibility reasons. Hans Aberg * Email: Hans Aberg mailto:[EMAIL PROTECTED] * AMS member listing: http://www.ams.org/cml/
SV: Haskell 1.4 and Unicode
Let me reiterate: Unicode is ***NOT*** a glyph encoding! Unicode is ***NOT*** a glyph encoding! and never will be. The same character can be displayed as a variety of glyphs, depending not only of the font/style, but also, and this is the important point, on the characters surrounding a particular instance of the character. Also, a sequence of characters can be displayed as a single glyph, and a character can be displayed as a sequence of glyphs. Which will be the case, is often font dependent. This is not something unique to Unicode. It is just that most people are used to ASCII, Latin-1 and similar, where the distinction between characters and glyphs is blurred. I would be interested in knowing why you think "the idea of it as a character encoding thoroughly breaks down in a mathematical context". Deciding what gets encoded as a character is more an international social process than a mathematical process... /kent k PS This may be getting too much into Unicode to fit for the Haskell list... In particular any argumentation regarding the last paragraph above should *not* be sent to the Haskell list, but could be sent to me personally. PPS I don't know what you mean by "semantics of glyphs". Hans Aberg wrote: I leave it to the experts to figure out what exactly Unicode is. I can only note that the idea of it as a character encoding thoroughly breaks down in a mathematical context. I think the safest thing is to only regard it as a set of glyphs, which are better, because ampler, than other encodings. I think figuring out the exact involved semantics of those glyphs is a highly complex issue which cannot fully be resolved.
