October 2001 - Haskell

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

Haskell 98 Standard; library Complex
by George Russell 25 Oct '01

25 Oct '01

I sent a report to SPJ on Tuesday complaining about the Haskell 98 definition of asin on Complex. Whatever the outcome of this report, I think the Haskell 98 definitions for Complex need the following documentational change. We should document, not in Haskell code, but in words, what each function is supposed to do, where there might be any doubt. For example, how do you tell from the definition of sqrt in the standard which of the two possible square roots is being chosen: > sqrt 0 = 0 > sqrt z@(x:+y) = u :+ (if y < 0 then -v else v) > where (u,v) = if x < 0 then (v',u') else (u',v') > v' = abs y / (u'*2) > u' = sqrt ((magnitude z + abs x) / 2) (I think I'll leave this as an exercise for the reader 8-) What is needed is a statement saying that sqrt z approximates the squareroot with phase in [0,pi) (or whatever the answer is). The standard should also specify in words which answer to log, asinh, acosh, atanh, asin, acos, atan, is being chosen.

1 0

Re: [ketil@ii.uib.no: Re: Enum class]
by Dylan Thurston 25 Oct '01

25 Oct '01

(I want to trim the headers, but don't know the history of this thread. Also cc:ed back to the Haskell list.) On Thu, Oct 25, 2001 at 11:11:42AM +0200, Ketil Malde wrote: > Dylan Thurston <dpt(a)math.harvard.edu> writes: > > I agree that Enum instances for Float/Double are not likely to be > > useful. > > From a gut feeling, I could see a use for expressions like > > [1.5, 1.6..] and [1.5, 1.6..2.0] > > (i.e. enumFromThen and enumFromThenTo) but enumFrom and enumFromTo > making list of rounded integers seems strange to me. > > It seems to me that enumFromThen and -To could be implemented > something like: > > enumFromThen beg next = beg : enumFromThen next (next+delta) > where delta = next-beg > > similarly for enumFromThenTo, of course. > > i.e. depending only on functionality found in Num. Why not put these > functions there, and remove Float and Double as Enum instances? > > What am I missing? Currently you can write data Day = Sunday | Monday | Tuesday | Wednesday | Thursday | Friday | Saturday weekdays = [Monday..Friday] which has nothing to do with Num. Best, Dylan Thurston

1 0