On Tue, Mar 11, 2008 at 4:01 AM, Adrian Hey <[EMAIL PROTECTED]> wrote:
> > and sorting is
> > meant to be a permutation, so we happily have the situation where this
> > has a correct answer: 2.
>
> > Anything else is incorrect.
>
> Isn't 3 also a permutation? Why is it incorrect?
Because it i
Yes, I have tried both implementations at the start and solved it by
choosing for the following:
type family F a :: * -> *
type FList a x = Either () (a,x)
type instance F [a] = FList a
instance (Functor (F [a])) where
fmap _ (Left _) = Left ()
fmap f (Right (a,x)) = Right (a,f x)
The option was:
On Tue, 11 Mar 2008, Hugo Pacheco wrote:
I know I do not need these constraints, it was just the simplest way I found
to explain the problem.
I have fought about that: I was not expecting F d c ~ F a (c,a) not mean
that F d ~F a /\ c ~(c,a), I thought the whole family was "parameterized".
If I
On Mon, 10 Mar 2008, Neil Mitchell wrote:
I would like to know if in fact there's any difference in practice
between (), [()], i.e. if in practice the difference matters.
Usually, not so much. A lot of Monad functions have _ variants, i.e.
mapM and mapM_. If you don't need the result, use t
Just a few updates on this one:
I've upgraded to bytestring-0.9.0.5 from Darcs, no improvement.
Also this morning I tried using Data.HashMap with Bytestring's readInt
and HashMap's hashInt.. The result was a Stack space overflow :(
God damn it I don't want to have to go back to C++ but soon will
I am trying to port a programme written in Maude, which is a reflective
language based on rewriting logic ( http://maude.cs.uiuc.edu/ ), to
Haskell. I thought using Template Haskell might be a good idea, but I
got stuck and now I am wondering if this is really possible in Haskell.
Let me give an ex
I know I do not need these constraints, it was just the simplest way I found
to explain the problem.
I have fought about that: I was not expecting F d c ~ F a (c,a) not mean
that F d ~F a /\ c ~(c,a), I thought the whole family was "parameterized".
If I encoded the family
type family F a x :: *
Sterling Clover wrote:
> there's no standard way that I know of besides "inspection" to
> determine if code might throw an exception, and this is particularly
> the case with the dreaded lazy IO of prelude functions.
The following old message showed even two ways of doing exactly that
-- in Haske
I am trying to port a programme written in Maude, which is a reflective
language based on rewriting logic ( http://maude.cs.uiuc.edu/ ), to
Haskell. I thought using Template Haskell might be a good idea, but I
got stuck and now I am wondering if this is really possible in Haskell.
Let me give an ex
> Manuel M T Chakravarty:
> Hugo Pacheco:
> > I would simply like the compiler not to use that instance if the
> > equality constraint does not hold, like some another instance
> > dependency constraint, but I assume that is not possible.
>
> This is independent of type families. The selection o
"Krzysztof Skrzętnicki" <[EMAIL PROTECTED]> writes:
> The above results are for 100 Ints x 10 runs, but I don't expect any
> drastic changes in longer run. I leave the interpretation up to you.
Might I suggest (also) testing with numbers of smaller magnitude?
Lots of collisions is another kil
| I think, it won’t find it. As Cale said, it’s a type variable. It’s like
| the “a” in the following definition:
|
| data T a = T a a
|
| I think, Conal Elliott used an operator type variable in order to make his
| code more readable. The (~>) is a type parameter which stands for an arrow
|
Hi Hugo,
I have encoded a type family such that:
type family F a :: * -> *
and a function (I know it is complicated, but I think the problem is self
explanatory):
hyloPara :: (Functor (F a), Functor (F d), F d a ~ F a (a,a), F d c ~ F a
(c,a)) => d -> (F d c -> c) -> (a -> F d a) -> a -> c
h
Are you really sure that your results are correct? I obviously did all my
tests with -O2 on.
Please rerun your tests on the new "framework". Also note that this one
contains tests for three cases:
- sorted
- revsorted
- randomized
From previous results I can guess that with randomized input Yhc's c
Neil Mitchell wrote:
Hi
(sort [a,b]) in the case we have: (compare a b = EQ)
Which of the following 4 possible results are correct/incorrect?
1- [a,a]
2- [a,b]
3- [b,a]
4- [b,b]
Fortunately the Haskell sort is meant to be stable,
I would have said it is meant to be *correct* first an
Jonathan Cast wrote:
On 10 Mar 2008, at 4:00 AM, Adrian Hey wrote:
Neil Mitchell wrote:
2) What does it do with duplicate elements in the list? I expect it
deletes
them. To avoid this, you'd need to use something like fromListWith,
keeping
track of how many duplicates there are, and expan
ok:
>
> On 11 Mar 2008, at 12:27 pm, Krzysztof Skrzętnicki wrote:
>
> >I've written little framework to work on. See sortbench.hs and
> >sortbench.py attachments.
> >Furthermore, I checked Yhc's implementation of sort: it is indeed
> >very fast:
>
> I took his earlier code and plugged yhc's
On Mar 11, 2008, at 0:20 , Chaddaï Fouché wrote:
2008/3/11, David Menendez <[EMAIL PROTECTED]>:
I think Adrian is just arguing that a == b should imply f a == f b,
for all definable f, in which case it doesn't *matter* which of two
equal elements you choose, because there's no semantic diffe
18 matches
Mail list logo
