- Haskell - Haskell.org

help!!!!
by Cadena Silva Andres 26 Apr '01

26 Apr '01

I need examples of trees please.

2 1

Ŭ�� ÿ� �� ̳ʰ� �ɼ��ִ� ??
by designq＠orgio.net 26 Apr '01

26 Apr '01

1 0

Ŭ�� ÿ� �� ̳ʰ� �ɼ��ִ� ??
by designq＠orgio.net 26 Apr '01

26 Apr '01

1 0

Haskell History
by IAESTE IFML 26 Apr '01

26 Apr '01

Hi! We're very interested in knowing everything (well, lots of things) about functional Programming History, and it's being very hard to get information about it. Could you recommend us some good book or web page to learn more about this subject? Best regards, Carlos, Cristina & Montse

2 1

Implict parameters and monomorphism
by Simon Peyton-Jones 26 Apr '01

26 Apr '01

This is a long message about the design of implicit parameters. In particular, it is about the interaction of the monomorphism restriction with implicit parameters. This issue was discussed in the original implicit-parameter paper, but I wanted to articulate it afresh and propose some design choices Simon Question 1: can we "inherit" implicit parameters ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider this: f x = (x::Int) + ?y where f is *not* a top-level binding. >From the RHS of f we'll get the constraint (?y::Int). There are two types we might infer for f: f :: Int -> Int (so we get ?y from the context of f's definition), or f :: (?y::Int) => Int -> Int At first you might think the first was better, becuase then ?y behaves like a free variable of the definition, rather than having to be passed at each call site. But of course, the WHOLE IDEA is that ?y should be passed at each call site (that's what dynamic binding means) so we'd better infer the second. Question 2: type signatures ~~~~~~~~~~~~~~~~~~~~~~~~~~~ OK, so it it legal to give an explicit, user type signature to f, thus: f :: Int -> Int f x = (x::Int) + ?y At first sight this seems reasonable, but it has the nasty property that adding a type signature changes the dynamic semantics. Consider this: (let f x = (x::Int) + ?y in (f 3, f 3 with ?y=5)) with ?y = 6 returns (3+6, 3+5) vs (let f :: Int -> Int f x = x + ?y in (f 3, f 3 with ?y=5)) with ?y = 6 returns (3+6, 3+6) Indeed, simply inlining f (at the Haskell source level) would change the dynamic semantics. Conclusion: the above type signature is illegal. You'll get a message of the form "could not deduce (?y::Int) from ()". Question 3: monomorphism ~~~~~~~~~~~~~~~~~~~~~~~~ There's a nasty corner case when the monomorphism restriction bites: z = (x::Int) + ?y The argument above suggests that we *must* generalise over the ?y parameter, to get z :: (?y::Int) => Int, but the monomorphism restriction says that we *must not*, giving z :: Int. Why does the momomorphism restriction say this? Because if you have let z = x + ?y in z+z you might not expect the addition to be done twice --- but it will if we follow the argument of Question 2 and generalise over ?y. Possible choices ~~~~~~~~~~~~~~~~ (A) Always generalise over implicit parameters Bindings that fall under the monomorphism restriction can't be generalised Consequences: * Inlning remains valid * No unexpected loss of sharing * But simple bindings like z = ?y + 1 will be rejected, unless you add an explicit type signature (to avoid the monomorphism restriction) z :: (?y::Int) => Int z = ?y + 1 This seems unacceptable (B) Monomorphism restriction "wins" Bindings that fall under the monomorphism restriction can't be generalised Always generalise over implicit parameters *except* for bindings that fall under the monomorphism restriction Consequences * Inlining isn't valid in general * No unexpected loss of sharing * Simple bindings like z = ?y + 1 accepted (get value of ?y from binding site) (C) Always generalise over implicit parameters Bindings that fall under the monomorphism restriction can't be generalised, EXCEPT for implicit parameters Consequences * Inlining remains valid * Unexpected loss of sharing (from the extra generalisation) * Simple bindings like z = ?y + 1 accepted (get value of ?y from occurrence sites) Discussion ~~~~~~~~~~ None of these choices seems very satisfactory. But at least we should decide which we want to do. It's really not clear what is the Right Thing To Do. If you see z = (x::Int) + ?y would you expect the value of ?y to be got from the *occurrence sites* of 'z', or from the valuue of ?y at the *definition* of 'z'? In the case of function definitions, the answer is clearly the former, but less so in the case of non-fucntion definitions. On the other hand, if we say that we get the value of ?y from the definition site of 'z', then inlining 'z' might change the semantics of the program. Choice (C) really says "the monomorphism restriction doesn't apply to implicit parameters". Which is fine, but remember that every innocent binding 'x = ...' that mentions an implicit parameter in the RHS becomes a *function* of that parameter, called at each use of 'x'. Now, the chances are that there are no intervening 'with' clauses that bind ?y, so a decent compiler should common up all those function calls. So I think I strongly favour (C). Indeed, one could make a similar argument for abolishing the monomorphism restriction altogether.

7 10

RE: running for long enough...
by Simon Marlow 25 Apr '01

25 Apr '01

> About the program below, someone (I think Simon Marlow) said > that if I run > it for long enough, I'll see "a"s rather than "b"s. I would > like to know for > how long I will have to wait, since 2 hours were not enough to see it > switching from "b"s to "a"s. > > > main = forkIO a >> b > > where > > a = putStrLn "a" >> a > > b = putStrLn "b" >> b Did you watch it continuously for two hours? It might have changed quicky to "a"s and back again without you noticing. Watch it very carefully. <mischevous grin> :) But seriously, don't waste your time on this example. It just doesn't work too well with GHC, because of the contention between the two threads both trying to access standard output. Cheers, Simon

2 1

GHC on MacOS X
by Ashley Yakeley 25 Apr '01

25 Apr '01

I don't suppose Atze Dykstra or anyone else has done any more work on GHC for MacOS X? Currently the 4.08.1 bootstrapping binaries don't work properly under the final MacOS X -- I had to rerun ranlib on all the libraries, and when I tried to compile a 'Hello World' Haskell program I got unresolvable references (look like trivial arithmetic functions) in the link phase, apparently coming from 'libHSrts.a'. The ideal would be one or more fink scripts (see <http://fink.sourceforge.net/>) that end up with a fully working installation of GHC 5.00. But first I have to figure out how to build the thing manually. -- Ashley Yakeley, Seattle WA

3 2

implicit-parameters paper
by S.D.Mechveliani 24 Apr '01

24 Apr '01

Simon P. Jones mentions some paper on implicit parameters in his recent letter on "Implicit parameters and monomorphism." Please, where to find this paper? ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

Re: Eq instance for (a,b,c,d,e) and upwards
by Olaf Chitil 23 Apr '01

23 Apr '01

I think that this discussion about tuples shows that there is a problem with the Haskell 98 report which should be corrected. I hope Simon accepts it as a minor bug fix. 1) The current wording of paragraph 6.1.4 is highly ambigious. > 6.1.4 Tuples > > Tuples are algebraic datatypes with special syntax, as defined > in Section 3.8. Each tuple type has a single constructor. There > is no upper bound on the size of a tuple. However, some Haskell > implementations may restrict the size of tuples and limit the > instances associated with larger tuples. The Prelude and libraries > define tuple functions such as zip for tuples up to a size of 7. All > tuples are instances of Eq, Ord, Bounded, Read, and Show. Classes > defined in the libraries may also supply instances for tuple types. May the limit for the size of tuples and the limit for instances be different? Do tuples exist at least for a size up to 7? What is the purpose of the last sentence? We should decide what we want and the paragraph should then state it clearly. 2) The arbitrary restrictions that Haskell implementations are permitted to apply, basically imply that you shouldn't use tuples at all if you want your code to be portable. Maybe there isn't even a Show instance for ()? So I think the report should demand that tuples and instances for Eq,Ord,Bounded,Read and Show should be implemented for at least up to a size of a given number n. 3) I propose this number n to be 7. This fits well with the fact that zip etc are defined for tuples up to a size of 7. I agree with Martin that you should use a labelled record or at least an own type instead of large tuples anyway. Programs that generate code should als generate definitions for data types, if large product types are needed. Olaf -- OLAF CHITIL, Dept. of Computer Science, University of York, York YO10 5DD, UK. URL: http://www.cs.york.ac.uk/~olaf/ Tel: +44 1904 434756; Fax: +44 1904 432767

2 1

question of decimal pointed literals
by S.D.Mechveliani 20 Apr '01

20 Apr '01

Can we solve and close the problem of the meaning of decimal pointed leterals? To my | People wrote about toRational (0.9) == 9%10 = False | ... | Probably, the source of a `bug' is a language agreement that the | input is in decimal representation (`0.9') and its meaning is a | floating approximation in _binary_ representation. | For example, 1%5 yields a finite mantissa in decimal representation | and an infinite (periodic) mantissa for the binary representation of | toBinary(1%5) = 1B % 1001B. (a typo: this should be 101B) | Therefore applying toRational to any finite float approximation | (Double, or other) of 1%5 does not return 1%5. Lennart Augustsson <lennart(a)mail.augustsson.net> writes > What are you talking about? Input in decimal representation is > stored as a Rational number. There is absolutely no loss of > precision. and in his next letter citates the Report: > "The floating point literal f is equivalent to > fromRational (n Ratio.% d), where fromRational is a > method in class Fractional and Ratio.% constructs a rational from > two integers, as defined in the Ratio library. The integers n and > d are chosen so that n/d = f." By saying "input is in decimal representation (`0.9')" I meant that a number `0.9' is written by a programmer keeping in mind a decimal representation. Further, according to the citation, 0.9 --> fromRational (9%10), 0.2 --> fromRational (1%5) are stored as the values of type Fractional a => a. (1) What is this `a' for our example of toRational (fromRational (0.9)) == 9%10 ? (2) Why Haskell does not report an ambiguity error? For `a' may be Rational, Double, Float - just anything of Fractional. If we take Lennart's assertion > Input in decimal representation is stored as a Rational number. > There is absolutely no loss of precision. then it should be `a' = Rational. Then, in particular, toRational (0.d) == d%10 = True for any decimal literal d and * any other behavior is a bug. * Is this really so? Now, Hugs-98-Feb-2000, probably, decides that `a' = Double. Because it returns False for 0.9. And in this case these values are _not_ stored as the rational numbers, but convert to Double, with the precision loss caused, as I wrote initially, by truncating of the division result, like 1001B % 1010B. Who could explain, please, whether I understand correct the whole question, and answer to the questions (1), (2) ? And is `False' is a bug? Thanks in advance for the comments. ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2