- Haskell - Haskell.org

Re: Incoherence
by John Hughes 26 Oct '01

26 Oct '01

John Hughes wrote: | `x := []' wouldn't be problematic, just monomorphic. | That is, x must be used consistently as a list of a | particular type. Just to check if I understand you correctly. In your proposal, does the following thing share `x'? let x = fac 100 in x + x (My understanding is that, in order to do this in your proposal, we have to say: let x := fac 100 in x + x Correct?) Correct. Does this also mean that it becomes impossible to share polymorphic values? I.e. the following contrived example will not behave as usual: wrong :: Either String a wrong = Left (show (fac 100)) -- not shared? example1 :: Either String Int example1 := do wrong return 1 example2 :: Either String Char example2 := do wrong return 'a' (With the usual Either monad instance.) Also true. Of course, in this case, there is a perfect remedy, just lifting out `show (fac 100', which is a monomorphic expression. However, this is not always possible, we might have a datatype like this: data PolyMonoList a = Poly Int (Foo a) | Mono a (Foo a) | Nil We can construct rather large polymorphic values, which have to be converted in linear time to the same value of a different type. Yup. I guess we already have the problem of not being able to share monomorphic values polymorphically. In fact, the Either monad instance is a good example: instance Monad (Either e) where return = Right Left x >>= k = Left x Right a >>= k = k a In the definition of `>>=', it is impossible to share `Left x'. /Koen. All true, but I doubt whether any of this is a big deal. MLers already live with their "value restriction", which has similar penalties, so there is a precedent. John

2 1

Re: Deprecated feature section
by John Hughes 26 Oct '01

26 Oct '01

George Russel proposed a search for things which should be deprecated. I have a very distinct unfondness for contexts in algebraic data type declarations. They make absolutely no difference except move type errors to a different part of a program (or rather, they add type errors). In that sense they could be said to be quite harmless, but they dramatically complicate the typing rules for everything involving algebraic data types, especially when combined with labelled fields. Cheers, /kff Seconded! There is a sensible meaning for contexts on data-type declarations, but Haskell ones don't have it. (See my paper "Restricted Data Types" in the Haskell workshop a couple of years ago). At present they are simply useless. John

1 0

bug in displaying fixed numbers
by Lukasz Pankowski 25 Oct '01

25 Oct '01

I was very surprised when I discovered (writing a bit more complicated program) that a program like > import Numeric ( floatToDigits ) > print $ showFFloat Nothing 0.01 "" enters in to infinite loop. I found that (formatRealFloat FFFixed Nothing) do not like displaying numbers less than 0.1. For x = 0.01 we have e=-1 and ds="1". Function f loops down to 0, which will never be reached. I changed the function in hugs for my use. But since the problem is in a standard library I will have to make a workaround for may code to work elsewhere. Original and modified parts below. Original: FFFixed -> case decs of Nothing -> let f 0 s ds = mk0 s ++ "." ++ mk0 ds f n s "" = f (n-1) (s++"0") "" f n s (d:ds) = f (n-1) (s++[d]) ds mk0 "" = "0" mk0 s = s in f e "" ds Wish: FFFixed -> case decs of Nothing -> let f 0 s ds = mk0 s ++ "." ++ mk0 ds f n s "" = f (n-1) (s++"0") "" f n s (d:ds) = f (n-1) (s++[d]) ds g n ds = "0." ++ (replicate n '0') ++ ds mk0 "" = "0" mk0 s = s in if e >= 0 then f e "" ds else g (-e) ds I am rather new to Haskell so I do not know if the problem have been discussed already. -- =*= Lukasz Pankowski =*=

1 0

Re: Incoherence
by Marcin 'Qrczak' Kowalczyk 25 Oct '01

25 Oct '01

Thu, 25 Oct 2001 09:47:31 +0000, Levent Erkok <erkok(a)cse.ogi.edu> pisze: > Another place where `:=' bindings are badly needed is the recursive > do-notation (mdo, as supported in hugs.) In an mdo, let bindings > have to be monomorphic, because they are passed back to the mfix > loop in a lambda binding. Hence, if we had :=, we can simply say > that mdo only allows let bindings of the `:=' form, and that would > clear up the whole issue. It would be great to be able to write ':=' inside 'do' without 'let' because 'let' starts a new layout level and requires increased indentation when the definition doesn't fit in one line. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Re: Incoherence
by John Hughes 25 Oct '01

25 Oct '01

John Hughes wrote: > What we need is different binding syntax for monomorphic and polymorphic > bindings. Roll on := and = ... I agree absolutely that we need such a distinction. Although it's worth clarifying a point. The monomorphism restriction doesn't exclude polymorphism, just overloading, e.g. I can bind `x = []' with no problem. So is your proposal to have := bind non-overloaded (and non-implicitly parameterized terms), or do you really mean that it will only bind monomorphic terms? (thus `x := []' would be problematic, unless there's a type sig). --Jeff My proposal is that := should bind *monomorphically* -- just like lambda binding. The motivation for that is that a polymorphic function can easily become overloaded after a small change to the program, such as adding removal of duplicate elements from a list. Such changes shouldn't cause wholesale differences in typing -- which the MR currently can. Another way to look at it is that = should imply type generalisation (including qualification), and := should mean no generalisation. It's a little odd to support *two kinds* of generalisation (with and without qualification). `x := []' wouldn't be problematic, just monomorphic. That is, x must be used consistently as a list of a particular type. But that need not prevent the type that x has from being inferred from its uses. John

5 4

HaXml article on IBM developerWorks
by Joe English 25 Oct '01

25 Oct '01

There's a nice article on HaXml (Runciman and Wallace's excellent Haskell toolkit for XML) in the "XML Matters" section in IBM developerWorks. From the abstract: | XML Matters : Transcending the limits of DOM, SAX, and XSLT | ------------------------------------------------------- | Consider Haskell in lieu of DOM, SAX, or XSLT for processing XML data. The | library HaXml creates representations of XML documents as native recursive | data structures in the functional language Haskell. HaXml brings with it a | set of powerful higher order functions for operating on these "datafied" | XML documents. Many of the HaXml techniques are far more elegant, compact, | and powerful than the ones found in familiar techniques like DOM, SAX, or | XSLT. Code samples demonstrate the techniques. http://www-106.ibm.com/developerworks/xml/library/x-matters14.html --Joe English jenglish(a)flightlab.com

1 0

RE: Haskell 98: Enum Class
by Simon Peyton-Jones 25 Oct '01

25 Oct '01

| In addition, I suggest that, since it is widely agreed that | the instances of Enum for Float and Double are highly | unsatisfactory, the report should give these instances the | same status as n+k patterns have (in 1.4 of the recent | revision). In particular, their use should be "discouraged", | and there | should be a warning that the instances may be "altered or | removed in Haskell 2". | | It might clear the ground somewhat for Haskell 2 if there | were a new section containing a list of deprecated features; | we can probably think of some other things which should go in | there. In addition to what's said for n+k patterns, I | suggest the standard explicitly encourage (but not oblige) | conforming compilers to issue warnings when deprecated | features are used. The Revised Haskell 98 report is suppposed to be in conclusion mode. An attempt to decide what features are deprecated would open up a big new debate. One could instead list features which are controversial --- that would be easier. Whether it would actually be worth the work of getting consensus on such a list is not clear to me. Simon

2 1

(no subject)
by Tobias.Haeberlein＠gmx.de 25 Oct '01

25 Oct '01

After lots of unsuccessful searching and trying: Does anyone know how to run Fran with the newest version of ghc? -Tobi -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net

1 0

RE: Haskell 98: Enum class
by Simon Peyton-Jones 25 Oct '01

25 Oct '01

| Somebody raised the issue why to/fromEnum doesn't use Integer | instead of Int. This would, it would seem, solve at least | some of the Enum problems that arise from (integral) types | with more than 4G values. So, again, why not? There was an extended discussion on this point, I believe, during the Haskell 1.4 --> Haskell 98 transition. I forget the details, but I expect that efficiency was an issue. However, regardless of the merits of the case, changing the type of to/fromEnum is not a possibility for the Haskell 98 report, I'm afraid. Simon

1 0

Re:Haskell 98: Enum Class
by George Russell 25 Oct '01

25 Oct '01

Simon Peyton Jones suggested the following changes: > 1. Move specification of enumFrom and friends from 3.10 to 6.3.4 > > 2. Specify that for bounded types, (succ maxBound) and (pred minBound) > are errors. > > 3. Specify that succ and pred on numeric types just add/subtract 1 > (subject to > (2) above. > > 4. Rewrite D.2 to talk about deriving only, not about Enum in general. > > 5. In Appendix A, the Enum class defn, add comments to explain that the > default methods only work for types whose fromEnum/toEnum range fits=20 > inside Int. In addition, I suggest that, since it is widely agreed that the instances of Enum for Float and Double are highly unsatisfactory, the report should give these instances the same status as n+k patterns have (in 1.4 of the recent revision). In particular, their use should be "discouraged", and there should be a warning that the instances may be "altered or removed in Haskell 2". It might clear the ground somewhat for Haskell 2 if there were a new section containing a list of deprecated features; we can probably think of some other things which should go in there. In addition to what's said for n+k patterns, I suggest the standard explicitly encourage (but not oblige) conforming compilers to issue warnings when deprecated features are used.

3 3