[Haskell] Simple IO Regions

[oleg at pobox.com]

Simon Peyton-Jones wrote:

> Previously I've thought of using a nested tuple type
> 	(m1, (m2, (m3 ())))

That was my thought too. But then we need the comparison operation on
those 'm' (which are actually type eigen-variables). Not that it can't
be done (it can, and several examples prove that). But it requires a
little bit too many extensions. It appears there is a way to move the
whole burden of maintaining the set of types (which become the set of
constraints) to the typechecker. That is, to you...


> Why do you need the
> 	instance IN () b
> ?

Don't we need at least one instance in a class so that the typechecker
could resolve the constraint?

Dominic Steinitz wrote:
> Can someone give an explanation of how the marks get built up?

Suppose we have a class TypeEq a b so that the constraint TypeEq holds
whenever a and b are the same. Then the type Int and the type
	TypeEq a Int => a
are kind of equivalent, right? The HList library plays many tricks
like that. The idea is that we can replace a definite type with a type
variable subject to some constraint (which we can fix later on). 
In some respects, constraints are more convenient: they float, their
order does not matter, their duplicates are automatically
eliminated. Just what we need to build a set...
It ``follows'' then that instead of building the union of types, we
can build the union of constraints. The latter operation is trivial:
the typechecker does that all the time. If we restrict the scope of
the type variable by quantification, the scope of the corresponding
constraint is likewise restricted. The quantification also builds
eigen-variables (which are distinct from anything else) -- so we get
'gensym' on the type level for free. That is all there is to it...


Chris Kuklewicz wrote:
> I tweaked the IORegions code using some other ideas from the thread.
>
> qGetChar was just a demo, and has been replaced by liftH, liftH2, and
> liftH3 which should cover all the System.IO hFoo functions.

As Andrew Pimlott has just pointed out on Haskell cafe, liftH
functions should not be exported!

The functions within the IORegions module have unrestricted access to
the naked handle. They have to be careful and trusted:

	-- do not leak the unwrapped handle

	-- do not close the handle
	   (if the handle really needs to be closed,
	    one better just throw an exception or error)

Because liftH accepts an _arbitrary_ function on handles, it
essentially extends the trust to anyone outside of IORegions -- which
defeats the latter's purpose. True, liftH functions are convenient --
but they must be used _inside_ of the module, to build qGetChar,
qPutChar, etc. functions. It is the latter that can be exported.

The idea of regions is that not all operations on handles are
`safe'. Thus we need a way to specifically enumerate which are those
primitive operations that safe. Enumerating lifted versions of
getChar, putChar, etc. in the export list of IORegions is that
enumeration. I'm afraid we have a circumstance where genericity is not
a virtue.