Re: PATCH: implementation for TH PprLib.hs punctuate function

2004-03-04 Thread Ian Lynagh
On Tue, Mar 02, 2004 at 07:02:18PM +, Duncan Coutts wrote: I noticed that the 6.3 version of the PprLib.hs is not fully implemented so pretty printing some things calls Prelude.undefined. Thanks - looks like something I forgot to go back to. Attached patch typechecks but I've not

RE: [Haskell] Per-type function namespaces (was: Data.Set whishes)

2004-03-04 Thread Simon Peyton-Jones
| detail, of course ;). What I'm secretly hoping is that the | GHC/hugs/HBC people will see what I'm trying to achieve, tell me I'm | totally nuts, and then suggest an alternative, much simpler approach | which gives us exactly the same goal ... As I implied earlier, I am thus far unconvinced

RE: [Haskell] Per-type function namespaces (was: Data.Set whishes)

2004-03-04 Thread Simon Peyton-Jones
| So there is no sub-typing, no row polymorphism, no attempt to give | f r = r.x | a fancy type that makes f applicable to any record with an x field. | | On the other hand, there is also no problem with many records having the | same field name either, which is the problem we started with.

Re: [Haskell] Per-type function namespaces (was: Data.Set whishes)

2004-03-04 Thread Andreas Rossberg
Simon Peyton-Jones wrote: If the big bug-bear is record selectors, let's focus on them exclusively. I now think that ML got it right. ML records are simply labelled tuples. Note that this is true only for SML, not for Caml. So just as (Bool,Int) is an anonymous type, so is {x::Bool, y::Int}.

Re: [Haskell] Per-type function namespaces (was: Data.Set whishes)

2004-03-04 Thread Andreas Rossberg
Simon Peyton-Jones wrote: | Actually, #l is just syntactic sugar for (\{l=x,...}-x), which implies | that you might need type annotations. Yes I was wrong to say that there are no implicitly-defined record selectors; (#l r) is exactly that. Syntactically I'd prefer (r.l); but regardless, it's a

Re: [Haskell] Per-type function namespaces (was: Data.Set whishes)

2004-03-04 Thread Ross Paterson
On Thu, Mar 04, 2004 at 09:21:23AM -, Simon Peyton-Jones wrote: My personal view is this: we should have adopted the ML view of records. It solves the immediate problem, and no more elaborate scheme seems sufficiently right to be declared the winner.Alas, like all other proposals, it's

[Haskell] GHC EXE Windows

2004-03-04 Thread Stenio
GHC executable file only works in MS-DOS. I would like run the executable file on Windows. Can someone help meThanks ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Per-type function namespaces (was: Data.Set whishes)

2004-03-04 Thread Conor McBride
Hi While we're talking about SML, I think there are a few other things worth stealing... 1) I still miss multiline pattern matching in lambda (fn p1 = e1 | p2 = e2 | ...) not strictly necessary, but often less disruptive of the text than either a let/where-introduced helper-function or \ x

[Haskell] natural numbers

2004-03-04 Thread Iavor S. Diatchki
hello, looking through the documentation for Data.Word I run into the follwoing comment: it would be very natural to add a type Natural providing an unbounded size unsigned integer, just as Integer provides unbounded size signed integers. We do not do that yet since there is no demand for it.

Re: [Haskell] natural numbers

2004-03-04 Thread Alastair Reid
it would also be useful to have finite natural numbers, ala C's unsigned int. Word8, Word16, Word32 and Word64 -- Alastair Reid www.haskell-consulting.com ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] natural numbers

2004-03-04 Thread Pablo E. Martinez Lopez
it would be very natural to add a type Natural providing an unbounded size unsigned integer, just as Integer provides unbounded size signed integers. We do not do that yet since there is no demand for it. if that is not too much work could we have that in the library? i think it would be very

Re: [Haskell-cafe] State Monad

2004-03-04 Thread Georg Martius
Hi, thanks for your suggestion. The thing is, that I don't want to change the type of my transformation functions. To answer Iavor's question: I have basically two types of transformation functions. One StringTransformation (String - String) and one transformation with a string and something