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
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
> | 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
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
> I have a dual Athlon box, make -j2 fails, but make works.
> Is that normal?
I did some tweaking to the build system to help -jN builds, but I
haven't tested a complete build this way. Whereabouts does it fall over
for you?
Cheers,
Simon
___
> I'm trying to do an unregistered build of ghc, using the cross-port
> script. However, compilation aborts at the following point:
>
> haskell/b1/libraries/base > ../../ghc/compiler/ghc-inplace -ldl
> -fglasgow-exts -cpp -Iinclude -funbox-strict-fields
> -package-name base -O
> -H24m -keep-hc-f
> Building htk, I've got an error:
>
> TestGetPut.hs:6:
> Module `GetPut' is located in package `Main'
> but its interface file claims it is part of package
> `uni-events-test'
>
> It happened (as far as I got) when ghc saw in current path
> the *.hi file built for installation. Ther
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
> > 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
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
On Thursday 27 June 2002 12:10, Ketil Z. Malde wrote:
> *lights go on*
>
> Of course! While I have about 90K values to sort, it's only a range
> from 0 to about 5-600, and a less than even distribution at that. (I
> must be a lot denser than I thought. Colin, if you ever happen to pass
> by, do
Simon Marlow quoted Max Kirillov
[snip]
> > Building htk, I've got an error:
> >=20
> > TestGetPut.hs:6:
> > Module `GetPut' is located in package `Main'
> > but its interface file claims it is part of package
> > `uni-events-test'
> >=20
> > It happened (as far as I got) when ghc saw
I know this has been discussed before, but I can't remember the
conclusion and nothing seems to have
been done, so I am going to bring it up again.
Is there any way the compiler can mark object files with whether they
are profiling or not, so that you cannot
link a profiled object with a non-pr
* Ashley Yakeley <[EMAIL PROTECTED]> [2002-07-11T17:06-0700]:
> At 2002-07-11 11:22, Eray Ozkural wrote:
>
> >> A Windows installer for 5.04 is now available via the GHC downloads
> >> page: http://haskell.org/ghc/download_ghc_504.html
> >
> >/me pings debian people. we can't lag behind windows,
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
15 matches
Mail list logo
