- Haskell - Haskell.org

RE: help!!!!
by vortex 27 Apr '01

27 Apr '01

Gepost in fa.haskell in reactie op een mail met subject: help!!! --------------- Cadena Silva Andres wrote: > I need examples of trees please. No problem! Lemme see now... There's oak, scarlet oak, bur oak, pin oak, northern red oak, shingle oak, swamp white oak, pine, Scotch pine, Austrian pine, willow, white willow, birch, redwood, mulberry, apple, cherry, black cherry, Oriental cherry, yew, hazel, juniper, alder, ash, elm, holly, poplar, aspen, maple, hedge maple, trident maple, Arnur maple, shagbark maple, sugar maple, paperbark maple, Japanese maple, black maple, Norway maple, Crimson King Norway maple, Tatarian maple, red maple, autumn flame red maple, october glory red maple, silver maple, Beebee silver maple, Freeman maple, White Tigress maple, rowan, hemlock, larch, cedar, spruce, white fir, Nikko fir, Douglas fir, Nordmann fir, sequoia, yellow buckeye, Ohio buckeye, hickory, bitternut hickory, shagbark hickory, northern catalpa, filbert, dogwood, hawthorn, hornbeam, American hophornbeam, persimmon, silverbell, magnolia, Franklin, lacebark, pear, sassafras, lilac, corktree, Ohio buckeye, red buckeye, chestnut, horsechestnut, European horsechestnut, Brioti red horsechestnut, serviceberry, walnut, black walnut, sweetgum, crabapple, Japanese Zelkova, Japanese pagodatree, elder, boxelder, Mimosa, orange, Cockspur hawthorn, Washington hawthorn, tulip, sourwood, palm, forest pansy redbud, maidenhair, ginkgo, photinia, black locust, sunburst thornless honeylocust, cypress, weeping nootka false cypress, and, last but not least, the charmingly named American bladdernut. You need any more, just holler, y'hear? --- Frank Atanassow, Information & Computing Sciences, Utrecht University Padualaan 14, PO Box 80.089, 3508TB Utrecht, The Netherlands Tel +31 (0)30 253-3261 Fax +31 (0)30 251-3791 _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

1 0

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