Daniel Crealer writes: >I came across interesting concept of monad, and that is >what inspired the following idea. I would just like to know if anyone >thinks it's interesting and if someone has already developed it.
Yes it is interesting, and the fact that you thought of it might mean you have valuable "insight skills" in computing. Similar ideas are already in circulation --since the 70s in the research OS community in fact-- but dressed not in the guise of the monad but rather in the guise of something called a capability as in "capability OSes" like GNOSSIS, KeyKOS, Extremely-Reliable OS, etc, or "capability PLs" like Hewitt's Actors framework, Joule, Mozart/Oz, E and --lately-- dozens of others. A capability is essentially a pointer that is unforgeable because of care taken in implementing the OS or the language runtime. Note that there is something in Unix called a capability which is not a "real" capability and which you can safely ignore. > I download a program >off the Internet that claims to do some interesting transformation on >my data. But I don't trust the application not to send my secret data >back to the web site. I could achieve this by running the program in a >sandbox that doesn't allow it to send data over the Internet. But maybe the >program has legitimate reasons to send data, e.g., the company charges based >on how much data I transform, so the program wants to periodically send >messages to the web site saying it performed some units of work. This is a standard application of capabilities; the downloaded program is said to be "confined" by the local OS or runtime. Unfortunately I am unwilling at this time to learn enough Caml to decipher your pseudo-Caml. If you learn enough Haskell to rewrite it in Haskell I'll take a look. The reason capabilities can do such things as confinement is that they are "totalitarian" in the sense that going through a capability is the *only* way for the programmer to access or consume some interesting set of resources. (In fact, capability OSes and runtimes are carefully audited by security engineers to ensure that property.) Like capabilities, monads can easily be made "totalitarian". In fact, modulo functions with "unsafe" in their name and modulo (the kludge of) semi-closed handles and modulo unintentional "security holes" and modulo maybe one or two other warts I'm not recalling right now, Haskell and GHC's IO monad already is "totalitarian" with respect to most side effects, eg, almost all I/O. While many have suspected a similarity between monads and capabilities, no one to my knowledge has worked out even in principle how to do security engineering of software with monads (so we could be wrong about the similarity). I am uninterested in following up on this similarity, and most capability experts prefer dynamically typed OOPLs in the Smalltalk tradition though in the past a language in the Prolog tradition was used. It is easy to get the impression that OOP is sort of stupid. That's what I thought till I discovered capability PLs. I now think the body of ideas around capability PLs (again mostly dynamically-typed OOPLs these days) is likely to be richer and more scientifically fertile for the long term than FP even. Right now, mostly only security engineers know about it as it is the technically superior way to construct "unhackable" software, but it deserves more attention from computer science researchers. I'm concentrating on on FP for essentially social and economic reasons, not technical superiority to the capability-PL approach. by "social" reason I mean mainly that it is easier to spot (and ignore!) the low-IQ programmers on FP mailing lists whereas on, eg, the average OOP mailing list or newsgroup the low-IQ folks waste a lot of your time. (But the E mailing list mentioned below has a very very bright membership.) A point of intersection between capability PLs and FPLs is that both have been used to formalize financial contracts. Also, E is the only language I know of besides the FPLs where the standard variable-binding construct, namely def foo := bar, introduces an "immutable" variable, namely foo. An "immutable" variable is one that cannot later be assigned a different value. even in the almost-functional language Scheme the variable, namely foo, bound by the standard variable-binding construct, namely (let ((foo bar)) body), can be mutated, namely by (set! foo bar2), and Scheme has no alternative to the let special form that can produce an immutable variable. (In E, there's another construct, namely var foo := bar, that will introduce a mutable variable.) The motivation for E's offering immutable variables is not the standard FP motivation of referential transparency but rather the observation that they make it easier for the programmer to avoid the unintentional creation of certain classes of security holes. The best place on the 'Net to learn about capabilities is on the mailing list (which is at least twice as busy as the Haskell mailing list BTW) for the E programming language at http://www.eros-os.org/pipermail/e-lang/. If you post to this mailing list, please tell them I sent you! I participated on this list till earlier this month. Finally, my favorite intros to capability thinking are: <LI><a href="http://mumble.net/jar/pubs/secureos/";>Rees's 1995 paper "Security Kernel"</a> <LI><a href="http://www.sims.berkeley.edu/~ping/sid/ideus.html#design";>Design of a Secure Desktop Interface, chapter 5 of Ping's draft paper.</a> -- Richard Uhtenwoldt "It's a mammal thing; you wouldn't understand." _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
