Replacing the Prelude

2002-05-12 Thread Ashley Yakeley
I have recently been experimenting writing code that replaces large chunks of the Prelude, compiling with -fno-implicit-prelude. I notice that I can happily redefine numeric literals simply by creating functions called 'fromInteger' and 'fromRational': GHC will use whatever is in scope for tho

Re: Replacing the Prelude

2002-05-14 Thread Dylan Thurston
, and not worry about types at all. > > I accept that this might be a slightly bizarre request. There are a > number of things I don't like about the way the Prelude.Monad class and > 'do' notation are set up, and it would be nice to be able to experiment > with alte

RE: Replacing the Prelude

2002-05-14 Thread Simon Peyton-Jones
Ashley writes | > I was hoping to do something similar for 'do' notation by redefining | > (>>), (>>=) etc., but unfortunately GHC is quite insistent | that 'do' notation quite specifically refers to GHC.Base.Monad Dylan replies | I'm surprised that ghc uses the fromInteger and fromRational

RE: Replacing the Prelude

2002-06-03 Thread Ashley Yakeley
Ping! At 2002-05-14 07:17, Simon Peyton-Jones wrote: >Ashley writes > >| > I was hoping to do something similar for 'do' notation by redefining >| > (>>), (>>=) etc., but unfortunately GHC is quite insistent >| that 'do' notation quite specifically refers to GHC.Base.Monad > >Dylan replies > >

RE: replacing the Prelude (again)

2002-07-15 Thread Simon Peyton-Jones
I'm fond of the idea proposed by Marcin 'Qrczak' Kowalczyk: | May I propose an alternative way of specifying an alternative Prelude? | Instead of having a command line switch, let's say that 3 always means | Prelude.fromInteger 3 - for any *module Prelude* which is in scope! That's a perfe

RE: replacing the Prelude (again)

2002-07-15 Thread Ashley Yakeley
At 2002-07-15 01:05, Simon Peyton-Jones wrote: >I quite like the fact that you would then have to say > > import MyPrelude as Prelude > >thereby stressing that you are importing the Prelude stuff. Doesn't this assume your Prelude stuff is all in one module? Or can you import several modu

Re: replacing the Prelude (again)

2002-07-15 Thread Malcolm Wallace
> | anymore. What I would like is that the defualting rules refer > | to the classes in my version of the Prelude, > | not the Standard Prelude. > > You can always get that (with the -fno-implicit-prelude thing) by adding > default [Int, Double] > > or whatever to your source module, jus

RE: replacing the Prelude (again)

2002-07-15 Thread Bernard James POPE
Hi All, Thanks to everyone for their comments. I can see that this is quite a difficult design problem, and it is unlikely that one solution will please everyone, which makes me think that the current solution will probably stand. Simon Peyton-Jones writes: > Bernie writes: > | anymore. What

Re: replacing the Prelude (again)

2002-07-15 Thread Bernard James POPE
Hi again, Malcolm writes: > We came across the same problem in the Hat tracer (which is also a > source-to-source transformation, and can also be used for debugging). > > The problem is that the transformation introduces new classes, so > Prelude.Ord -> HatPrelude.Ord > Prelude.Eq -> Ha

Re: replacing the Prelude (again)

2002-07-15 Thread Malcolm Wallace
> > The defaulting mechanism *only* applies to types constrained by > > the original builtin Prelude.Num, not to the transformed class > > HatPrelude.Num. > > I did wonder how Hat tackled this. > Out of curiosity what is the solution that Hat uses? Hat doesn't have a solution. When the lack of

Re: replacing the Prelude (again)

2002-07-15 Thread Olaf Chitil
Malcolm Wallace wrote: > > For what reasons do you require the original prelude? > > Exactly the same reasons. We want to do as little desugaring as > necessary in the transformation, so inevitably we need at least a > small part of the Prelude in scope. This is a bit misleading. We do desugar

Re: replacing the Prelude (again)

2002-07-15 Thread Bernard James POPE
Malcolm writes: > Bernie writes: > > I did wonder how Hat tackled this. > > Out of curiosity what is the solution that Hat uses? > > Hat doesn't have a solution. When the lack of correct defaulting > causes Hat to generate type-incorrect code, the underlying compiler > will complain vociferousl

RE: replacing the Prelude (again)

2002-07-16 Thread Simon Peyton-Jones
|Ambiguities in the class Num are most common, so Haskell | provides another |way to resolve them---with a default declaration: |default (t1 , ... , tn) |where n>=0, and each ti must be a monotype for which Num ti holds. | ^^

Re: replacing the Prelude (again)

2002-07-17 Thread Dylan Thurston
On Tue, Jul 16, 2002 at 04:02:44PM +1000, Bernard James POPE wrote: > I would like to use do-notation in the transformed program, but have it > refer to Prelude.Monad and not MyPrelude.Monad which is also in scope. Why do you have a MyPrelude.Monad (different from Prelude.Monad) if you don't want

Re: replacing the Prelude (again)

2002-07-17 Thread Bernard James POPE
Dylan writes: > On Tue, Jul 16, 2002 at 04:02:44PM +1000, Bernard James POPE wrote: > > I would like to use do-notation in the transformed program, but have it > > refer to Prelude.Monad and not MyPrelude.Monad which is also in scope. > > Why do you have a MyPrelude.Monad (different from Prelude.