October 2001 - Haskell

RE: <rant>Unicode stupidity</rant> (Was: Unicode support)
by Karlsson Kent - keka 24 Oct '01

24 Oct '01

> None of that "But 21 bits *is* enough". > Yeah, like 640K was enough. And countless other examples. That is not comparable. Never was. > I thought we had learned, but I was wrong... I'm especially > disheartened to hear that ISO bought into the same crap. Who's going to invent all these gazillions of as-yet-unencoded characters do you think? I'll be expecting a proposal from *you* detailing the the first few 100000 new characters or so, each with extensive and convincing documentation that they are used as the basic elements of writing in a known community. ;-) Kind regards /kent k

1 0

Re: Unicode support
by Marcin 'Qrczak' Kowalczyk 24 Oct '01

24 Oct '01

30 Sep 2001 22:28:52 +0900, Jens Petersen <petersen(a)redhat.com> pisze: > 16 bits is enough to describe the Basic Multilingual Plane > and I think 24 bits all the currently defined extended > planes. So I guess the report just refers to the BMP. In early days the Unicode Consortium was doing everything to confuse peoble about whether Unicode fits into 16 bits. It used to push the view that it's based on 16-bit units, and that pairs of units from the range U+D800..DFFF (called surrogates) can encode a million of extra characters (none of which had a more specific meaning defined at that time). I was told on the Unicode list that it was done because for some people it would be hard to accept an encoding which requires *more* than twice as much storage as 8-bit charsets. 16 bits is "only" twice as much. Unfortunately some companies, like Microsoft and Oracle, believed the "lie of Unicode marketing" and adopted the 16-bit view as the basic internal and external format, ignoring the issue of surrogates. Some time ago the Unicode Consortium slowly began switching to the point of view that abstract characters are denoted by numbers in the range U+0000..10FFFF. Storing them in 16-bit units by expressing characters below U+FFFF directly and representing others as pairs of surrogates is just a way to serialize Unicode to streams of bytes (or 16-bit words), called UTF-16. AFAIK UTF-8 was first present in ISO-10646-1. The ISO standard, although sharing actual assignments of characters to numbers with Unicode, from the beginning viewed character codes as 31-bit numbers, which can be serialized for transmission using for example UTF-8 or UTF-16. Unicode adopted UTF-8 by cutting it at the point of U+10FFFF. It also invented UTF-32 which means to just store characters in 32-bit words (endianness issues are analogous to UTF-16), but is explicitly restricted to characters below U+10FFFF, to avoid confusion with unrestricted 31-bit codes of ISO-10646-1. So now UTF-8, UTF-16 and UTF-32 are treated in parallel by Unicode. The ISO standard is going to match this and limit itself to U+10FFFF too, which in theory should end the problem about the number of characters in these standards. Unicode had to do something with this because it finally began adding characters above U+FFFF, and it would really make no sense to treat UTF-16 as the fundamental view, saying that some codes really don't represent characters but must be used in pairs, since character properties are defined in terms of real characters, not components of surrogate pairs individually. Surrogates are just a hole in the middle of the first 64k of characters, because UTF-16 can't encode them insolated. Unfortunately the 16-bit view is still widespread and there is much confusion. Companies invested money in the 16-bit Unicode and they can't simply replace it with something entirely different, so they actually begin implementing UTF-16. In practice support for surrogates could be almost non-existant in the past, but now there are actual characters allocated there, so it must be done, despite the pain of using a variable-length encoding. There are cases like Oracle which ignored surrogates and misimplemented UTF-8 by treating surrogates like other characters below U+FFFF, yet calling it UTF-8. Now instead of fixing their mistake they added the real UTF-8 under a strange name AL24UTFFSS (I'm not sure if they finally fixed the names) and are trying to push their old version as an official alternative to UTF-8. There is a very strong opposition, but they are still trying. IMHO it would have been better to not invent UTF-16 at all and use UTF-8 in parallel with UTF-32. But Unicode used to promote UTF-16 as the real Unicode, and now it causes so many threads on Unicode list to clear the confusion about the nature of characters above U+FFFF. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

6 6

Re: Enum class
by George Russell 24 Oct '01

24 Oct '01

I personally think the inclusion of Float and Double in Enum is an unmitigated disaster. Enum consists of three separate parts: (1) succ & pred. These appear for float to correspond to adding or subtracting 1.0. (I am finding this out by testing with ghci; it's not specified where it should be, in section 6.3.4 of the standard). Because of rounding errors, succ and pred fail many of the properties for float they have for integers, EG succ . pred = pred . succ = id succ x > x and so on. succ and pred might actually be USEFUL if instead they represented the next representable real (with succ (-0.0) = 0.0 I suppose), as it is I don't really need succ when (+1.0) is clearer and not much longer to type. (2) toEnum,fromEnum. fromEnum appears to do some unspecified rounding; for GHC it rounds to 0. toEnum also does rounding, since Float has in some areas less precision than integers. For example (toEnum 1234567890) :: Float and (toEnum 1234567891) :: Float appear to be identical. Why we should need two poorly-specified rounding functions here is beyond me. (3) enumFrom, enumFromThen and so on, aka arithmetic sequences. These are defined in terms of equations which work for exact types, but to find out how it actually works you need to decipher the Haskell code in the prelude, which tells you the increment is added at each step. Thus the second element of [m,n...] may not be n, and [x..] will eventually get stuck in a loop. I think it would be best if we could just get rid of using the Enum instance for Float and Double, but if not it should be deprecated.

4 4

Re: Monomorphism, monomorphism...
by Marcin 'Qrczak' Kowalczyk 24 Oct '01

24 Oct '01

Mon, 8 Oct 2001 11:35:48 +0200, Hannah Schroeter <uk1o(a)rz.uni-karlsruhe.de> pisze: > Now, with the typical dictionary implementation of type classes, > this wouldn't really be too difficult. Dictionaries would have to be make hashable and comparable. For a sane semantics you can't compare their identities, because dictionaries of instances of the same type might be created independently in separate modules and would be treated as different. So we would either need to extend the representation of each dictionary to include a runtime identification of the type, or somehow guarantee to share the representation of equal dictionaries. >> C++ templates require having source available in each place a template >> is used. > > No. The standard specifies "export"ed templates. It's only that > nearly no implementation supports that part of the ISO standard. Ok, I was talking about the traditional model of compilation of C++. That's why nobody fully implemented 'export' yet: it doesn't fit it. > Isn't there some experimental thing that implements type classes > by complete specialization of all code that uses polymorphic > values? I'm not sure. I argued for a kind of pragma between INLINE and SPECIALIZE, which would tell the compiler to export the unfolding for making specializations in modules which need them, but don't bother with inlining each call. SimonPJ agreed that it's a good idea and is perhaps working on this. I was only able to change ghc to mark internal instance functions as inline. The effect isn't exactly right. > But at least, C++ templates have pattern matching ([partial] > specialization!) and are Turing complete, albeit in a very > strange way of expression. That's why they have a limited depth of recursion (I think 31 is the required minimum). >> The C++ way wouldn't work for Haskell in general because sometimes >> the depth of instances created is not bounded statically, > > Can you name such a case in standard H'98? Polymorphic recursion: f :: Show a => Int -> a -> String f n x | null (drop n str) = f n (x,x) | otherwise = str where str = show x > Right. A collection of existentially typed values is similar to > abstract class Base ... class Derived1 : Base ... class Derived2 : Base, > Collection[Base] with values of the different derived classes in > typical OO languages. Except that there are no downcasts (neither checked with a Maybe result nor unchecked unsafe). Since OO languages often use subtypes to emulate constructors of algebraic types, they need downcasts. In Haskell it's perhaps less needed but it's a pity that it's impossible to translate an OO scheme which makes use of downcasts into Haskell in an extensible way (algebraic types are "closed"). -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

4 3

Re: Incoherence
by John Hughes 24 Oct '01

24 Oct '01

John Hughes wrote: > What we need is different binding syntax for monomorphic and polymorphic > bindings. Roll on := and = ... If I recall correctly, in some earlier language (KRC?) this difference was achieved by letting let-bindings be polymorphic, and where-bindings be monomorphic. The idea was that where-bindings ONLY encode sharing, i.e., making the term graph structure explicit. I actually like that distinction.... Wolfram Not KRC: it had neither let nor where bindings! Each equation could be max one line. In any case, I think this would be unfortunate: given that Haskell permits large expressions, it would be awkward not to be able to make a monomorphic binding except at the equation level. john

1 0

RE: Enum class
by Simon Peyton-Jones 24 Oct '01

24 Oct '01

I'm filing most of this (useful) discussion about Enum under "ideas for Haskell 2". Enum is a known problem, and when we did the Haskell 98 definition in the first place there were various proposals for cleaning it up, but (as the discussion indicates) it's hard to decide what the Right Thing is, so it ended up as you see it. Jan-Willhem comes closest to making concrete proposals related to the Revised Haskell 98 story, so I want to comment on them: | * In the report, give clear and explicit definitions of | enumFrom... for Float and Double. This could be done right now. | The toughest part is deciding what the behavior at extremes should | be; any behavior is bad, and so picking one with appropriate caveats | should be just fine. I don't foresee agreement on which bad | behavior is appropriate. The Report Section 6.3.4 (about Enum) refers back to Section 3.10 for semantics for enumFrom etc. There you'll find a specification for what they mean, including Float and Double. If I can improve the wording I'd be glad to do so, but it does look defined to me. | * Get rid of the useless (and in truth actively dangerous) default | methods for enumFrom... and kin. This could be done now, I think. I can see the point here, but that would break working programs. I'd be happy to add a comment with the default methods to say that they only work for types that map into Int nicely. | * Definitions of enumFrom... for Int which deal gracefully with | overflow might be a nice addition to the report as people get them | wrong. Hmm. If the specification is ok, I'm disinclined to add an implementation too -- there's every chance I'll get it wrong too! | * Add definitions for boundedEnumFrom... to the Prelude, | | * Split the Enum class into two. Not for Haskell 98, I think. Even the former would break working programs that happen to define boundedEnumFrom... Ah well. Simon

1 0

Re: rank 2-polymorphism and type checking
by Janis Voigtlaender 24 Oct '01

24 Oct '01

Iavor S. Diatchki writes: > > > test :: (forall t . (forall a . t a) -> t b) -> b -> b > i am not an expert on this, but isnt this rank 3? Might be. Does this mean I cannot write it in Haskell? But, with data T a = C I can write: test' :: (forall t . (forall a . t a) -> t b) -> b -> b test' g x = case g C of C -> x Here, the type checker finds out on its own that t is instantiated to T. Still, why are the annotations in the following code not enough to let it also accept the definition of "test" (see my earlier message), respectively how can I tell it that t should be instantiated to t c = forall d . (c->d) -> d -> d ? test :: (forall t . (forall a . t a) -> t b) -> b -> b test g x = (g :: (forall a . (forall d . (a->d) -> d -> d)) -> (forall e . (b->e) -> e -> e)) ((\f y -> y) :: (forall a . (forall d . (a->d) -> d -> d))) (id :: (b -> b)) (x :: b) -- Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de

1 0

RE: Haskell 98 - Standard Prelude - Floating Class
by Lennart Augustsson 24 Oct '01

24 Oct '01

> That's a good idea too. > Is there a reason for defining acosh as above instead of > acosh x = log(x + sqrt(x*x-1)) If there is one I can't remember it. :-) -- Lennart

3 2

Re: Enum class
by Jan-Willem Maessen 23 Oct '01

23 Oct '01

Alas, it seems to me Enum is really two classes rather unfortunately lumped together: Correspondence with Int: > class Enum a where > succ, pred :: a -> a > toEnum :: Int -> a > fromEnum :: a -> Int Arithmetic series-like enumeration: > class Enum a where > enumFrom :: a -> [a] -- [n..] > enumFromThen :: a -> a -> [a] -- [n,n'..] > enumFromTo :: a -> a -> [a] -- [n..m] > enumFromThenTo :: a -> a -> a -> [a] -- [n,n'..m] Having recently had to tweak prelude definitions of all of the above, I can personally testify that the situation is not a happy one: We can't meaningfully define correspondence with Int for type Integer, much less Float, Double, etc. The default enumFrom... use toEnum on Int sequences, and as far as I can tell are no use to anyone; Bounded types must close off the ends of the enumeration at minBound and maxBound, and unbounded types won't fit into an Int. So, what's to be done? * In the report, give clear and explicit definitions of enumFrom... for Float and Double. This could be done right now. The toughest part is deciding what the behavior at extremes should be; any behavior is bad, and so picking one with appropriate caveats should be just fine. I don't foresee agreement on which bad behavior is appropriate. Definitions for the methods in the first category might be nice, too. Perhaps they should signal an error. I'm clueless as to whether pred and succ just add/subtract 1 or whether they ought to round as well. * Get rid of the useless (and in truth actively dangerous) default methods for enumFrom... and kin. This could be done now, I think. * Definitions of enumFrom... for Int which deal gracefully with overflow might be a nice addition to the report as people get them wrong. The Feb. 2000 release of hugs, for example: Prelude> [(maxBound::Int)-2..maxBound] [2147483645,2147483646,2147483647,-2147483648,-2147483647,-2147483646,-2147483645, etc... [GHC appears to do it right, I have no idea about current hugs or nhc versions.] * Add definitions for boundedEnumFrom... to the Prelude, or perhaps to a library. This might or might not be a big change for Haskell 98; I forget where Simon PJ's drawn the line. It does reflect reality, though. * Split the Enum class into two. Possibly "correspondence with Int" belongs in "Bounded"---but it depends what you think "Bounded" means. Int64 and Word probably don't fit the model too well. In any case, this can't really be a revision to Haskell 98; it needs to be thought about in future Haskell versions. What say others? Is this sensible? Or have I let my recent frustrations take hold? -Jan-Willem Maessen Eager Haskell Project jmaessen(a)mit.edu

2 1

suggestion
by Andre W B Furtado 23 Oct '01

23 Oct '01

What do you all think about activating the mechanism that automatically includes the name of the list before the subject of a mailing list email? For example: "[hugs-users] Installation problems" or "[haskell] newbie question". I think this would be a nice way to make massages more organized and help people who sign multiple lists. I heard somewhere that this is possible, isn't it Simon? Cheers, -- Andre

5 5