Martin Sulzmann <[EMAIL PROTECTED]> writes:
> - There's a class of MPTC/FD programs which enjoy sound, complete
> and decidable type inference. See Result 1 below. I believe that
> hugs and ghc faithfully implement this class.
> Unfortunately, for advanced type class acrobats this class of
>
On Feb 17, 2006, at 3:30 PM, Ashley Yakeley wrote:
Andy Gill wrote:
I'd like to see a way of enforcing return strictness, that is
where you
have confidence that what a function is returning is fully evaluated.
Imagine a function hstrict;
hstrict :: a -> a
Is this like deepseq, that st
Andy Gill wrote:
I'd like to see a way of enforcing return strictness, that is where you
have confidence that what a function is returning is fully evaluated.
Imagine a function hstrict;
hstrict :: a -> a
Is this like deepseq, that strictly evaluates internal structure using seq?
With
I'd like to see a way of enforcing return strictness, that is where you
have confidence that what a function is returning is fully evaluated.
Imagine a function hstrict;
hstrict :: a -> a
you can define hseq with this.
hseq :: a -> b -> b
hseq a b = hstrict a `seq` b
and $!!.
($!!) :
I'm forwarding an email that Martin Sulzmann asked me to post on his
behalf.
From: Martin Sulzmann <[EMAIL PROTECTED]>
Subject: MPTC/FD dilemma
Here's my take on the MPTC/FD dilemma.
There has been lots of discussion about MPTC/FDs. T
> Most of this discussion on patterns (except for views)
> seems too much focused on concrete data types.
> (regexps for lists: what a horrible thought :-)
> This is just the thing to avoid in software design.
> (Don't expose implementation details, use interfaces etc.)
There's nothing in HaRP tha
Most of this discussion on patterns (except for views)
seems too much focused on concrete data types.
(regexps for lists: what a horrible thought :-)
This is just the thing to avoid in software design.
(Don't expose implementation details, use interfaces etc.)
On the other hand, this is exactly wha
On 2/16/06, Henrik Nilsson <[EMAIL PROTECTED]> wrote:
> Conor and I discussed this over lunch.
>
> Specifically, we talked about whether the right hand side of a pattern
> synonym would be any Haskell pattern (including "_", "~", possibly "!"),
> or restricted to the intersection between the patter
