- Haskell-i18n - Haskell.org

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

Re: [Haskell-i18n] Unicode in source
by Marcin 'Qrczak' Kowalczyk 26 Aug '02

26 Aug '02

Fri, 23 Aug 2002 10:56:43 -0400, Dylan Thurston <dpt(a)petunia.bostoncoop.net> pisze: > (I'd go further and require that the leading white-space always be > identical, not just get you to the same column. Tabs are not always > equal to 8 spaces...) Choosing a non-standard tab width is evil. They should be 8 spaces always and life would be a bit simpler. -- __("< Marcin Kowalczyk \__/ qrczak(a)knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

4 3

Re: [Haskell-i18n] Unicode in source
by Marcin 'Qrczak' Kowalczyk 25 Aug '02

25 Aug '02

Sat, 24 Aug 2002 11:21:40 -0700, Ashley Yakeley <ashley(a)semantic.org> pisze: > I disagree, a tab is not an encoding for a run of spaces. It's an > entirely separate kind of whitespace. I use tabs to indent my code, 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). OCaml usually uses the indent of 2 (it has a bit more indents than Haskell because case alternatives etc. are delimited by |, usually put at the left). 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. -- __("< Marcin Kowalczyk \__/ qrczak(a)knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

1 0

Re: [Haskell-i18n] Unicode in source
by Ashley Yakeley 24 Aug '02

24 Aug '02

At 2002-08-24 07:00, Alastair Reid wrote: >I don't think this discussion has any real bearing on >internationalization and nothing at all to do with what level of >indentation makes your code look nice. It is only about how you >_encode_ sequences of spaces in files. I disagree, a tab is not an encoding for a run of spaces. It's an entirely separate kind of whitespace. I use tabs to indent my code, and in fact this is to me more important than the width setting. It makes it very easy to raise and lower the indentation level and it guarantees that the blocks line up nicely. My indentation width is "one tab", not any number of spaces. I do sometimes use additional single spaces, usually when I have to break a line, but never for braced blocks. For about 95% of my code it makes little difference what setting you make your tabs, you'll just see the indentation rather heavily pronounced if you set it to 8. Occasionally I have some things that line up only for 4-tabs, sorry, but it's my code and you'll just have to deal with it. It should only be marginally annoying anyway. -- Ashley Yakeley, Seattle WA

1 0

Re: [Haskell-i18n] Unicode in source
by Ashley Yakeley 24 Aug '02

24 Aug '02

At 2002-08-23 19:47, Glynn Clements wrote: > To determine the column number, assume a fixed-width font with this > tab convention: tab stops are 8 characters apart, and a tab > character causes the insertion of enough spaces to align the current > position with the next tab stop. > >If you want your code to compile properly, it will have to "look" >right to a compiler which has tab stops every eight columns. Oh I don't use layout, so this makes no difference to me. My blocks are explicitly and unambiguously marked with braces, and my declarations separated with semicolons. And my tabs are set to four, because the code looks nicer that way. And now with internationalisation, we're having all this trouble because the "column number" notion necessary for layout just doesn't work very well with such things as multiple scripts, special halfwidth forms, composed vs. decomposed characters, different-sized spaces etc. I think in this case some simple "90%" solution will be adequate, but my own preference is to avoid it altogether. -- Ashley Yakeley, Seattle WA

2 1