Simon notes that lifted functions prevent certain optimisations, and
then Joe wonders if lifting tuples prevents optimisations. Arvind has
already answered this question. Unlifted tuples satisfy the type
isomorphism
(a,(b,c)) = (a,b,c)
which is heavily used for optimising Id, but is
Here are two more legal problems, ie problems concerning (broken) laws. The
first is a problem with lifted functions spaces (even though I voted for them
before), similar to Simon's recent "Effect 1". Consider:
f [] = \y -> e1 g [] y = e1
f (x:xs) = \y -> e2 g (x:xs) y = e2
Obfuscated Haskell Code Contest
===
THE TIME HAS COME!
Haskell has now come of age and it is time to prove that we can do as
good as C programmers can. Thus, the time has come for an obfuscated
Haskell code contest. The contest is
Some people have referred to semantic issues and Abramsky and Ong's work
when contributing to the lifted/unlifted debate. I think it would be fair
to summarise them as follows.
Pro lifting
===
The simplest possible lambda calculus has lifting in its canonical model as
soon as "laziness"
Warren makes an excellent point, though he doesn't highlight it:
unlifted tuples are INCOMPATIBLE with seq
By "incompatible" I mean that you need parallel specualative evaluation
to implement it. So a truly polymorphic seq is out. That takes us back
to an overloaded version, except t
> Simon says:
> Warren makes an excellent point, though he doesn't highlight it:
>
> unlifted tuples are INCOMPATIBLE with seq
>
> The reason for this is that we can't implement unlifted tuples directly at
> all. Instead, we simulate them by making pattern matching lazy, so that
>
More on liftings:
In our FPCA 91 paper, Simon and I came to the conclusion that the "proper"
way to give semantics to data declarations was, as follows. If
data T = A U V | B W
then the model for T (written here T*) is
T* = ((U* x V*) + W*)_\bot
where the x is pure domain product, the +
>By "incompatible" I mean that you need parallel specualative evaluation
>to implement it. So a truly polymorphic seq is out. That takes us back
>to an overloaded version, except that seq couldn't have an instance for
>(unlifted) tuples!
At the risk of repeating myself: this is exactly right
I have dropped a snapshot of our current Glasgow Haskell sources on
ftp.dcs.glasgow.ac.uk, in pub/haskell/glasgow/working/, in
ghc-0.18-src.tar.gz (3MB, gzipped, probably unpacks to about 10MB).
This version, 0.18, is strictly a "hacker's release". The attached
ghc/README file provides a few de
Simon writes
| Warren makes an excellent point, though he doesn't highlight it:
|
| unlifted tuples are INCOMPATIBLE with seq
|
| By "incompatible" I mean that you need parallel specualative evaluation
| to implement it. So a truly polymorphic seq is out. That takes us back
| to an overlo
10 matches
Mail list logo
