I finally understood that George Russell's Library is not really about global
variables. Rather it is about what I want to call 'execution contexts', which
are -- as Marcin Kowalczyk observed -- a restricted form of dynamically
scoped variables.
[NB: Another (maybe better) name would have been
On 27 Nov 2004, at 00:59, Benjamin Franksen wrote:
I finally understood that George Russell's Library is not really about
global
variables. Rather it is about what I want to call 'execution
contexts', which
are -- as Marcin Kowalczyk observed -- a restricted form of dynamically
scoped variables.
Jules Bean wrote:
A problem is the ability to pass callbacks to external libraries...
Why not just put all the state in a record, then there's only one thing to
pass around... you can use the state monad to hide this (or the state monad
transformer if you need to layer over IO) then use partial fun
On Sat, 27 Nov 2004, Benjamin Franksen wrote:
> An execution context is a mutable finite map from types to (monomorphic)
> values. Each IO action implicitly carries exactly one such map and by default
> passes it on to the actions that follow.
Execution contexts sound a good description of them.
A general point on top-level TWIs. It occurs to me that all variables
are local to
something (function, object, thread, process, machine, network,
world...). I think it
is an error to limit Haskells domain. If we allow unique per process
variables (top-level
TWI's) we limit our level of abstract
On Saturday 27 November 2004 17:10, you wrote:
> On Sat, 27 Nov 2004, Benjamin Franksen wrote:
> > An execution context is a mutable finite map from types to (monomorphic)
> > values. Each IO action implicitly carries exactly one such map and by
> > default passes it on to the actions that follow.
On Saturday 27 November 2004 17:55, you wrote:
> A general point on top-level TWIs. It occurs to me that all variables
> are local to
> something (function, object, thread, process, machine, network,
> world...).
> [...]
> It seems to me the object model fits perfectly, and what people are
> trying
On Sat, 27 Nov 2004, Benjamin Franksen wrote:
> I would think that with ACIO we have a nice mathematical
> characterization for the IO actions that would be "safe" even at the
> top-level. ("Safe" meaning mainly that we do not open a can-of-worms
> with regard to execution order.) I don't know how
Ben,
On Sat, 27 Nov 2004, Benjamin Franksen wrote (apropos ACIO topdecls):
> ... a highly controversial new language feature.
The language feature is easily done, and just what has been happening all
along:
type ACIO = IO
declare :: ACIO a -> a
{-# NOINLINE declare #-}
declare e = unsa
Benjamin Franksen wrote:
Timber (formerly O'Haskell) has gone this way. Its object model is defined
(and in fact was implemented) by a straight-forward translation into a
(state) reader monad transformer over the IO monad. It is noteworthy that in
this translation the (local) state of a Timber o
On Sunday 28 November 2004 13:53, Keean Schupke wrote:
> ... here is an example object
> in actuall Haskell code using the HList library...
>
> >point = do
> > x <- newIORef 0
> > returnIO $ mutableX .=. x
> > .*. getX .=. readIORef x
> > .*. moveD .=. (\d -> modifyIORef
11 matches
Mail list logo
