August 2002 - Haskell-i18n

SourceForge Project Active
by Ashley Yakeley 05 Sep '02

05 Sep '02

A SourceForge project for the internationalisation effort is active at <http://sourceforge.net/projects/haskell-i18n/> I've added my Unicode character properties code. Check it out (cvs co). Note that the build process grabs about 850K of data files from the Unicode website with wget. Also you'll need m4 and ghc installed. Also compiling some of the files takes forever. If you have haddock installed you make HTML documentation with 'make doc'. Feel free to contribute more useful functionality, such as encodings. Let me know if you want to be added as a developer. I've been making everyone an admin, I don't know if that's a good idea or not... -- Ashley Yakeley, Seattle WA

9 15

Re: [Haskell-i18n] SourceForge Project Active
by Ashley Yakeley 30 Aug '02

30 Aug '02

At 2002-08-29 01:22, Martin Norbäck wrote: >Nice. Who will supply good UTF-8 code? I have some at >http://www.dtek.chalmers.se/~d95mback/gettext/ but it is not in good >shape. I have encoding and monadic stream processing decoding in HBase, but it will need to be adapted to the regular Haskell Prelude... >Another thing, why not use the hierarchy even more, and put the >sub-modules of Text.Unicode in Text.Unicode.UnicodeDefs and so on? I wasn't sure exactly where, so I just put them in Text for the time being. Perhaps Text.Properties.* for character properties? Is anyone bothered by the size of the library? It's 16M on my MacOS X, of which 10M is character names. libHSbase.a is only 14M. -- Ashley Yakeley, Seattle WA

1 0

Re: [Haskell-i18n] SourceForge Project Active
by Ashley Yakeley 30 Aug '02

30 Aug '02

At 2002-08-29 03:01, Jens Petersen wrote: >However since it isn't possible to checkout the toplevel >directory: Do "co ." to check out the root module. -- Ashley Yakeley, Seattle WA

1 0

Re: [Haskell-i18n] SourceForge Project Active
by Marcin 'Qrczak' Kowalczyk 29 Aug '02

29 Aug '02

Thu, 29 Aug 2002 10:15:32 +0100, Simon Marlow <simonmar(a)microsoft.com> pisze: > I think we should start with lazy steam encoders/decoders, and later > add monadic versions and ones that work with arrays. For GHC, we'll > want some really low-level ones that work on ByteArray# for use in > the I/O libraries, but that can come later (maybe use libiconv?). Have a look at http://sf.net/projects/qforeign I have some recoding machinery (I don't like it but couldn't think how to to it better) including iconv, and Unicode character properties (lib/, unidata/, charsets/). It rotted a bit, I had unresolved issues with packaging for newer ghcs. -- __("< Marcin Kowalczyk \__/ qrczak(a)knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

1 0

RE: [Haskell-i18n] SourceForge Project Active
by Simon Marlow 29 Aug '02

29 Aug '02

> Where should a UTF-8 module be put? Text.UTF8? See http://www.haskell.org/~simonmar/lib-hierarchy.html (I really ought to put this in the repository somewhere). Text encodings are in Text.Encoding at the moment. I think we should start with lazy steam encoders/decoders, and later add monadic versions and ones that work with arrays. For GHC, we'll want some really low-level ones that work on ByteArray# for use in the I/O libraries, but that can come later (maybe use libiconv?). Cheers, SImon

1 0

Re: Tabs
by Marcin 'Qrczak' Kowalczyk 28 Aug '02

28 Aug '02

Sun, 25 Aug 2002 17:31:21 -0700, Ashley Yakeley <ashley(a)semantic.org> pisze: > Two opposing viewpoints, that you should not use tabs in source code at > all -- > <http://adamspiers.org/computing/why_no_tabs.html> > > ...and that you should tabs in source code, but only for indenting -- > <http://www.derkarl.org/why_to_tabs.html> There are also two viewpoints about how to use tabs, if at all: 1. Tabs are always 8, use whatever indent you like (by using as much tabs as fit and then spaces). 2. Indent is always one tab, the width is unspecified. An interesting fact is that each of these viewpoints works fine when used consistently, but they conflict wich each other if mixed. That's why people won't universally agree on that: for everybody his method works fine internally, it becomes wrong when the other method comes. > Linus Torvalds has another view, for his Unix kernel "Linux" source: > > "Tabs are 8 characters, and thus indentations are also 8 characters." Unfortunately C doesn't use as much nesting as functional languages so this view is not well suited for Haskell and similar languages. -- __("< Marcin Kowalczyk \__/ qrczak(a)knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

2 1

SF Project
by Ashley Yakeley 28 Aug '02

28 Aug '02

Sorry for the delay. I have submitted SourceForge project request. Here is the "Project Purpose and Summarization" I entered. The Haskell language standards are undergoing an internationalisation effort. This will be a place for the Haskell Internationalisation Working Group to work on Haskell code that may eventually become part of the standard Haskell libraries. Examples include Unicode character property functions, UTF-8 and other encoding and decoding functions, and associated documentation. Archives for the Internationalisation WG mailing list can be found at: <http://www.haskell.org/pipermail/haskell-i18n/> I hope this is OK. In any case it's too late to change it now... The "Unix name" for the project is 'haskell-i18n', the same as this mailing list. The license for the project is BSD. Turnaround is usually around 24 hours, and then I'll add the names I've been given (norpan, pesco) and anyone else who has stuff to contribute. Like all SF projects, everything in the repository will be available to everyone by anonymous CVS. -- Ashley Yakeley, Seattle WA

1 0

RE: [Haskell-i18n] Unicode in source
by Sven Moritz Hallberg 26 Aug '02

26 Aug '02

On Mon, 2002-08-26 at 11:33, Simon Marlow wrote: > Allowing characters to span more than one column wouldn't break the > layout rule, as long as the character to column mapping is generally > agreed upon across editors and locales. (I think we established that > this is not necessarily the always case, although in practice it should > be). I guess we can just refer to the Unicode standard for the mapping? > Requiring a newline before a new layout context would break *a lot* of > code. You can't write 'let x = 42 in x + 1' for example. Sure, a > refinement could be made to allow these kind of things, but this will > serve to make the layout rule more complex, rather than less. So to > extend gracefully while keeping backwards compatibility, I propose: > > - There be a fixed character->column mapping I agree. > - Tab stops are every 8 columns This appears to be the only viable solution if we don't want to force layout blocks to start after newlines, your argument against which I accept. > - We recommend that programmers avoid using indentation levels > which depend on the widths of non-space characters. > > Obeying the third requirement means that your code will look fine in a > proportional font. The compiler could warn about violations quite > easily. Note that it is ok to write 'let x = 42 in x + 1', because the > meaning of the code doesn't depend on the actual indentation level of > the first 'x'. Good point, I'd be happy with it. Regards, Sven Moritz

2 1

RE: [Haskell-i18n] Unicode in source
by Ashley Yakeley 26 Aug '02

26 Aug '02

At 2002-08-26 02:33, Simon Marlow wrote: >Allowing characters to span more than one column wouldn't break the >layout rule, as long as the character to column mapping is generally >agreed upon across editors and locales. Heh. I think this is above and beyond the call of duty. AFAIK Unicode has little to say on such things as "fixed width". How many columns do you think characters of right-to-left scripts such as Hebrew and Arabic take up? At 2002-08-26 03:19, Sven Moritz Hallberg wrote: >I guess we can just refer to the Unicode standard for the mapping? As far as I know, no. I recommend going for a simple rule, such as counting "Letter" (and other) codepoints as one, and "Mark" codepoints as zero. This is "General Category", which unicode does have tables for. -- Ashley Yakeley, Seattle WA

1 0

Tabs
by Ashley Yakeley 26 Aug '02

26 Aug '02

At 2002-08-25 14:42, Marcin 'Qrczak' Kowalczyk wrote: >Tabs are poorly suited for indenting because a tab has width 8 and >this is at least twice too much for an indent unit for a functional >language (i.e. lots of nested expressions). Tabs are well suited for indenting because they're convenient and make the blocks line up easily. And you can set the tab width to whatever you want. Two opposing viewpoints, that you should not use tabs in source code at all -- <http://adamspiers.org/computing/why_no_tabs.html> ...and that you should tabs in source code, but only for indenting -- <http://www.derkarl.org/why_to_tabs.html> Both make the point that one cannot rely on tabs being set to any particular size. I'm closer to the second viewpoint, probably I ought to be using spaces rather than tabs to make things like line comments line up. I believe using tabs for indenting and then setting that to something other than eight is a reasonably common practice in other languages. Linus Torvalds has another view, for his Unix kernel "Linux" source: "Tabs are 8 characters, and thus indentations are also 8 characters." <http://adamspiers.org/computing/Linus-Kernel-CodingStyle> >Tabs must have a consistent width, because otherwise mixing tabs with >spaces (which will always happen from time to time when several people >are editing the same code) has fatal consequences. Not in my Haskell! This is consequence of using layout, which I eschew in my own code. When you use braces and semicolons, the issue is much the same as for C or C++ or Java. I think I make about the same number of indentations in Haskell as I do in those languages, for instance. Obviously, like everyone else when working on someone else's code I follow their style. For layout, the language designers probably need to fix the tab width to something, and eight is the standard. So everyone has to use eight when using layout, or else not use tabs. From this it's easy to get in a mindset of "tabs are always eight", but that doesn't really represent the variation in this setting seen in other languages. When I first wrote Haskell and discovered my code didn't compile because the language itself made picky interpretations of whitespace, I was horrified. But I understand other people like it... Fortunately I can easily avoid the issue by using braces and I don't have to learn the layout rules either. -- Ashley Yakeley, Seattle WA

3 2