Ketil Z. Malde <[EMAIL PROTECTED]> writes
> I'll hereby argue for using a quicksort implementation akin to
>
>> sortBy' _ [] = []
>> sortBy' pc (x:xs) = let (l,e,g) = part3 (`pc` x) xs
>> in sortBy' pc l ++ (x:e) ++ sortBy' pc g
>>where
>>part3 comp xs = p3 [] [] [
Hi Claus.
Moral support but little else below
> As noone has responded so far, I have to conclude that this
> is quite an infrequently used package..
>
> - noone using ghc + win32 API?
> - noone using ghc + hgl on windows?
Although I feel the Win32 package is important I am finding it i
A while ago (in connection with HGL problems, some of which were
traced to incorrect greencard output), I asked here:
> Alternatively, is anyone out there using ghc's win32 binding?
As noone has responded so far, I have to conclude that this
is quite an infrequently used package..
- noone u
> The hmake parser specifically doesn't depend on layout. A
> module doing
> crazy stuff like
>
> module M where
> import qualified {- " -}
> N
>
> is perfectly fine, and all it takes to implement is the addition of a
> `concatMap' over and above the version which expects th
> But ghci already contains a Haskell parser - so it should be much
> less work.
No excuses, but part of the reason we didn't do this is because of the
structure of GHCi. There's a strong separation between the bit we call
the "compiler" which translates a single module into executable code,
and
> (hopefully this is fairly bug-free) At least for my data (lots of
> values, limited range), it appears to speed things up tremendously. I
> haven't measured more general cases in any detail, though. And one
> obvious drawback may be that it's not stable, which I think can be
> alleviated by
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> There was some concern about the lack of laziness and stack
> overflows [of merge- vs. quicksort], but the general concensus was
> that merge sort was a better choice. Feel free to argue otherwise
> :)
I'll hereby argue for using a quicksort implemen
Alastair Reid <[EMAIL PROTECTED]> writes:
> > For instance, hmake manages just fine with a
> > simplified parser that understands only token streams introduced by
> > the keyword 'import' at the beginning of a line ...
>
> It's true that many people layout their code in such a way that this
> wi
> I agree it can be delicate, but there is no real need for a full
> Haskell parser. For instance, hmake manages just fine with a
> simplified parser that understands only token streams introduced by
> the keyword 'import' at the beginning of a line, modified by
> respecting cpp directives and H
> > I am trying to compile ghc on my powermac (debian 3.0)
>
> I'm afraid we don't have a port for your system at the moment.
> Furthermore the road to porting GHC is long and tortuous :-(
On the other hand, if you just want any Haskell compiler, nhc98 builds
and installs very easily on ppc-linu
> I am trying to compile ghc on my powermac (debian 3.0)
> apt-get source ghc5 succeed,
> but to do the actual compilation, it need a working ghc
> (and there is no binary package in the list)
>
> How can I get a (even old) working ghc ?
I'm afraid we don't have a port for your system at the mo
> > Aha! GHCi (and ghc --make) has a pre-pass that looks through the
> > file for import declarations so it can build the dependency tree,
> > and it does this without using a proper Haskell parser. I'll bet
> > it's ignoring the CPP directives. Probably it should flag an error,
> > I'll look i
> > Aha! GHCi (and ghc --make) has a pre-pass that looks through the
> > file for import declarations so it can build the dependency tree,
> > and it does this without using a proper Haskell parser. I'll bet
> > it's ignoring the CPP directives. Probably it should flag an error,
> > I'll look i
> Aha! GHCi (and ghc --make) has a pre-pass that looks through the
> file for import declarations so it can build the dependency tree,
> and it does this without using a proper Haskell parser. I'll bet
> it's ignoring the CPP directives. Probably it should flag an error,
> I'll look into it.
> | 5.02 uses quicksort, but 5.04 will use mergesort
> | instead which has much more predictable performance
> | behaviour.
>
> What implementation of mergesort are you using? (Could you
> send me code?)
It's Ian Lynagh's implementation, from a thread on this list recently:
http://www.haske
> > > I think the problem is that GHCi doesn't respect #ifdef
> > > conditional compilation.
> >
> > I wasn't aware of any bugs in that area, can anyone provide
> some sample
> > code? (and I'm surprised, because GHCi just runs cpp in
> the same way as
> > GHC).
>
> Ah, I think it is probably
Colin Runciman <[EMAIL PROTECTED]> writes:
> Also, curiously enough, it could just as well be the problem that your
> int-sorting phase has too *little* sorting to do, as this common
> version of quickSort degenerates both for in-order and reverse-order
> inputs.
*lights go on*
Of course! Whil
> > 5.02 uses quicksort,
>
> That's funny, since I see quadratic scaling, I must be hitting worst
> case both times? 'sort' and 'sortBy' *are* implemented in the same
> way, right?
It's possible, I suppose. Yes, sort is defined in terms of sortBy.
Simon
__
Ketil Z. Malde wrote:
>>5.02 uses quicksort,
>>
>That's funny, since I see quadratic scaling, I must be hitting worst
>case both times? 'sort' and 'sortBy' *are* implemented in the same
>way, right?
>
Implementations of QuickSort on lists usually take the easy option of
using the head of the li
19 matches
Mail list logo
