* My taste is that isomorphic possibly-abstract types should get a new kind
of type declaration (newtype, isotype, or whatever), perhaps defined to be
exactly equivalent to a algebraic data type with just one strict
constructor. But I don't feel strongly about this.
(At least
I have written a Haskell library that enables you to write network
servers in Haskell, using the RPC (Remote Procedure Call) protocol.
Currently, the library works under HBC only (it uses the Native class).
Servers written with the RPCServer library are run through the inetd(8C)
daemon. All it
The bottom line: Equational reasoning in a typed language needs to
take account of types.
For those who would like me to go into a little more detail:
Warren has described a puzzling situation in which the two similarly
defined functions:
f1 x y = const (show x == show y)
Just a small addendum to Mark's response to Warren:
Overloading (even just polymorphism, as Mark says) does compromise
equational reasoning, in much the same way that lexical scoping does.
That is x = y |- f x = f y , provided it's the same x and the same y.
Cheers,
--Joe
I think we should be pretty cautious about jumping in with lifed function
spaces. I have come up with two distinct unintended effects. While neither
is fatal to the idea, I don't think either obvious, and I am nervous that
others may pop out of the woodwork somewhere down the road (to mix
Simon writes
| I have never, never been tripped up by the liftedness of tuples, but the
| argument that ``we are prepared to pay for laziness so why not this too''
| has a certain masochistic charm. I'll try the effect on performance of
| making all tuple-matching lazy in the nofib suite.
Good
