Informally, a "pure program" an executable such that the stream of bytes entering it totally determines the stream of bytes leaving it. Many useful programs that I would like to write in Haskell don't fall into this category -- for example, network servers -- but a lot of their components do. Can these components can be Haskell functions without IO in their signatures? Though that seems reasonable, it is not, in general, true. For example, System.Info.os is generally treated as pure, though it is not. It's not clear to me how to disambiguate these "born again" values from really pure values. -- _jsn
You're essentially describing functional reactive programming. You end
up with the system being described as pure, reactive values and
plugging IO based streams in at the edges.
Have a look at the wiki description
(http://www.haskell.org/haskellwiki/Functional_Reactive_Programming)
and especially the Reactive library
(http://www.haskell.org/haskellwiki/Reactive).
Theres been a fair amount of work on using frp for distributed,
network-orientated systems. Flask
(http://portal.acm.org/citation.cfm?id=1411203.1411251) and Opis
(http://perso.eleves.bretagne.ens-cachan.fr/~dagand/opis/) are
particularly interesting. Opis really shows the value of using pure
functions by allowing the same reactive system to be run in
production, attached to a debugger, run in a step-by-step simulator or
run in a model checker without altering the systems code.
On Wed, Nov 5, 2008 at 12:12 AM, Jason Dusek
Informally, a "pure program" an executable such that the stream of bytes entering it totally determines the stream of bytes leaving it.
Many useful programs that I would like to write in Haskell don't fall into this category -- for example, network servers -- but a lot of their components do. Can these components can be Haskell functions without IO in their signatures?
Though that seems reasonable, it is not, in general, true. For example, System.Info.os is generally treated as pure, though it is not. It's not clear to me how to disambiguate these "born again" values from really pure values.
-- _jsn _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On 2008 Nov 4, at 19:12, Jason Dusek wrote:
Many useful programs that I would like to write in Haskell don't fall into this category -- for example, network servers -- but a lot of their components do. Can these components can be Haskell functions without IO in their signatures?
I'm working on a report generator (for my own use, probably will be too limited for practical use until/unless I have a need); the input data and output ultimately have to be in IO, but the bulk of the program (and all of the library) is pure; you *want* a report to produce the same output for the same input. -- 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
Hello Jason, Wednesday, November 5, 2008, 3:12:29 AM, you wrote:
Many useful programs that I would like to write in Haskell don't fall into this category -- for example, network servers -- but a lot of their components do. Can these components can be Haskell functions without IO in their signatures?
pure function is one those result depends only on its arguments. as far as you can provide "input stream" as an function argument, it should be possible to write it in pure way (as far as you don't concern efficiency. sometimes imperative algorithms mauy be just faster than pure ones since data structures are different) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
A performance improvement could be the caching of responses based on
computation costs and number of accesses. This functionality can be
implemented a general module that may be used to wrap any pure program if
needed. This is something that only pure programs can ever do. And the
haskell type system can enforce that.
2008/11/5 Bulat Ziganshin
Hello Jason,
Wednesday, November 5, 2008, 3:12:29 AM, you wrote:
Many useful programs that I would like to write in Haskell don't fall into this category -- for example, network servers -- but a lot of their components do. Can these components can be Haskell functions without IO in their signatures?
pure function is one those result depends only on its arguments. as far as you can provide "input stream" as an function argument, it should be possible to write it in pure way (as far as you don't concern efficiency. sometimes imperative algorithms mauy be just faster than pure ones since data structures are different)
-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
"Jason Dusek"
Can these components can be Haskell functions without IO in their signatures?
Sure. You might, for example, abstract networking out of your web server and thus end up with a function of type serve :: [HTTPRequest] -> [HTTPResponse] that lazily maps its input stream to an output stream. You can keep state by passing your state to yourself in a recursive call or do something more involved like using the state monad, but you'll find it very, very, very hard to write a genuinely non-deterministic program without changing input data, no matter what you do, even on multiprocessors. Enabling such things seems rather to be the scope of INTERCAL... does it already have a MAYBE COME FROM statement that relies on an external random source? -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.
Jason Dusek wrote:
Though that seems reasonable, it is not, in general, true. For example, System.Info.os is generally treated as pure, though it is not. It's not clear to me how to disambiguate these "born again" values from really pure values.
It seems to me no one addressed your actual point. System.Info is broken. "os" has the wrong type. Sorry about that. There is quite a lot of brokenness in the standard libs which stops pure functions being pure. It's a shame IMO. Jules
System.Info is broken. "os" has the wrong type.
And the wrong value! I have not installed mingw32 on this machine, mingw32 isn't even an os... /me has goal of having "os" on Linux report "wine1.1.7" Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ==============================================================================
Jules Bean
Jason Dusek wrote:
Though that seems reasonable, it is not, in general, true. For example, System.Info.os is generally treated as pure, though it is not. It's not clear to me how to disambiguate these "born again" values from really pure values.
System.Info is broken. "os" has the wrong type.
Sorry about that. There is quite a lot of brokenness in the standard libs which stops pure functions being pure. It's a shame IMO.
I've thought about this a little bit, and it may be okay. What if our rule for program purity is a program, once compiled, may be moved from environment to environment, and will either execute consistently or simply fail to execute. Consider this program: import System.Info main = putStrLn os If I compile it on Linux and then run the executable on FreeBSD, it will either fail to run, because FreeBSD Linux compatibility got worse since I tried it last, or run and print linux as it would on Linux. Does this seem reasonable? As long as the programs are statically linked, through and through, they should be pure. Admittedly, this approach does not address "source level purity", which is impossible due to `unsafePerformIO` and, more generally, conditional compilation. -- _jsn
Hi Jason,
To help me understand your question, would you be unhappy with the following
structure?
-- runnable
main = interact f
-- composable
f = ...
The discipline is to use interact (or another combinator) to wrap a
functional/composable/pure component like f into an executable. Then give
main to users and f to programmers. This same game can be made more
sophisticated, eg
main = interact (show . f . read)
Or unparse & parse in place of show & read.
For more on combining usability and composability, see
http://haskell.org/haskellwiki/TV
http://conal.net/blog/posts/tangible-functional-programming-a-modern-marriag...
- Conal
On Tue, Nov 4, 2008 at 4:12 PM, Jason Dusek
Informally, a "pure program" an executable such that the stream of bytes entering it totally determines the stream of bytes leaving it.
Many useful programs that I would like to write in Haskell don't fall into this category -- for example, network servers -- but a lot of their components do. Can these components can be Haskell functions without IO in their signatures?
Though that seems reasonable, it is not, in general, true. For example, System.Info.os is generally treated as pure, though it is not. It's not clear to me how to disambiguate these "born again" values from really pure values.
-- _jsn _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Conal Elliott
To help me understand your question, would you be unhappy with the following structure?
-- runnable main = interact f -- composable f = ...
The discipline is to use interact (or another combinator) to wrap a functional/composable/pure component like f into an executable. Then give main to users and f to programmers.
I'd like to be able to compose with systems not written in Haskell, though -- in short, I think of interact f as the composable, exportable part. My original email is motivated by concern about at what level a program is "pure" in the presence of conditional compilation (and dynamic linking, for that matter). I can not, for example, say all pure functions in my code, when used with the same Haskell library set, will return the same results on all platforms. So source code level purity is out. If we move to executable level purity, that seems plausible -- on a given platform, a given executable, if it executes all, will execute identically if it is statically linked with the C libs as well as the Haskell. This is not actually possible on Macs but whatever. The one corner case I had in mind was FreeBSD's Linux ABI compatibility, but I suspect that doesn't matter at all (not having any FreeBSD handy at the moment, I can not verify it). -- _jsn
participants (9)
-
Achim Schneider -
Alberto G. Corona -
Brandon S. Allbery KF8NH -
Bulat Ziganshin -
Conal Elliott -
Jamie Brandon -
Jason Dusek -
Jules Bean -
Mitchell, Neil