- Haskell - Haskell.org

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

24 Oct '01

Wed, 24 Oct 2001 10:36:22 +0200, Hannah Schroeter <uk1o(a)rz.uni-karlsruhe.de> pisze: > Why not create a dictionary record while compiling the associated > instance (which may, by the H'98 definition, occur only once in > the program)? Instances with contexts are commonly represented as functions which make dictionaries from other dictionaries. So although the function itself is only one, it may be applied many times to the same argument, and we want to unify results of the application, pretending that there exists only one instance for Eq [[[[Int]]]]. > Yes, of course. It's a similar problem like in Cayenne, where type checking > could take infinite time, too. (And what about current ghc Haskell, > with multiple parameter type classes, overlapping instances, perhaps > even -fallow-undecidable-...?!) The same. module Test where class C a where f :: a instance C a => C a main = print (f :: ()) [qrczak ~]$ ghc -c -fglasgow-exts -fallow-undecidable-instances Test.hs Test.hs:4: Context reduction stack overflow; size = 21 Use -fcontext-stack20 to increase stack size to (e.g.) 20 `C ()' arising from use of `f' at Test.hs:4 `C ()' arising from use of `f' at Test.hs:4 `C ()' arising from use of `f' at Test.hs:4 `C ()' arising from use of `f' at Test.hs:4 `C ()' arising from use of `f' at Test.hs:4 `C ()' arising from use of `f' at Test.hs:4 `C ()' arising from use of `f' at Test.hs:4 `C ()' arising from use of `f' at Test.hs:4 `C ()' arising from use of `f' at Test.hs:4 `C ()' arising from use of `f' at Test.hs:4 `C ()' arising from use of `f' at Test.hs:4 `C ()' arising from use of `f' at Test.hs:4 `C ()' arising from use of `f' at Test.hs:4 `C ()' arising from use of `f' at Test.hs:4 `C ()' arising from use of `f' at Test.hs:4 `C ()' arising from use of `f' at Test.hs:4 `C ()' arising from use of `f' at Test.hs:4 `C ()' arising from use of `f' at Test.hs:4 `C ()' arising from use of `f' at Test.hs:4 `C ()' arising from use of `f' at Test.hs:4 `f at [()]' arising from use of `f' at Test.hs:4 When generalising the type(s) for main -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RE: Enum class
by Simon Marlow 24 Oct '01

24 Oct '01

> > i_succ' = succ i' > > -- ghc : 2147483648 > > -- hugs: -2147483648 > -- nhc98: -2147483648 > -- hbc: -2147483648 > > > I think Hugs is wrong. Integer shouldn't wrap. > > (Actually, ghc is `wrong': hbc, hugs and nhc98 match the Report's > specification here: succ = toEnum . (+1) . fromEnum > This is confirmed by the description of the semantics in > section 3.10.) Indeed. But the default definitions of enumFrom & friends also don't make much sense for Integer. With nhc98, which presumably is using the default definitions from the report: Prelude> [2147483647 .. 2147483649] [] according to the report, this should yield an error (section 6.3.4 states that fromEnum should report an error if its argument is out of range). Both behaviours seem less than useful to me. GHC returns [2147483647, 2147483648, 2147483649], which is also wrong. Is there a good reason why toEnum & fromEnum convert to/from Int rather than Integer? Cheers, Simon

1 0

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