and is stored for efficiency only.
Second, the definition of hyperstrictness must be quite arbitrary for some
nonstandard extensions. What to do with Dynamic? With ForeignObj
containing StablePtrs inside?
If it is worth, it could be defined as a class, and could be even
automaticelly derivable. I
On 22-Mar-2000, Qrczak [EMAIL PROTECTED] wrote:
On Wed, 22 Mar 2000, Fergus Henderson wrote:
Actually, that raises an interesting question:
should instances of `==' be required to be hyperstrict
in cases where they return `True'?
Certainly no.
First, using (==) for that purpose is
Strictness only improves efficiency and narrows cases when a function is
defined, but it can never improve correctness. There is no code that
requires strictness to work at all.
Unless we use extensions like GHC's Exception or unsafePerformIO. Or use
hGetContents and want to
On Wed, 22 Mar 2000, Frank Atanassow wrote:
But some programs make essential use of bottom in a denotational way,
and then functions defined on the type in question are required to be
strict.
They can't, because each legal function is continuous. If it has a
different value depending on
Suppose Sven implements his `len' function as above, and furthermore
implements a library which depends on this function being hyperstrict.
Suppose next that I implement an instance of `==' that returns `True' without
evaluating the arguments, and then finally suppose a third programmer called
Wed, 22 Mar 2000 15:23:32 +0100 (MET), Bjorn Lisper [EMAIL PROTECTED] pisze:
I think the cleanest solution is to add a method "hseq" to the Eval
class, which is similar to seq but evaluates its first argument
hyperstrictly before returning its second.
You mean "implicit Eval"? Then I would
Me:
I think the cleanest solution is to add a method "hseq" to the Eval
class, which is similar to seq but evaluates its first argument
hyperstrictly before returning its second.
Marcin 'Qrczak' Kowalczyk:
You mean "implicit Eval"? Then I would certainly not call this solution
"clean". Even
Wed, 22 Mar 2000 17:26:25 +0100 (MET), Bjorn Lisper [EMAIL PROTECTED] pisze:
I don't know about full polymorphism (I guess hseq would not work
well for function-typed arguments, for instance), but I know there
are situations where it can be important from a practical perspective
to add
On 22-Mar-2000, Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] wrote:
I'm not convinced that it [hseq] should exist at all. Much can be archieved
by adding strictness flags to data definitions, or at most suitable
problem-specific functions / classes. It should not be *very* important
to
On 21-Mar-2000, Sven Panne [EMAIL PROTECTED] wrote:
Example: length is strict in its argument, but the following
function is hyperstrict (at least according to my definition :-) :
len :: Eq a = [a] - Int
len [] = 0
len (x:xs) | x == x = 1 + len xs
This 'x == x' is folklore for
10 matches
Mail list logo
