Re: Another question about monads and linearity
Patrick Logan <[EMAIL PROTECTED]> writes:
> In "Rolling Your Own Mutable ADT: A Connection Between Linear Types
> and Monads", p. 1, Chen and Hudak write:
>
> There are few formal connections between monads and
> single-threaded state... For any state-transformer monad... there
> is a trivial operation... that will instantly destroy any hope for
> single-threadedness: getState s = (s, s)
>
> In day-to-day Haskell 1.3 programming what is the solution to this
> problem? If a program is using a C interface to create a mutable
> state, say an external database, what is the simplest way of
> encapsulating the state so that this "trivial operation" cannot be
> defined except by the original author?
1) Visually inspect the implementation of your monad.
You might apply Chen and Hudak's technique or you might just rely on
your own intuition - simple cases aren't too hard.
2) Take a little time to decide what you should export and what you shouldn't.
Suppose you write a little state-transformer monad:
newtype S s a = MkS (s -> (a,s))
unMkS :: S s a -> (s -> (a,s))
unMkS (MkS x) = x
instance Monad S where
m >>= k = MkS (\ s1 -> case unMkS m s1 of { (a,s2) -> unMkS (k a) s2 })
return a = MkS (\ s -> (a,s))
getS :: S s s
getS = MkS (\ s -> (s,s))
setS :: s -> S s ()
setS s = MkS (\ _ -> ((),s))
Obviously you want to export S, >>=, return, getS and setS.
You also want to prevent people from creating random state transformer
functions - so we'd better hide the MkS.
I don't think there's any harm in exporting unMkS, but I don't see
any point in doing so and it's best to keep your data types abstract.
Here's what your export list should look like:
module StateTransformer
( S -- export the type "S" but not its constructors
, getS -- export the state modifiers
, setS
-- no need to export >>= and return - they're automatically exported
) where
Hope this helps!
--
Alastair Reid Yale Haskell Project Hacker
[EMAIL PROTECTED] http://WWW.CS.Yale.EDU/homes/reid-alastair/
Another question about monads and linearity
In "Rolling Your Own Mutable ADT: A Connection Between Linear Types and Monads", p. 1, Chen and Hudak write: There are few formal connections between monads and single-threaded state... For any state-transformer monad... there is a trivial operation... that will instantly destroy any hope for single-threadedness: getState s = (s, s) In day-to-day Haskell 1.3 programming what is the solution to this problem? If a program is using a C interface to create a mutable state, say an external database, what is the simplest way of encapsulating the state so that this "trivial operation" cannot be defined except by the original author? One problem I have with the hanful of papers I have read so far is separating the reports about what is possible to implement in some hypothetical language from the reports about what is possible in some existing implementation of, say, Haskell 1.3. If I attempt to do something in Haskell, and I fail, I am not sure whether it is the compiler telling me my goal is impossible or if it is telling me I haven't stated my goal correctly. Thanks from a beginner. -- Patrick Logan mailto:[EMAIL PROTECTED] Voice 503-533-3365Fax 503-629-8556 Gemstone Systems, Inc http://www.gemstone.com
Re: Monads and Linear Logic
> In general laymen's terms, what are the performance and expressiveness > issues in comparing monads with linear objects? You may want to glance at the latest version of `How to Declare an Imperative' (Computing Surveys, to appear), which explicitly makes this comparison. It's available via my home page. -- P --- Philip Wadler [EMAIL PROTECTED] Bell Laboratories http://cm.bell-labs.com/cm/cs/who/wadler/ Lucent Technologies office: +1 908 582 4004 600 Mountain Ave, Room 2T-304 fax: +1 908 582 5857 Murray Hill, NJ 07974-0636 USA home: +1 908 626 9252 ---
Monads and Linear Logic
I am stretching my imperative brain cells to comprehend(!) monads, and
now their relationship to linear ("unique" in Clean) objects. I have
glanced at Philip Wadler's paper, but the semantics are impenetrable
to me at this point, and I am looking at the issue from a more
"practical" point of view ("practical" in the sense of "practice",
"practitioner", not that theory is impractical!).
My impression is that monads and linear objects are used in
essentially the same way. I have explicitly read how linear objects
allow the compiler to "garbage collect" them at compile time because
the compiler knows exactly how they are used. I assume the same can be
done for monads? Is this done in the good Haskell compilers?
In general laymen's terms, what are the performance and expressiveness
issues in comparing monads with linear objects?
Thanks
--
Patrick Logan mailto:[EMAIL PROTECTED]
Voice 503-533-3365Fax 503-629-8556
Gemstone Systems, Inc http://www.gemstone.com
