April 2001 - Haskell - Haskell.org

Re: help!!!!
by Ashley Yakeley 26 Apr '01

26 Apr '01

At 2001-04-26 11:44, Cadena Silva Andres wrote: >I need examples of trees please. Of all the trees that grow so fair, Old England to adorn, Greater are none beneath the Sun, Than Oak, and Ash, and Thorn. Sing Oak, and Ash, and Thorn, good Sirs (All of a Midsummer morn)! Surely we sing of no little thing, In Oak, and Ash, and Thorn! Oak of the Clay lived many a day, Or ever Aeneas began; Ash of the Loam was a lady at home, When Brut was an outlaw man; Thorn of the Down saw New Troy Town (From which was London born); Witness hereby the ancientry Of Oak, and Ash, and Thorn! Yew that is old in churchyard mould, He breedeth a mighty bow; Alder for shoes do wise men choose, And Beech for cups also. But when ye have killed, and your bowl is spilled, And your shoes are clean outworn, Back ye must speed for all that ye need, To Oak, and Ash, and Thorn! Ellum she hateth mankind, and waiteth Till every gust be laid, To drop a limb on the head of him, That anyway trusts her shade: But whether a lad be sober or sad, Or mellow with ale from the horn, He will take no wrong when he lieth along 'Neath Oak, and Ash, and Thorn! Oh, do not tell the Priest our plight, Or he would call it a sin; But - we have been out in the woods all night, A-conjuring Summer in! And we bring you news by word of mouth - Good news for cattle and corn - Now is the Sun come up from the South, With Oak, and Ash, and Thorn! Sing Oak, and Ash, and Thorn, good Sirs (All of a Midsummer morn)! England shall bide till Judgement Tide, By Oak, and Ash, and Thorn! (from _Puck of Pook's Hill_, Rudyard Kipling). -- Ashley Yakeley, Seattle WA

1 0

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 25 Apr '01

25 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