- Haskell-Cafe - Haskell.org

Re: = vs ->
by Ashley Yakeley 10 Oct '01

10 Oct '01

At 2001-10-09 17:36, Mark Carroll wrote: >So, for instance, how come function definitions and guards use "=" but >lambdas and cases use "->"? It's like this: f x = fx f = \x -> fx f :: X -> FX f x = case x of x' -> fx' x'' -> fx'' Make sense? -- Ashley Yakeley, Seattle WA

1 0

Opsss... Sorry (SuSE 7.3)
by Jorge Adriano 09 Oct '01

09 Oct '01

I just accidently sent a mail written in portuguese about SuSE 7.3. I'm really sorry, it will not happen again. My apologies J.A.

1 0

SuSE 7.3
by Jorge Adriano 09 Oct '01

09 Oct '01

Está para sair a 22 de Outubro... até eu estou a ficar surpreendido com a evolução destes tipos. Qd penso do 1o Linux que instalei (à cerca de dois anos? - andava eu no 4o ano) sinto-me como aquelas velhas que dizem "eu ainda sou do tempo...", err... em que tinha de andar a alterar XF86Config à unha para configurar a resolução default do monitor (Lembras-te Canelas? :) De instalação para instalação a distribuição da SuSE tem ficado mais fácil de instalar e configurar, e até mais bonita. O Kernel tem-se desenvolvido bastante bem e as Desktops nem se fala. Tudo junto dá um sistema excelente. Eles tentam passar a ideia de que a distribuição é excelente para empresas, assim como familias comuns... e se há algum tempo tinha as minhas reserva, agora começo a achar que isso já não é bem assim. Vamos lá ver no que é que dá o Star Office 6, ou como (a mais longo prazo) evoluirá o KOffice - já para não falar do Hancom Office parece espetacular (mas esse é comercial) http://www.suse.com/us/products/suse_linux/i386/new_features.html http://www.suse.com/us/products/suse_linux/i386/games.html :) J.A.

1 0

RE: Unicode support
by Karlsson Kent - keka 09 Oct '01

09 Oct '01

> -----Original Message----- > From: Ketil Malde [mailto:ketil@ii.uib.no] ... > > But as I said: they will not go away now, they are too > firmly established. > > Yep. But it appears that the "right" choice for external encoding > scheme would be UTF-8. You're free to use any one of UTF-8, UTF-16(BE/LE), or UTF-32(BE/LE). And you should be prepared for those encodings from anyone else. In some cases, like e-mail, only UTF-8 (unless encoded by base64) can be used for Unicode. > >> When not limited to ASCII, at least it avoids zero bytes and other > >> potential problems. UTF-16 will among other things, be full of > >> NULLs. > > > Yes, and so what? > > So, I can use it for file names, Millions of people do already, including me. Most of them don't even know about it. (The file system must be made for that, of course, but at least two (commonly used) file system use UTF-16 for *all* [long] file names: NTFS and HFS+. There is another file system, UFS, that uses UTF-8, with the names in normal form D(!), for all file names. (If the *standard* C file API is used, some kind of conversion is triggered.) Those file systems got it right, many other file systems are at a loss when it comes to even that simple level of I18N, rendering non-pure-ASCII file names essentially useless, or at least unreliable.) > in regular expressions, If the system interpreting the RE is UTF-16 enabled, yes, of course. > and in > whatever legacy No: in modern systems. One of the side effects of the popularity of XML is that support for both UTF-8 and UTF-16 (also as external encodings) is growing... B.t.w. Java source code can be in UTF-8 or in UTF-16, as well as in legacy encodings. Unfortunately the compiler has to be steered via a command line parameter, while having the source files self declare their encoding would be much better (compare XML). > applications that expect textual data. > > So will a file filled with image data, video clips, or plainly a > > list of raw integers dumped to file (not formatted as strings). > > But none of these pretend to be text! How is that relevant? If you're going to do anything "higher-level" with text, you have to know the encoding, otherwise you'll get lots of more or less hidden bugs. Have you ever had any experience with any of the legacy "multibyte" encodings used for Chinese/Japanese/etc.? In many of them, if you hit a byte that might be an ASCII letter, it need not be that at all, just a second byte component in the representation of a non-ASCII character. If you think every "A" byte is an "A" (an interpret them in some special way, say a (part of a) command name), you're in trouble! Often hard-to-find trouble. No-one that argues that one can take text in any "ASCII extension" and look at the (apparent) ASCII only (and everything else to be in some arbitrary extension, never affecting the processing) seems to be aware of the details of those encodings. B.t.w. video clips (and images) can and do have Unicode (UTF-16?) texts as components (e.g. subtitles). > > True. But implementing normalisation, or case mapping for > that matter, > > is non-trivial too. In practice, the additional complexity with > > UTF-16 seems small. > > All right, but if there are no real advantages, why bother? Efficiency (and backwards compatibility) is claimed from people who work much more "in the trenches" with this than I do. And I have no quarrel with that. Kind regards /kent k

1 0

= vs ->
by Mark Carroll 09 Oct '01

09 Oct '01

What is the rationale for when Haskell demands a "=" and when it demands a "->"? Ideas that occur to me are: (a) The distinction helps the parser a lot (b) There's a semantic difference that the language's grammar is trying to express that isn't obvious to me -- Mark

1 0

Re: Unicode support
by Ketil Malde 09 Oct '01

09 Oct '01

[Posted to haskell-cafe, since it's getting quite off topic] "Kent Karlsson" <kentk(a)md.chalmers.se> writes: >>> for a long time. 16 bit unicode should be gotten rid of, being the worst >>> of both worlds, non backwards compatable with ascii, endianness issues >>> and no constant length encoding.... utf8 externally and utf32 when >>> worknig with individual characters is the way to go. >> I totally agree with you. > Now, what are your technical arguments for this position? > (B.t.w., UTF-16 isn't going to go away, it's very firmly established.) What's wrong with the ones already mentioned? You have endianness issues, and you need to explicitly type text files or insert BOMs. An UTF-8 stream limited to 7-bit ASCII simply is that ASCII stream. When not limited to ASCII, at least it avoids zero bytes and other potential problems. UTF-16 will among other things, be full of NULLs. I can understand UCS-2 looking attractive when it looked like a fixed-length encoding, but that no longer applies. > So it is not surprising that most people involved do not consider > UTF-16 a bad idea. The extra complexity is minimal, and further > surfaces rarely. But it needs to be there. It will introduce larger programs, more bugs, lower efficiency. > BMP characters are still (relatively) easy to process, and it saves > memory space and cache misses when large amounts of text data > is processed (e.g. databases). I couldn't find anything about the relative efficiencies of UTF-8 and UTF-16 on various languages. Do you have any pointers? From a Scandinavian POV, (using ASCII plus a handful of extra characters) UTF-8 should be a big win, but I'm sure there are counter examples. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

2 2

Reasons behind the "one instance per type" limitation
by Diego Dainese 08 Oct '01

08 Oct '01

Hi, what are the reasons behind the rule stating that a type must not be declared as an instance of a particular class, more than once in the program? Thanks in advance, -- Diego To reply remove the 2 `x' from the address.

1 0

Re: UniCode
by Dylan Thurston 08 Oct '01

08 Oct '01

On Fri, Oct 05, 2001 at 11:23:50PM +1000, Andrew J Bromage wrote: > G'day all. > > On Fri, Oct 05, 2001 at 02:29:51AM -0700, Krasimir Angelov wrote: > > > Why Char is 32 bit. UniCode characters is 16 bit. > > It's not quite as simple as that. There is a set of one million > (more correctly, 1M) Unicode characters which are only accessible > using surrogate pairs (i.e. two UTF-16 codes). There are currently > none of these codes assigned, and when they are, they'll be extremely > rare. So rare, in fact, that the cost of strings taking up twice the > space that the currently do simply isn't worth the cost. This is no longer true, as of Unicode 3.1. Almost half of all characters currently assigned are outside of the BMP (i.e., require surrogate pairs in the UTF-16 encoding), including many Chinese characters. In current usage, these characters probably occur mainly in names, and are rare, but obviously important for the people involved. > However, you still need to be able to handle them. I don't know what > the "official" Haskell reasoning is (it may have more to do with word > size than Unicode semantics), but it makes sense to me to store single > characters in UTF-32 but strings in a more compressed format (UTF-8 or > UTF-16). Haskell already stores strings as lists of characters, so I see no advantage to anything other than UTF-32, since they'll take up a full machine word in any case. (Right?) There's even plenty of room for tags if any implementations want to use it. > See also: http://www.unicode.org/unicode/faq/utf_bom.html > > It just goes to show that strings are not merely arrays of characters > like some languages would have you believe. Right. In Unicode, the concept of a "character" is not really so useful; most functions that traditionally operate on characters (e.g., uppercase or display-width) fundamentally need to operate on strings. (This is due to properties of particular languages, not any design flaw of Unicode.) Err, this raises some questions as to just what the "Char" module from the standard library is supposed to do. Most of the functions are just not well-defined: isAscii, isLatin1 - OK isControl - I don't know about this. isPrint - Dubious. Is a non-spacing accent a printable character? isSpace - OK, by the comment in the report: "The isSpace function recognizes only white characters in the Latin-1 range". isUpper, isLower - Maybe OK. toUpper, toLower - Not OK. There are cases where upper casing a character yields two characters. etc. Any program using this library is bound to get confused on Unicode strings. Even before Unicode, there is much functionality missing; for instance, I don't see any way to compare strings using a localized order. Is anyone working on honest support for Unicode, in the form of a real Unicode library with an interface at the correct level? Best, Dylan Thurston

4 4

Re: Hashtable ADT
by John Hughes 06 Oct '01

06 Oct '01

> As I understand from the concepts of Functional Programming, it is not > possible to implement a Hashtable ADT in Haskell language, where one can > insert, and access values in O(1) complexity. It has to be implemented > with an external language. I don't know if it can be done in standard Haskell 98, but it can certainly be done using extensions provided by most or all implementations (IORef, IOArray). There is no need of using an external language, although it will not fit well the functional style. Better is to use the ST monad (which provides creation, reading, and writing of arrays and references in constant time). Side-effects in the ST monad can be encapsulated using runST :: (forall s. ST s a) -> a You give it a computation using updateable state as an argument, a "state thread", and it gives you the result as a pure value. The "forall s" is a typing trick which prevents an encapsulated state thread from referring to references belonging to a different state thread. Using this you can, for example, create a function share :: Hashable a => [a] -> [a] which takes a list of hashable values, and returns an equal list, in which equal values are always represented by the same pointer. Internally, there's a hash table which lets you map each element of the input to a unique representative. You could compose share with a lexical analyser, for example, to share all the copies of the same identifier. Encapsulated stateful operations like this fit very nicely with the functional style! Take a look at "State in Haskell", John Launchbury and Simon Peyton Jones, http://www.cse.ogi.edu/~jl/Papers/stateThreads.ps which explains all of this at length. John Hughes

1 0

Re: Hashtable ADT
by Marcin 'Qrczak' Kowalczyk 06 Oct '01

06 Oct '01

Sat, 6 Oct 2001 14:10:05 +0300, Cagdas Ozgenc <co19(a)cornell.edu> pisze: > As I understand from the concepts of Functional Programming, it is not > possible to implement a Hashtable ADT in Haskell language, where one can > insert, and access values in O(1) complexity. It has to be implemented > with an external language. I don't know if it can be done in standard Haskell 98, but it can certainly be done using extensions provided by most or all implementations (IORef, IOArray). There is no need of using an external language, although it will not fit well the functional style. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0