October 2001 - Haskell-Cafe

Closed Classes
by Eric Allen Wohlstadter 12 Oct '01

12 Oct '01

Are there any plans to add closed classes as a hugs extension? This was described in the paper: Object-Oriented Style Overloading for Haskell, Mark Shields and Simon Peyton Jones; BABEL workshop '01. Eric Wohlstadter

1 0

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

12 Oct '01

At 2001-10-09 11:55, Mark Carroll wrote: >What is the rationale for when Haskell demands a "=" and when it demands >a "->"? What? Example please... -- Ashley Yakeley, Seattle WA

7 10

Re: performUnsafeIO
by Ashley Yakeley 11 Oct '01

11 Oct '01

At 2001-10-11 11:55, Sebastian Schulz wrote: >I need to extract an IO String to String. No!!! Don't do it. Make the final result of your Haskell calculation be an "IO String". Then when you have a look at it, it will be automatically executed and you'll see the String. -- Ashley Yakeley, Seattle WA

1 0

help for exercise 4.10
by rock dwan 11 Oct '01

11 Oct '01

Iam having some difficulties doing exercise 4.10 from craft of functional programming book second edition ..is their a possible solution for this ? _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

2 1

performUnsafeIO
by Sebastian Schulz 11 Oct '01

11 Oct '01

hi. I need to extract an IO String to String. Remembering some function like 'performUnsafeIO :: IO a -> a', I searched the hugs libs, but without a match. Does a function like this still exists? Or how can I transform IO a to a? regards seb

3 2

Re: Reasons behind the "one instance per type" limitation
by Ashley Yakeley 10 Oct '01

10 Oct '01

At 2001-10-08 09:27, Diego Dainese wrote: >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? It's so that the members of the class are unambiguous. -- class C t where foo :: t -> Integer instance C Bool where foo _ = 3; instance C Bool where foo _ = 5; ambiguous = foo True; -- GHC has a flag that will turn the rule off. -- Ashley Yakeley, Seattle WA

4 4

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