- Haskell-Cafe - Haskell.org

RE: Primitive types and Prelude shenanigans
by Simon Peyton-Jones 28 Feb '01

28 Feb '01

| Why not just let | | if x then y else z | | be syntactic sugar for | | Prelude.ifThenElse x y z The burden of my original message was that a) this is reasonable, but b) it would have to become the *defined behaviour* As you say, the "defined behaviour" would have to cover guards as well, and I'm not absolutely certain what else. The way GHC is set up now, it's relatively easy to make such changes (this wasn't true before). But it takes some design work. If someone cares enough to do the design work, and actively wants the result, I'll see how hard it is to implement. Simon

3 2

examples using built-in state monad
by Konst Sushenko 28 Feb '01

28 Feb '01

hello, in my program i used my own parameterised state transformer monad, which is well described in literature: newtype State s m a = ST (s -> m (a,s)) ghc and hugs contain built in implementation of state monad ST. is it the same thing? the documentation is not clear on that. if it is the same, is it faster? also, could someone please recommend any samples that use the built in ST monad? thanks konst

2 1

Re: Literate Programming in Haskell?
by Bill Halchin 28 Feb '01

28 Feb '01

Hello Haskell Community, Probably somebody else has already brought this issue up already. Why can't we have some kind of integrated literate programming model where I can I can have hyperlinks in comments to documents represented in XML?? In other words, a kind of seamless literate progarmming environment in Haskell with XML, i.e. Haskell and XML are seamless?? E.g. here is a step in the right direction by writing in Literate Haskell in HTML!: http://www.numeric-quest.com/haskell/ The stuff at this URL is pretty cool, i.e. "Haskell" scripts written in HTML. I want to also see hyperlinks to XML docs in Literate Haskell comments or maybe even to Haskell code! Regards, Bill Halchin >From: "Erik Meijer" <erik(a)meijcrosoft.com> >To: "Patrik Jansson" <patrikj(a)cs.chalmers.se>, <haskell-cafe(a)haskell.org> >CC: <ralf(a)cs.uu.nl> >Subject: Re: Literate Programming in Haskell? >Date: Mon, 19 Feb 2001 22:00:47 -0800 > >You also might take a look at Maarten Fokkinga's mira.sty >http://www.cse.ogi.edu/~mbs/src/textools/ and Mark Shileds' abbrev.sty >which >was derived from that http://www.cse.ogi.edu/~mbs/src/textools/. > >Erik >----- Original Message ----- >From: "Patrik Jansson" <patrikj(a)cs.chalmers.se> >To: <haskell-cafe(a)haskell.org> >Cc: <ralf(a)cs.uu.nl> >Sent: Monday, February 19, 2001 6:07 AM >Subject: Re: Literate Programming in Haskell? > > > > On Mon, 19 Feb 2001, Bostjan Slivnik wrote: > > > > > > > I'm also very interested in this, but ideally I would want the >output >to > > > > be in some proportional font, with symbols like =>, ->, <- replaced >with > > > > arrows, etc. Also, it would be very nice to have the code >automatically > > > > column aligned (using heuristics). > > > > > > So am I. Is anybody willing to cooperate on the desing of such tool? > > > > A tool I am using is Ralf Hinze's lhs2tex > > > > http://www.informatik.uni-bonn.de/~ralf/Literate.tar.gz > > > > http://www.informatik.uni-bonn.de/~ralf/Guide.ps.gz > > > > It transforms .lhs files (with some formatting commands in LaTeX-style > > comments) to LaTeX. Development based on this idea is something I would >be > > willing to participate in as I already have a fair amount of Haskell > > code/articles (read: my PhD thesis;-) in this format. > > > > Maybe Ralf can say something about his views on further development of > > lhs2tex (copyright etc.) by other people (us?). > > > > /Patrik Jansson > > > > PS. I have made some small improvements to lhs2tex locally and I seem to > > remember that one or two of those were actually needed to get it to > > run with my ghc version. > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > >_______________________________________________ >Haskell-Cafe mailing list >Haskell-Cafe(a)haskell.org >http://www.haskell.org/mailman/listinfo/haskell-cafe _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

1 0

RE: Primitive types and Prelude shenanigans
by Simon Peyton-Jones 27 Feb '01

27 Feb '01

| | Some while ago I modified GHC to have an extra runtime | | flag to let you change this behaviour. The effect was | | that 3 turns into simply (fromInt 3), and the | | "fromInt" means "whatever fromInt is in scope". | | Hmmm... so how about: | | foo fromInt = 3 | | Would this translate to: | | foo f = f 3 This exactly what will happen. But you are right to say that it is perhaps not what you want. Another alternative would be: "3" turns into "Prelude.fromInt 3", where "Prelude.fromInt" means "whatever Prelude.fromInt is in scope". So then you'd have to say import Prelude () import MyPrelude as Prelude (as Malcolm and Marcin suggested). Maybe that's a good plan; it's a little more heavyweight. [Incidentally, if this is nhc's behaviour, it's not H98. The Report (tries to) stress that you get the "fromInt from the actual standard Prelude" regardless of what is in scope. That's why I'm not going to make it the default behaviour.] Yet another possibility would to be say you get "the unqualified fromInt that's in scope at top level". But that seems worse. Re Bools, Koen and Marcin write (respectively) | | [...] guarantee that (if otherwise e1 e2) = e1. | | I do not understand this. "otherwise" is simply a function | name, that can be used, redefined or hidden, by anyone. It | is not used in any desugaring. Why change that behaviour? | > So much for numerics. It's much less obvious what to do | about booleans. | | IMHO a natural generalization (not necessarily useful) is to follow | the definition of the 'if' syntactic sugar literally. 'if' expands | to the appropriate 'case'. So Prelude.True and Prelude.False must be | defined, and they must have the same type (otherwise we get a type | error each time we use 'if'). This would allow even | data FancyBool a = True | False | DontKnow a The point is that there must be a *defined* desugaring. The desugaring in the report defines the behaviour, but the compiler is free to do differently. If one is to be free to rebind types, the desugaring must be fully defined. Marcin suggests that 'if' is just syntactic sugar. But that would be a disaster if the new Bool type didn't have constructors True and False. For example, maybe Bool becomes a function: type Bool = forall b. b -> b -> b No constructor 'True'! Here I think the right thing is to say that desugaring for boolean constructs uses a function 'if' assumed to have type if :: forall b. Bool -> b -> b -> b Now the programmer can define both Bool and if, and the compiler will be happy. My point is this: there is some *design* to do here. It's not obvious what the design should be. But if anyone feels inclined to do the design (in consultation with the community of course) then I'd be inclined to implement it in GHC. (Though I'm not writing a blank cheque!) Decoupling the prelude is a desirable goal. Simon

3 2

Re: Tree handling
by Lars Lundgren 26 Feb '01

26 Feb '01

On Mon, 26 Feb 2001, Martin Gustafsson wrote: > Hello > > I'm a haskell newbie that tries to create a tree with arbitary numbers of childs. > I create the data structure but i can't do anything on it can someone please help > me with a small function that sums the values of the leafs, so i don´t loose my hair > so fast. > > The datastructure looks like this and a binary tree built with it would look like this: > > > data GeneralTree = Nil | Node (Integer,[GeneralTree]) > As you said you were a newbie I will ask a few questions about your datastructure. Do you know that there is no need to tuple the elements in the Node if you do not want to. You can write: data GeneralTree = Nil | Node Integer [GeneralTree] What is the intended difference between (Node 5 []) and (Node 5 [Nil]) ? > > tree = > (20, > [ > (-20,[(30,[Nil]),(20,[Nil])]), > (40,[(65,[Nil]),(-40,[Nil])]) > ] > ) This is not of type GeneralTree! (And its layout is messed up) Hint: write the type of every expression you write, and debugging will be much easier. tree :: GeneralTree ERROR tree.hs:8 - Type error in explicitly typed binding *** Term : tree *** Type : (a,[(b,[(c,[GeneralTree])])]) *** Does not match : GeneralTree This is an expression with type GeneralTree: tree :: GeneralTree tree = Node 20 [Node (-20) [Node 30 [Nil], Node 20 [Nil]], Node 40 [Node 65 [Nil], Node (-40) [Nil]]] Now it should be very easy to write a function to sum the nodes in a tree sumTree :: GeneralTree -> Integer sumTree Nil = 0 sumTree (Node n ts) = ... write this yourself hint - sum and map are very useful functions (defined in the prelude) as are recursion. Good luck! /Lars L

1 0

RE: stack overflow
by Scott Turner 26 Feb '01

26 Feb '01

At 01:26 2001-02-26 -0800, Simon Peyton-Jones wrote: >And so on. So we build up a giant chain of thunks. >Finally we evaluate the giant chain, and that builds up >a giant stack. > ... >If GHC were to inline foldl more vigorously, this would [not] happen. I'd hate to have my programs rely on implementation-dependent optimizations. BTW, I've wondered why the Prelude provides foldl, which commonly leads to this trap, and does not provide the strict variant foldl', which is useful enough that it's defined internal to the Hugs prelude. Simple prejudice against strictness? -- Scott Turner p.turner(a)computer.org http://www.billygoat.org/pkturner

1 0

Lo mejor de Internet aqu�
by promocionesdosmiluno＠yahoo.es 25 Feb '01

25 Feb '01

Visita esta web http://MundoEspanya.redireccion.com

1 0

Re: unliftM
by Lars Lundgren 23 Feb '01

23 Feb '01

On 23 Feb 2001, Julian Assange wrote: > > Is there a standard construct for something of this ilk: > > unliftM :: Monad m a -> a > I do not know if it is a standard, but every monad usually has a "runMonad" function. For ST you have runST, for IO you have unsafePerformIO and for your own monad you need to define it. Note, that if you use unsafePerformIO you, the action must not have (important) sideeffects. The burden of proof is upon YOU. /Lars L

1 0

Re: Inferring from context declarations
by D. Tweed 22 Feb '01

22 Feb '01

George Russell wrote: > > (3) Simon Peyton Jones' comments about dictionary passing are a red herring, > since they assume a particular form of compiler. Various (MLj, MLton) > ML compilers already inline out all polymorphism. Some C++ compilers/linkers > do it in a rather crude way as well, for templates. If you can do it, > you can forget about dictionary passing. [Standard disclaimer: I write prototype code that's never `finished' to ever-changing specs in a university environment; other people probably view things differently.] I'm not sure I'd agree about this. Note that there's two levels, inlining polymorphic functions at the call site and `instantiating polymorphic functions at each usage type' without doing the inlining. C++ compilers have to at least do the second because of the prevailing philosophy of what templates are (i.e., that they're safer function-macros). Some of the time this is what's wanted, but sometimes it imposes annoying compilation issues (the source code of the polymorphic function has to be available everytime you want to use the function on a new class, even if its not time critical, which isn't the case for Haskell). I also often write/generate very large polymorphic functions that in an ideal world (where compilers are can do _serious, serious_ magic) I'd prefer to work using something similar to a dictionary passing implementation. I'd argue that keeping flexibility about polymorphic function implementation (which assumes some default but can be overridden by the programmer) in Haskell compilers is a Good Thing. Given that, unless computing hardware really revolutionises, the `speed/memory' profile of todays desktop PC is going to recurr in wearable computers/PDAs/etc I believe that in 20 years time we'll still be figuring out the same trade-offs, and so need to keep flexibility. ___cheers,_dave________________________________________________________ www.cs.bris.ac.uk/~tweed/pi.htm|tweed's law: however many computers email: tweed(a)cs.bris.ac.uk | you have, half your time is spent work tel: (0117) 954-5250 | waiting for compilations to finish.

2 2

Re: Primitive types and Prelude shenanigans
by Ketil Malde 22 Feb '01

22 Feb '01

qrczak(a)knm.org.pl (Marcin 'Qrczak' Kowalczyk) writes: > 'negate' defined, as it's obviously meaningless for them. We can put > 'fromInteger' in some class and 'negate' in its subclass, and make > only the former instance for natural numbers. Nitpick: not necessarily its subclass, either. We can probably imagine types where negate makes sense, but fromInteger does not, as well as vice versa. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0