Serge,
How do you think, is the program (1) equivalent to (2)
in the meaning of Haskell-98 ?
(1) (\ x -> (if p x then foo (g x) else foo (h x))
where
p ... g ... h ... foo ...
)
(2) (\ x -> foo ((if p x then g x else h x)
where
Dean Herrington has mailed me to point out that the metatype is unnecessary:
class Assert a where
assertW :: MVar a -> a -> a
assertR :: MVar a -> a
instance Assert a => Assert [a] where
assertW mv [] = unsafePerformIO $ do putMVar mv []; return []
assertW mv (x:xs) = unsafePerformIO $ do
Claus,
The need to shadow the data types is a bit
annoying, but then the whole generic bit would preferably be
generated anyway. Template Haskell to the rescue, or Drift?-)
Agreed. Current plan is to use Drift
There is still something I don't understand about your
specification: the assertio
Simon,
Does this mean you can womble along with Claus's suggestion? I'm
feeling a bit swamped at the moment, and not keen to undertake another
open-ended implementation exercise. So if you can manage without, and
perhaps use the experience to refine the specification of a Really
Useful Feature,
y to avoid the problems with types is
to use a multi-parameter type class. Little example attached.
So, thanks again Claus!
Regards
Colin R
-- A mini-experiment in concurrent data-driven assertions.
-- Colin Runciman after Claus Reinke after Andy Gill after ...
-- February 2003
import Control.
Claus,
It may be possible to get the two representations together by applying the
predicate to a "reader" for x, generated from x, which would complement
something like Hood's "writer" for x, generated from x. Just as the context
demanding parts of x isn't aware of triggering observations, the p
C.Reinke wrote:
I'm not sure whether I understand what you have in mind
later on, but this first part sounds so remarkably like
something I've seen before, that I'll take my chances.
Do you remember Andy Gill's Hood from long ago?
Inside its implementation, it had a very similar problem:
writin
Simon,
Next idea is to have a function
await :: a -> b -> b
which is rather like 'seq' except that it waits for its first argument
to be evaluated, whereas 'seq' evaluates it. Then you could write a new
version of 'length' which used await before every case expression. Is
that what you had in m
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
Ketil Z. Malde wrote:
>I have what I think is a really strange problem. I have a fair sized
>problem, which involves sorting a data set, first on labels (which are
>Strings) and then on scores (which are Ints).
>
>The strange thing is that string sorting is *vastly* faster than int
>scoring! No
10 matches
Mail list logo
