Current situation regarding global IORefs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Current situation regarding global IORefs

Lennart Augustsson
Adrian Hey wrote:

>> I've written about 50000 lines of USB devices drivers for *BSD (in C).
>> They work from the bare metal and up.  They contain no global
>> mutable state (except for variables that define debugging levels,
>> because you need to access these from the in-kernel debugger).
>
> Yes, I was aware of this. But with all due respect, if you're running
> with an OS already present (not what I would call bare metal :-), your
> device driver alone is not the entire IO sub-system. I'm not sure
> what you mean by it having no mutable state. Do you mean no top level
> mutable state, or do you mean there is no mutable state whatsoever
> associated with a particular USB port(device..whatever)?

I said "no *global* mutable state", by which I meant no global
variables.  Of course there's mutable state.  This is C after all. :)
(And it would there in Haskell too.)

And yes, somewhere there's some global mutable state in the OS.
I've never claimed that it should be totally forbidden.  Various
circumstances forces it upon us.  What I've been claiming is that
it should be avoided where possible.  Which is almost always.

        -- Lennart

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Current situation regarding global IORefs

Brian Hulley
Lennart Augustsson wrote:
> And yes, somewhere there's some global mutable state in the OS.
> I've never claimed that it should be totally forbidden.  Various
> circumstances forces it upon us.  What I've been claiming is that
> it should be avoided where possible.  Which is almost always.

Thus there seems to be agreement that whereas this should be avoided where
possible, it is still needed in some cases.

Therefore the question arises as to how to safely incorporate this into the
language. As everyone knows, use of unsafePerformIO could break the type
system without a programmer knowing it, but I think I am right in saying
that if only monomorphic refs were allowed at the top level, type safety
would be ensured (so there would be no need for the truly horrible value
restriction that infects the whole of SML for example)

Therefore I propose a new keyword to define monomorphic top level IORefs,
something like:

augment ref = monomorphicvalue -- just a plain value not a monadic
computation

where "augment" refers to the augmentation of the RealWorld state by the
state of ref as in John's suggestion to use "augmented IO" in preference to
"global mutable state"

The use of a plain value to initialize the ref rather than a monadic
computation would ensure that there would be no problems with trying to work
out which order to initialize top level refs that are dependent on values of
refs in other modules since there could be no dependencies.

Regards, Brian.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Current situation regarding global IORefs

Brian Hulley
Brian Hulley wrote:
> The use of a plain value to initialize the ref rather than a monadic
> computation would ensure that there would be no problems with trying
> to work out which order to initialize top level refs that are
> dependent on values of refs in other modules since there could be no
> dependencies.

I meant to say that while there *could* be dependencies I don't think they
would be any different from the dependencies that can exist at the moment
with one value depending on another which in turn is defined in terms of the
first either within a module or between mutually recursive modules.

Also, to qualify my suggestion, I am not 100% sure that it would be powerful
enough for all uses - perhaps monadic computations are needed in some cases
to init global refs?

Regards, Brian.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Current situation regarding global IORefs

Adrian Hey
In reply to this post by Brian Hulley
Brian Hulley wrote:
> The use of a plain value to initialize the ref rather than a monadic
> computation would ensure that there would be no problems with trying to
> work out which order to initialize top level refs that are dependent on
> values of refs in other modules since there could be no dependencies.

I'm not sure what problem you see with the ACIO monad proposal. It
was designed to prevent the kind of ordering dependency problems
which (I think) you're refering to. You can't read or write
IORefs/MVars or do any other "real IO" operation from ACIO.
All you can do is create them (and more complex data structures
based on them). So they could be evaluated at compile time, in
principle (AFAICS etc..). I think it should also be possible to
fork threads from ACIO, provided you arrange that they're initially
blocked on an empty MVar or something.

If it turns out that that isn't enough to properly initialise them
(like you need to do real IO), then you just can't have them as
top level identifiers. But you can still use something like the
"oneShot" function to implement "get" actions at the top level (in
the IO monad).

Regards
--
Adrian Hey

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Current situation regarding global IORefs

Brian Hulley
Adrian Hey wrote:

> Brian Hulley wrote:
>> The use of a plain value to initialize the ref rather than a monadic
>> computation would ensure that there would be no problems with trying
>> to work out which order to initialize top level refs that are
>> dependent on values of refs in other modules since there could be no
>> dependencies.
>
> I'm not sure what problem you see with the ACIO monad proposal. It
> was designed to prevent the kind of ordering dependency problems
> which (I think) you're refering to. You can't read or write
> IORefs/MVars or do any other "real IO" operation from ACIO.
> All you can do is create them (and more complex data structures
> based on them). So they could be evaluated at compile time, in
> principle (AFAICS etc..). I think it should also be possible to
> fork threads from ACIO, provided you arrange that they're initially
> blocked on an empty MVar or something.
>
> If it turns out that that isn't enough to properly initialise them
> (like you need to do real IO), then you just can't have them as
> top level identifiers. But you can still use something like the
> "oneShot" function to implement "get" actions at the top level (in
> the IO monad).

I was thinking that there would be a problem with polymorphic refs but now I
think I understand that there would not be a problem, seeing the description
of ACIO in
http://www.haskell.org//pipermail/haskell-cafe/2004-November/007664.html 
where it is clear that the ACIO actions are just prepended to main.

So I'll retract my proposal in favour of ACIO :-)

Regards, Brian.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Current situation regarding global IORefs

Tony Finch
In reply to this post by Lennart Augustsson
On Sat, 29 Apr 2006, Lennart Augustsson wrote:
>
> And yes, somewhere there's some global mutable state in the OS.
> I've never claimed that it should be totally forbidden.  Various
> circumstances forces it upon us.  What I've been claiming is that
> it should be avoided where possible.  Which is almost always.

The strict object-capability style of programming makes this a strict
rule to prevent capabilities from leaking.
http://www.erights.org/talks/thesis/

Tony.
--
f.a.n.finch  <[hidden email]>  http://dotat.at/
VIKING NORTH UTSIRE SOUTH UTSIRE: SOUTH 7 OR GALE 8, OCCASIONALLY SEVERE GALE
9 IN VIKING AND NORTH UTSIRE, DECREASING 5 OR 6, THEN VEERING SOUTHWEST 6 OR 7
IN VIKING. RAIN AT TIMES. MODERATE OR GOOD.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12