Re: = vs ->
On Wed, 10 Oct 2001, D. Tweed wrote: > degenerate equality you get from defining the lhs in terms of the rhs. The > -> is used whenever you've got something on the right that `leads to' to ^left > something on the left, eg ^right Being bad on these elementary terms makes using foldr, foldl, etc a bit difficult for me :-S ___cheers,_dave www.cs.bris.ac.uk/~tweed/pi.htm |tweed's law: however many computers email: [EMAIL PROTECTED] | you have, half your time is spent work tel: (0117) 954-5250 | waiting for compilations to finish. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: = vs ->
On 10 Oct 2001, Ketil Malde wrote: > Mark Carroll <[EMAIL PROTECTED]> writes: > > > On Tue, 9 Oct 2001, Ashley Yakeley wrote: > > >> At 2001-10-09 11:55, Mark Carroll wrote: > > >>> What is the rationale for when Haskell demands a "=" and when it > >>> demands a "->"? > > Okay, I can't give you anything formal, but here's my intuitive > understanding of things > > > e.g. > > > x :: Integer -> Integer > > A function "from" and Integer to an Integer. Even more obvious if you > have one more parameter: > > g :: Integer -> Integer -> Integer > > g takes an Integer and returns a function that takes an Integer and > returns an Integer. Equals-assignment would be very non-intuitive > here. As I understand it, the equals sign is used whenever the item on both sides are equal, i.e., one side can be replaced with the other without changing meaning. Of course, in the case of a function definition it's the degenerate equality you get from defining the lhs in terms of the rhs. The -> is used whenever you've got something on the right that `leads to' to something on the left, eg case x of Maybe y ->True Nothing ->False It is not the case that `Maybe y' is the same as True, so = is clearly inappropraite. Likewise for lambdas (\x->x+2 doesn't have x = x+2). It's perhaps less clear because after using functional languages for any length of time you get very used to thinking of function definitions as a restricted kind of rewrite rule, and rewrite rules may not necessarily have any connection to a notion of equality. ___cheers,_dave www.cs.bris.ac.uk/~tweed/pi.htm |tweed's law: however many computers email: [EMAIL PROTECTED] | you have, half your time is spent work tel: (0117) 954-5250 | waiting for compilations to finish. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: = vs ->
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 ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: = vs ->
Mark Carroll <[EMAIL PROTECTED]> writes: > On Tue, 9 Oct 2001, Ashley Yakeley wrote: >> At 2001-10-09 11:55, Mark Carroll wrote: >>> What is the rationale for when Haskell demands a "=" and when it >>> demands a "->"? Okay, I can't give you anything formal, but here's my intuitive understanding of things > e.g. > x :: Integer -> Integer A function "from" and Integer to an Integer. Even more obvious if you have one more parameter: g :: Integer -> Integer -> Integer g takes an Integer and returns a function that takes an Integer and returns an Integer. Equals-assignment would be very non-intuitive here. I guess the same argument goes for lambdas \x -> x*x maps *from* an x *to* its square. > x 1 = 1 > x 2 = 3 Function definitions use (=). I'm not sure I see any really compelling reason, except that it's the usual math syntax, and arrows would look weird, in particular with nullary definitions: c -> 0 > y a = > case a of > 1 -> 1 > 2 -> 3 > z a > | a == 1 = 1 > | a == 2 = 3 It seems there's a predisposition for having exactly one (=) in function definitions. Perhaps one could have had a syntax like z a = | a == 1 -> 1 | a == 2 -> 3 instead, as it'd make it more consisten with the case, but I suppose there's a reason for it being the way it is. The case statement is an expression like any other, while I suspect the guards can only be used in function definitions like your 'z' example. By the way, if you read '=' as "is assigned to", and '|' as "where" and '->' as "gives", things mostly make sense, I think. (Note that there's also the back-arrow, used to "draw from", e.g. in the IO Monad main = do x <- readFile "/etc/passwd" putStr (map crack (lines x)) or list comprehensions primes = [ p | p <- [2..], noDivides p primes] I suppose the difference from (=) assignment is reasonably clear.) Rambling on, -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: = vs ->
On Tue, 9 Oct 2001, Ashley Yakeley wrote: > 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... e.g. x :: Integer -> Integer y :: Integer -> Integer z :: Integer -> Integer x 1 = 1 x 2 = 3 y a = case a of 1 -> 1 2 -> 3 z a | a == 1 = 1 | a == 2 = 3 So, for instance, how come function definitions and guards use "=" but lambdas and cases use "->"? -- Mark ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: = vs ->
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 ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Reasons behind the "one instance per type" limitation
"Iavor S. Diatchki" wrote: > > hello, > > > Why aren't instance declarations handled by the module system like > > every other symbol, so that a module can decide when to import an > > instance declaration and when to export it? Are there technical > > difficulties with this approach? > > i beleive the reason is that instances don't have names and the > module system deals with names. on the other hand i don't think > this is a very good reason and completely agree with you that > it is a problem. i think some work is being done on introducing > named instances to Hasekll (there was a paper in the Haskell workshop > i think). This is actually quite messy. The first point that needs to be made is that instance code is invoked silently. Writing x==y invokes instance code, but there is no way to say which instance should be used, so it is important that there is precisely one instance declaration in scope for that class and type. The current definition of Haskell achieves this by insisting that there is only one such declaration on the whole progam, although earlier versions achieved it by more complex, and less convenient rules, that had the advantage that they could be checked locally, at module compile time. One could envisage other means, such as defining, by some new syntactic feature, which of the possible (named) instance declarations was to be used in a particular scope. Having different instance definitions in scope at different places can casue problems, as code would just use whichever was in scope where it was invoked. This is like the dynamic scope rules of early Lisp, which is not considered good design. An alternative is to treat instances as part of the static environment at declaration time, and include them in closures when functions are passed around or exported. This ensures that a named function always uses the same instance code for the same type, but still has problems. In a language with referential transparency, one should be able to replace a function call by its body code, with substitution of arguments, (I'm assuming top-level functions with no global variables). Instances behave like global variables, so calling an imported function which brings its instances with it will in general give different results from substitution of body code for the function, and getting whichever instance is in scope at the point of call. Personally, I don't like this prospect. --brian ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Opsss... Sorry (SuSE 7.3)
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. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
SuSE 7.3
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. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: Unicode support
Title: RE: Unicode support > -Original Message- > From: Ketil Malde [mailto:[EMAIL PROTECTED]] ... > > 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
= vs ->
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 ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Reasons behind the "one instance per type" limitation
hello, > Why aren't instance declarations handled by the module system like > every other symbol, so that a module can decide when to import an > instance declaration and when to export it? Are there technical > difficulties with this approach? i beleive the reason is that instances don't have names and the module system deals with names. on the other hand i don't think this is a very good reason and completely agree with you that it is a problem. i think some work is being done on introducing named instances to Hasekll (there was a paper in the Haskell workshop i think). bye iavor -- == | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | == ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Reasons behind the "one instance per type" limitation
On Mon, 8 Oct 2001 15:03:15 -0700 Ashley Yakeley <[EMAIL PROTECTED]> wrote: > 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; > -- OK, this is reasonable; but why are instance declarations always automatically exported and imported across modules boundary? This goes against information hiding. Consider this situation: > module M(T, f, g) where > data T = ... > ... > > module N where > import M > > instance Eq T where > ... now, suppose that in a second revision of the module M, an instance of Eq is made for T; even if this instance is needed for internal use only, it outlaws the instance defined in the module N. I think this problem could be a real show-stopper for big programs... Why aren't instance declarations handled by the module system like every other symbol, so that a module can decide when to import an instance declaration and when to export it? Are there technical difficulties with this approach? > GHC has a flag that will turn the rule off. I cannot find it! -- Diego To reply remove the 2 `x' from the address. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Unicode support
"Kent Karlsson" <[EMAIL PROTECTED]> writes: >> You have endianness issues, and you need to explicitly type text files >> or insert BOMs. > You have to distinguish between the encoding form (what you use internally) > and encoding scheme (externally). Good point, of course. Most of the arguments apply to the external encoding scheme, but I suppose it wasn't clear which of them we were discussing. > 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. >> 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, in regular expressions, and in whatever legacy applications that expect textual data. That may be worthless to you, but it isn't to me. > 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! > 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? >> I couldn't find anything about the relative efficiencies of UTF-8 and >> UTF-16 on various languages. > So, how big is our personal hard disk now? 3GiB? 10GiB? How many images, > mp3 files and video clips do you have? (I'm sorry, but your argument here > is getting old and stale. Don't be sorry. I'm just looking for a good argument in favor of UTF-16 instead of UTF-8, and size was the only possibility I could think of offhand. (And apparently, the Japanese are unhappy with the 50% increase UTF-8's three-byte encoding over UTF-16's two-byte one) You could run the same argument against UTF-16 vs UTF-32 as internal encoding form, memory and memory bandwidth is getting cheap these days, too, although memory is still a more expensive resource than disk. But as (I assume) the internal encoding form shouldn't matter (as) much, as it would be hidden from everybody but the Unicode library implementor. It boils down to performance, which can be measured. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Unicode support
- Original Message - From: "Ketil Malde" <[EMAIL PROTECTED]> ... > >>> 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. You have to distinguish between the encoding form (what you use internally) and encoding scheme (externally). For the encoding form, there is no endian issue, just like there is no endian issue for int internally in your program. For the encoding form there is no BOM either (or rather, it should have been removed upon reading, if the data is taken in from an external source). But I agree that the BOM (for all of the Unicode encoding schemes) and the byte order issue (for the non-UTF-8 encoding schemes; the external ones) are a pain. But as I said: they will not go away now, they are too firmly established. > An UTF-8 stream limited to 7-bit ASCII simply is that ASCII stream. Which is a large portion of the raison d'être for UTF-8. > 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 will a file filled with image data, video clips, or plainly a list of raw integers dumped to file (not formatted as strings). I know, many old utility programs choke on NULL bytes, but that's not Unicode's fault. Further, NULL (as a character) is a perfectly valid character code. Always was. > 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 True. But implementing normalisation, or case mapping for that matter, is non-trivial too. In practice, the additional complexity with UTF-16 seems small. > , lower efficiency. Debatable. > > 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. So, how big is our personal hard disk now? 3GiB? 10GiB? How many images, mp3 files and video clips do you have? (I'm sorry, but your argument here is getting old and stale. Very few worry about that aspect anymore. Except when it comes to databases stored in RAM and UTF-16 vs. UTF-32 which is guaranteed to be wasteful.) Kind regards /kent k ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Unicode support
[Posted to haskell-cafe, since it's getting quite off topic] "Kent Karlsson" <[EMAIL PROTECTED]> 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 ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
