In article <[EMAIL PROTECTED]>,
Hal Daume III <[EMAIL PROTECTED]> wrote:
> I spent about a half hour toying around with this and came up with the
> following, which seems to work (in ghci, but not hugs -- question for
> smart people: which is correct, if either?)...
Both are correct. Hugs fails
Hi,
I spent about a half hour toying around with this and came up with the
following, which seems to work (in ghci, but not hugs -- question for
smart people: which is correct, if either?)...
class Mul a b c | a b -> c where
mul :: a -> b -> c-- our standard multiplication, with fundeps
d
Gertjan Kamsteeg wrote:
>
> Ok, here is an attempt. I don't have time to explain, but it's not Myer's
> algorithm.
[snip]
Yes thanks. But it doesn't seem dramatically faster, on my test cases, than the
Myers algorithm version I have developed; indeed I think it's slightly slower.
However my Myers
David Bergman <[EMAIL PROTECTED]> writes:
> One problem, though, is that I would like not to get rid of the CAF,
> since I (presumably wrongly) assume that CAFs are implemented more
> efficiently in Hugs than "normal" definitions. Am I right in this
> assumption?
There isn't much to choose betwee
You are right,
After writing that e-mail I looked at a lot of cases in Hugs, and also
encountered this CAF problem. And, as I pointed out elsewhere, the "last
call optimisation" is not very interesting in the lazy evaluation
scenario...
One problem, though, is that I would like not to get rid of
"David Bergman" <[EMAIL PROTECTED]> writes:
> Note: In an unoptimized scenario, such as
> with Hugs, you do indeed run out of memory in your "loop" (after
> some 4 iterations) not having the recursion in the last
> call. Even loops not constructing cons cells do, such as
> loop 0 = retu
