monads with take-out options
Haskellians, Some monads come with take-out options, e.g. - List - Set In the sense that if unit : A -> List A is given by unit a = [a], then taking the head of a list can be used to retrieve values from inside the monad. Some monads do not come with take-out options, IO being a notorious example. Some monads, like Maybe, sit on the fence about take-out. They'll provide it when it's available. Now, are there references for a theory of monads and take-out options? For example, it seems that all sensible notions of containers have take-out. Can we make the leap and define a container as a monad with a notion of take-out? Has this been done? Are there reasons for not doing? Can we say what conditions are necessary to ensure a notion of take-out? Best wishes, --greg -- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105 +1 206.650.3740 http://biosimilarity.blogspot.com
2008/11/24 Greg Meredith
Haskellians, Some monads come with take-out options, e.g.
- List - Set
In the sense that if unit : A -> List A is given by unit a = [a], then taking the head of a list can be used to retrieve values from inside the monad.
Some monads do not come with take-out options, IO being a notorious example.
I think the take-out option for IO is usually called 'main'. :) Jason
On Mon, 2008-11-24 at 14:06 -0800, Greg Meredith wrote:
Haskellians,
Some monads come with take-out options, e.g. * List * Set In the sense that if unit : A -> List A is given by unit a = [a], then taking the head of a list can be used to retrieve values from inside the monad.
Some monads do not come with take-out options, IO being a notorious example.
Some monads, like Maybe, sit on the fence about take-out. They'll provide it when it's available.
It might be pointed out that List and Set are also in this region. In fact, Maybe is better, in this regard, since you know, if fromJust succeeds, that it will only have once value to return. head might find one value to return, no values, or even multiple values. A better example of a monad that always has a left inverse to return is ((,) w), where w is a monoid. In this case, snd . return = id :: a -> a as desired (we always have the left inverses join . return = id :: m a -> m a where join a = a >>= id).
Now, are there references for a theory of monads and take-out options? For example, it seems that all sensible notions of containers have take-out.
Sounds reasonable. Foldable gives you something: foldr const undefined will pull out the last value visited by foldr, and agrees with head at [].
Can we make the leap and define a container as a monad with a notion of take-out?
If you want. I'd rather define a container to be Traversable; it doesn't exclude anything interesting (that I'm aware of), and is mostly more powerful.
Has this been done?
Are you familiar at all with Foldable (http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Foldable.html#t%...) and Traversable (http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Traversable.html...) jcc
Jonathan,
Nice! Thanks. In addition to implementations, do we have more mathematical
accounts? Let me expose more of my motives.
- i am interested in a first-principles notion of data. Neither lambda
nor π-calculus come with a criterion for determining which terms represent
data and which programs. You can shoe-horn in such notions -- and it is
clear that practical programming relies on such a separation -- but along
come nice abstractions like generic programming and the boundary starts
moving again. (Note, also that one of the reasons i mention π-calculus is
because when you start shipping data between processes you'd like to know
that this term really is data and not some nasty little program...) One step
towards a first-principles characterization of data (as separate from
program) is a first-principles characterization of containers.
- Along these lines Barry Jay's pattern-matching calculus is an
intriguing step towards such a characterization. This also links up with
Foldable and Traversable.
- i also looked at variants of Wischik's fusion calculus in which
Abramsky's proof expressions characterize the notion of shippable data.
(Part of the intuition here is that shippable data really ought to have a
terminating access property for access to some interior region.
The linear
types for proof expressions guarantee such a property for all well-typed
terms.)
- There is a real tension between nominal strategies and structural
strategies for accessing data. This is very stark when one starts adding
notions of data to the π-calculus -- which is entirely nominal in
characterization. Moreover, accessing some piece of data by path is natural,
obvious and programmatically extensible. Accessing something by name is
fast. These two ideas come together if one's nominal technology (think
Gabbay-Pitt's freshness widgetry) comes with a notion of names that have
structure.*
- Finally, i think the notion of take-out option has something to do with
being able to demarcate regions. In this sense i think there is a very deep
connection with Oleg's investigations of delimited continuations and --
forgive the leap -- Linda tuple spaces.
As i've tried to indicate, in much the same way that monad is a very, very
general abstraction, i believe that there are suitably general abstractions
that account for a broad range of phenomena and still usefully separate a
notion of data from a notion of program. The category theoretic account of
monad plays a very central role in exposing the generality of the
abstraction (while Haskell's presentation has played a very central role in
understanding the utility of such a general abstractin). A similarly
axiomatic account of the separation of program from data could have
applicability and utility we haven't even dreamed of yet.
Best wishes,
--greg
* i simply cannot resist re-counting an insight that i got from Walter
Fontana, Harvard Systems Biology, when we worked together. In some sense the
dividing line between alchemy and chemistry is the periodic table. Before
the development of the periodic table a good deal of human investigation of
material properties could be seen as falling under the rubric alchemy. After
it, chemistry. If you stare at the periodic table you see that the element
names do not matter. They are merely convenient ways of referring to the
positional information of the table. From a position in the table you can
account for and predict all kind of properties of elements (notice that all
the noble gases line up on the right!). Positions in the table -- kinds of
element -- can be seen as 'names with structure', the structure of which
determines the properties of instances of said kind. i believe that a
first-principles account of the separation of program and data could have as
big an impact on our understanding of the properties of computation as the
development of the periodic table had on our understanding of material
properties.
On Mon, Nov 24, 2008 at 2:30 PM, Jonathan Cast
On Mon, 2008-11-24 at 14:06 -0800, Greg Meredith wrote:
Haskellians,
Some monads come with take-out options, e.g. * List * Set In the sense that if unit : A -> List A is given by unit a = [a], then taking the head of a list can be used to retrieve values from inside the monad.
Some monads do not come with take-out options, IO being a notorious example.
Some monads, like Maybe, sit on the fence about take-out. They'll provide it when it's available.
It might be pointed out that List and Set are also in this region. In fact, Maybe is better, in this regard, since you know, if fromJust succeeds, that it will only have once value to return. head might find one value to return, no values, or even multiple values.
A better example of a monad that always has a left inverse to return is ((,) w), where w is a monoid. In this case,
snd . return = id :: a -> a
as desired (we always have the left inverses
join . return = id :: m a -> m a
where join a = a >>= id).
Now, are there references for a theory of monads and take-out options? For example, it seems that all sensible notions of containers have take-out.
Sounds reasonable. Foldable gives you something:
foldr const undefined
will pull out the last value visited by foldr, and agrees with head at [].
Can we make the leap and define a container as a monad with a notion of take-out?
If you want. I'd rather define a container to be Traversable; it doesn't exclude anything interesting (that I'm aware of), and is mostly more powerful.
Has this been done?
Are you familiar at all with Foldable ( http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Foldable.html#t%...) and Traversable ( http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Traversable.html... )
jcc
-- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105 +1 206.650.3740 http://biosimilarity.blogspot.com
- i am interested in a first-principles notion of data. Neither lambda nor π-calculus come with a criterion for determining which terms represent data and which programs. You can shoe-horn in such notions -- and it is clear that practical programming relies on such a separation -- but along come nice abstractions like generic programming and the boundary starts moving again. (Note, also that one of the reasons i mention π-calculus is because when you start shipping data between processes you'd like to know that this term really is data and not some nasty little program...)
I wouldn't call the usual representations of data in lambda shoe-horned (but perhaps you meant the criterion for distinguishing programs from data, not the notion of data?). Exposing data structures as nothing but placeholders for the contexts operating on their components, by making the structure components parameters to yet-to-be-determined continuations, seems to be as reduced to first-principles as one can get. It is also close to the old saying that "data are just dumb programs" (does anyone know who originated that phrase?) - when storage was tight, programmers couldn't always afford to fill it with dead code, so they encoded data in (the state of executing) their routines. When data was separated from real program code, associating data with the code needed to interpret it was still common. When high-level languages came along, treating programs as data (via reflective meta- programming, not higher order functions) remained desirable in some communities. Procedural abstraction was investigated as an alternative to abstract data types. Shipping an interpreter to run stored code was sometimes used to reduce memory footprint. If your interest is in security of mobile code, I doubt that you want to distinguish programs and data - "non-program" data which, when interpreted by otherwise safe-looking code, does nasty things, isn't much safer than code that does non-safe things directly. Unless you rule out code which may, depending on the data it operates on, do unwanted things, which is tricky without restricting expressiveness. More likely, you want to distinguish different kinds/types of programs/data, in terms of what using them together can do (in terms of pi-calculus, you're interested in typing process communication, restricting access to certain resources, or limiting communication to certain protocols). In the presence of suitably expressive type systems, procedural data abstractions need not be any less "safe" than dead bits interpreted by a separate program. Or if reasoning by suitable observational equivalences tells you that a piece of code can't do anything unsafe, does it matter whether that piece is program or data? That may be too simplistic for your purposes, but I thought I'd put in a word for the representation of data structures in lambda. Claus Ps. there have been lots of variation of pi-calculus, including some targetting more direct programming styles, such as the blue calculus (pi-calculus in direct style, Boudol et al). But I suspect you are aware of all that.
Claus,
Thanks for your thoughtful response. Let me note that fully abstract
semantics for PCF -- a total toy, mind you, just lambda + bools + naturals
-- took some 25 years from characterization of the problem to a solution.
That would seem to indicate shoe-horning, in my book ;-). Moreover, when i
look at proposals to revisit Church versus Parigot encodings for data
structures (ala Oliveira's thesis), i think we are still at the very
beginnings of an understanding of how data fits into algebraic accounts of
computation (such as lambda and π-calculi).
Obviously, we've come a long way. The relationship between types and
pattern-matching, for example, is now heavily exploited and generally a good
thing. But, do we really understand what's at work here -- or is this just
another 'shut up and calculate' situation, like we have in certain areas of
physics. Frankly, i think we are really just starting to understand what
types are and how they relate to programs. This really begs fundamental
questions. Can we give a compelling type-theoretic account of the separation
of program from data?
The existence of such an account has all kinds of implications, too. For
example, the current "classification" of notions of quantity (number) is
entirely one of history and accident.
- Naturals
- Rationals
- Constructible
- Algebraic
- Transcendental
- Reals
- Complex
- Infinitessimal
- ...
Can we give a type theoretic reconstruction of these notions (of traditional
data types) that would unify -- or heaven forbid -- redraw the usual
distinctions along lines that make more sense in terms of applications that
provide value to users? Conway's ideas of numbers as games is remarkably
unifying and captures all numbers in a single elegant data type. Can this
(or something like it) be further rationally partitioned to provide better
notions of numeric type? Is there a point where such an activity hits a wall
and what we thought was data (real numbers; sequences of naturals; ...) are
just too close to programs to be well served by data-centric treatments?
Best wishes,
--greg
2008/11/24 Claus Reinke
- i am interested in a first-principles notion of data. Neither lambda
nor π-calculus come with a criterion for determining which terms represent data and which programs. You can shoe-horn in such notions -- and it is clear that practical programming relies on such a separation -- but along come nice abstractions like generic programming and the boundary starts moving again. (Note, also that one of the reasons i mention π-calculus is because when you start shipping data between processes you'd like to know that this term really is data and not some nasty little program...)
I wouldn't call the usual representations of data in lambda shoe-horned (but perhaps you meant the criterion for distinguishing programs from data, not the notion of data?). Exposing data structures as nothing but placeholders for the contexts operating on their components, by making the structure components parameters to yet-to-be-determined continuations, seems to be as reduced to first-principles as one can get.
It is also close to the old saying that "data are just dumb programs" (does anyone know who originated that phrase?) - when storage was tight, programmers couldn't always afford to fill it with dead code, so they encoded data in (the state of executing) their routines. When data was separated from real program code, associating data with the code needed to interpret it was still common. When high-level languages came along, treating programs as data (via reflective meta- programming, not higher order functions) remained desirable in some communities. Procedural abstraction was investigated as an alternative to abstract data types. Shipping an interpreter to run stored code was sometimes used to reduce memory footprint.
If your interest is in security of mobile code, I doubt that you want to distinguish programs and data - "non-program" data which, when interpreted by otherwise safe-looking code, does nasty things, isn't much safer than code that does non-safe things directly. Unless you rule out code which may, depending on the data it operates on, do unwanted things, which is tricky without restricting expressiveness.
More likely, you want to distinguish different kinds/types of programs/data, in terms of what using them together can do (in terms of pi-calculus, you're interested in typing process communication, restricting access to certain resources, or limiting communication to certain protocols). In the presence of suitably expressive type systems, procedural data abstractions need not be any less "safe" than dead bits interpreted by a separate program. Or if reasoning by suitable observational equivalences tells you that a piece of code can't do anything unsafe, does it matter whether that piece is program or data?
That may be too simplistic for your purposes, but I thought I'd put in a word for the representation of data structures in lambda.
Claus
Ps. there have been lots of variation of pi-calculus, including some targetting more direct programming styles, such as the blue calculus (pi-calculus in direct style, Boudol et al). But I suspect you are aware of all that.
-- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105 +1 206.650.3740 http://biosimilarity.blogspot.com
On Mon, 2008-11-24 at 15:06 -0800, Greg Meredith wrote:
Jonathan,
Nice! Thanks. In addition to implementations, do we have more mathematical accounts? Let me expose more of my motives. * i am interested in a first-principles notion of data.
Hunh. I have to say I'm not. The difference between Bool -> alpha and (alpha, alpha) is not one I've ever felt a need to elaborate. And I'm not sure you *could* elaborate it, within a mathematical context --- which to me means you only work up to isomorphism anyway.
Neither lambda nor π-calculus come with a criterion for determining which terms represent data and which programs.
As you know, lambda-calculus was originally designed to provide a foundation for mathematics in which every mathematical object --- sets, numbers, function, etc. --- would be a function (a lambda-term) under the hood. It was designed to abstract away the distinction between values and functions, not really to express it.
You can shoe-horn in such notions -- and it is clear that practical programming relies on such a separation
What? `Practical programming' in my experience relies on the readiness to see functions as first-class values (as near to data as possible). Implementations want to distinguish them, in various ways --- but then once you draw that distinction, programmers want to use data structures like tries, to get your `data structure' implementation for the program design's `function' types (or some of them...) As near as I can tell, the distinction between data and code is fundamentally one of performance, which makes it quite implementation-dependent. And, for me, boring.
-- but along come nice abstractions like generic programming and the boundary starts moving again. (Note, also that one of the reasons i mention π-calculus is because when you start shipping data between processes you'd like to know that this term really is data and not some nasty little program...)
It's not nice to call my children^Wprograms nasty :) I think, though, that the real problem is to distinguish values with finite canonical forms (which can be communicated to another process in finite time) from values with infinite canonical forms (which cannot). The problem then is defining what a `canonical form' is. But characterizing the problem in terms of data vs. code isn't going to help: \ b -> if b then 0 else 1 is a perfectly good finite canonical form of type Bool -> Int, while repeat 0 is a perfectly good term of type [Int] (a data type!) with no finite canonical form (not even a finite normal form). I'm sure this fails to engage your point, but perhaps it might clarify some points you hadn't considered. jcc
On Mon, Nov 24, 2008 at 02:06:33PM -0800, Greg Meredith wrote:
Now, are there references for a theory of monads and take-out options? For example, it seems that all sensible notions of containers have take-out. Can we make the leap and define a container as a monad with a notion of take-out? Has this been done? Are there reasons for not doing? Can we say what conditions are necessary to ensure a notion of take-out?
Yes, you are describing 'co-monads'. here is an example that a quick web search brought up, and there was a paper on them and their properties published a while ago http://www.eyrie.org/~zednenem/2004/hsce/Control.Comonad.html the duals in that version are extract - return duplicate - join extend - flip (>>=) (more or less) John -- John Meacham - ⑆repetae.net⑆john⑈
On 2008 Nov 24, at 17:06, Greg Meredith wrote:
Now, are there references for a theory of monads and take-out options? For example, it seems that all sensible notions of containers have take-out. Can we make the leap and define a container as a monad with a notion of take-out? Has this been done? Are there reasons for not doing? Can we say what conditions are necessary to ensure a notion of take-out?
Doesn't ST kinda fall outside the pale? (Well, it is a container of sorts, but a very different from Maybe or [].) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
Brandon, i see your point, but how do we sharpen that intuition to a formal characterization? Best wishes, --greg On Mon, Nov 24, 2008 at 10:45 PM, Brandon S. Allbery KF8NH < allbery@ece.cmu.edu> wrote:
On 2008 Nov 24, at 17:06, Greg Meredith wrote:
Now, are there references for a theory of monads and take-out options? For example, it seems that all sensible notions of containers have take-out. Can we make the leap and define a container as a monad with a notion of take-out? Has this been done? Are there reasons for not doing? Can we say what conditions are necessary to ensure a notion of take-out?
Doesn't ST kinda fall outside the pale? (Well, it is a container of sorts, but a very different from Maybe or [].)
-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
-- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105 +1 206.650.3740 http://biosimilarity.blogspot.com
Greg Meredith wrote:
Haskellians,
Some monads come with take-out options, e.g.
* List * Set
In the sense that if unit : A -> List A is given by unit a = [a], then taking the head of a list can be used to retrieve values from inside the monad.
Some monads do not come with take-out options, IO being a notorious example.
Some monads, like Maybe, sit on the fence about take-out. They'll provide it when it's available.
To amplify other people's comments: List A is just as on the fence as Maybe. "[]" plays the role of "Nothing". Some monads require that you put something in, before you take anything out [r -> a, s -> (a,s), known to their friends as reader and state] Error is similar to Maybe, but with a more informative Nothing. Most monads provide some kind of runM :: ## -> m a -> ## a where the ## are meta-syntax, indicating that you might need to pass something in, and you might get something slightly 'funny' out. Something based upon 'a' but not entirely 'a'. The taxonomy of monads is pretty much expressed in the types of these 'run' functions, I think. Jules
On Wed, 2008-11-26 at 19:09 +0000, Jules Bean wrote:
Greg Meredith wrote:
Haskellians,
Some monads come with take-out options, e.g.
* List * Set
In the sense that if unit : A -> List A is given by unit a = [a], then taking the head of a list can be used to retrieve values from inside the monad.
Some monads do not come with take-out options, IO being a notorious example.
Some monads, like Maybe, sit on the fence about take-out. They'll provide it when it's available.
To amplify other people's comments:
List A is just as on the fence as Maybe. "[]" plays the role of "Nothing".
Some monads require that you put something in, before you take anything out [r -> a, s -> (a,s), known to their friends as reader and state]
Error is similar to Maybe, but with a more informative Nothing.
Most monads provide some kind of
runM :: ## -> m a -> ## a
More precisely, runM :: f (m a) -> g a Where f and g are usually functors. Maybe, of course, has the nice property that g = m. jcc
participants (7)
-
Brandon S. Allbery KF8NH -
Claus Reinke -
Greg Meredith -
Jason Dagit -
John Meacham -
Jonathan Cast -
Jules Bean