Paul writes,
I think it's important to realize that laws aren't being entirely
lost -- they're just being weakened a (wee) bit, in the form of
carrying an extra constraint. For example, eta conversion:
\x -> f x = f
must simply be modified slightly:
\x -
Following up this discussion on
which laws are there in the presence of lifting,
which are not, and which one do we actually care about,
here is another observation.
On most occasions when you (well, I actually) write a datatype,
you think about it inductively.
In a lazy language however, you ge
Phil writes:
> In the absence of convincing answers, I'd rather have as many laws
> as possible, hence my preference for unlifted tuples and products.
Here's another law that I find useful:
If we write
f p = p
where p is some pattern&expression then I expect f to be the identity
func
If Lennart was asking, `Shall we make laws a paramount design feature
of Haskell, and therefore go for unlifted tuples, unlifted functions,
and no n+k or literal patterns', my answer would be `let's go for it'.
But I suspect what Lennart is really asking is `Shall we ignore laws,
have lifted tup
Indeed. Notice that there is a similar difference between call-by-need
and call-by-value beta:
(\x -> u) t = u[t/x] call-by-need
(\x -> u) t = u[t/x] if t /= _|_call-by-value
But here we seem to think the difference is important.
Paul and Phil write,
| What are the disadvantages of having a lifted function space?
|
| I think the main one is that we lose unrestricted eta
| conversion. But maybe that's not such a big deal either.
|
| We keep claiming that functional languages are good because they
| sa
For all those having problems compiling Happy with ghc version 0.16,
the solution is to compile the module ProduceCode.lhs without
optimisation. A small patch to the Makefile can be found on
ftp.dcs.gla.ac.uk in the file pub/haskell/happy/happy-0.7-0.7.1.patch.
Also, we didn't make it clear th
I've separated this from my previous note, because it's about the
precise question of strictness annotations rather than the more general
question of laws.
I would rather tell someone that to define a new type exactly
isomorphic to an old type they need to write
newtype Type = Construc
Paul writes,
What are the disadvantages of having a lifted function space?
I think the main one is that we lose unrestricted eta
conversion. But maybe that's not such a big deal either.
We keep claiming that functional languages are good because they
satisfy lots of la
I would rather tell someone that to define a new type exactly
isomorphic to an old type they need to write
newtype Type = Constructor typeexp
then tell them that they need to write
data Type = Constructor !typeexp
The latter smacks too much of magic. This is clearly a m
I think it's important to realize that laws aren't being entirely
lost -- they're just being weakened a (wee) bit, in the form of
carrying an extra constraint. For example, eta conversion:
\x -> f x = f
must simply be modified slightly:
\x -> f x = fif f /= _|_
(I should al
11 matches
Mail list logo
