Haskellians,
Some monads come with take-out options, e.g.
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 _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
2008/11/24 Greg Meredith <[hidden email]>
Haskellians, I think the take-out option for IO is usually called 'main'. :) Jason _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Greg Meredith
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%3AFoldable) and Traversable (http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Traversable.html#t%3ATraversable) jcc _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
Jonathan,
Nice! Thanks. In addition to implementations, do we have more mathematical accounts? Let me expose more of my motives.
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 <[hidden email]> wrote:
-- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105 +1 206.650.3740 http://biosimilarity.blogspot.com _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Greg Meredith
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⑈ _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Greg Meredith
> - 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. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Greg Meredith
On 2008 Nov 24, at 17:06, Greg Meredith wrote:
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] [hidden email] system administrator [openafs,heimdal,too many hats] [hidden email] electrical and computer engineering, carnegie mellon university KF8NH _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
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 <[hidden email]> wrote:
-- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105 +1 206.650.3740 http://biosimilarity.blogspot.com _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Claus Reinke
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.
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 <[hidden email]> - i am interested in a first-principles notion of data. Neither lambda -- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105 +1 206.650.3740 http://biosimilarity.blogspot.com _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Greg Meredith
John,
You write: Yes, you are describing 'co-monads'. Good catch, but actually, that's too weak. i'm requesting something that is both a monad and a co-monad. That makes it something like a bi-algebra, or a Hopf algebra. This, however, is not the full story. i'm looking for a reference to the full story. Surely, someone has already developed this theory.
Best wishes, --greg From: John Meacham <[hidden email]>
Subject: Re: [Haskell-cafe] monads with take-out options To: [hidden email] Message-ID: <[hidden email]> Content-Type: text/plain; charset=utf-8 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⑈ -- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105 +1 206.650.3740 http://biosimilarity.blogspot.com _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Greg Meredith
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 _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Greg Meredith
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 _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
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 _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
Free forum by Nabble | Edit this page |