On Wed, 17 Jun 1998, Simon L Peyton Jones wrote:
> What is "Strict". If you said (x `seq` ask2) instead
> of (ask2 (Strict x)) then you should get the behaviour you expect.
"x `seq` ask2" didn't worth but after a little more research, "ask2
`strict` x" did.
The general question is whether it is stylistically good or bad to use
strictness outside the IO Monad to sequence IO. The documentation is
ambiguous.
> There's a critique of various I/O models in
>
> %A P Hudak
> %A RS Sundaresh
> %T On the expressiveness of purely-functional I/O systems
> %R YALEU/DCS/RR-665, |DCS|, Yale University
> %D March 1989
I am guessing that this answers that question. Anyone know a URL? Or can
someone send me a copy?
> > The program would look something like:
> > main = do
> > (dbSource,dbSink) <- dbConnect "ODBC: someodbcurl"
> > (httpSource,httpSink) <- apacheConnect "urlToListenOn"
> > (httpResponses,dbUpdates) <- return $ myCGIFunction httpSource dbSource
> > dbSink dbUpdates
> > httpSink httpResponses
>
> I gather that HTTPRequests and DataBaseVersions arrive
> asynchronously and unpredictably. So how does myCGIFunction know
> which list to probe first? Whichever it chooses it may block on
> one while there is data on the other. Unless I'm misunderstanding.
Actually only HTTPRequests block. I assume that myCGIFunction gets
blocked until it recieves an HTTPRequest. Onces it gets an HTTPRequest,
it pulls a new DatabaseVersion (opens a transaction) from the database
version list. The database version list may also block in which case the
HTTPClient willl have to wait for database contention to ease before
getting back a response.
In the general case, I am assuming that sources block if they are event
driven and supply a new version if they are demand driven. (it is like
the difference between demand-pull and event-push content on the web e.g.
http requests vs recieving subscription email). If the programmer has a
function that takes two blocking inputs then I presume that it waits on
one and then it waits on another. The programmer just wants the program
to wait until it has input on both before firing an output. For example,
you might have a spam detector which watches for incoming email on two
separate accounts. This detector should block until it has mail in both.
> You need to be able to say "wait until there's input available
> on one of these two ports, and tell me which". Something like
> the Unix select call. GHC's Posix library has such a thing,
> but you can't use it in the way you describe because myCGIFunction
> is a pure function on lists.
I am actually assuming that the unix select call is embedded in whatever
process is supplying the list of http requests not in Haskell itself.
Haskell's waiting for HTTPRequests is more like waiting for the system to
supply the contents of a file or waiting for more input from a socket.
On haskell's end, I would expect it just to block until it has input (in
the same way that I would expect the filecopy function in the tutorial to
block until it sees EOF).
Is this an incorrect assumption? It seems to work for addtwo above.
> So far as your dbSink is concerneds, presumably what you have in mind is that
> (dbSink dbUpdates) spins off a concurrent process that pulls on dbUpdates and
> sends them to the database. Concurently, httpSink is doing the same.
Yes. You could view them as creating a file, writing the list to the file
and spinning off a process that consumes the contents of the file in the
way unix "tail -f" does.
e.g.
dbsink dbupdates = do
somehandle <- createHandle
%createProcess on somehandle
write somehandle (map show dbpudates)
The difficulty is that sequence semantics mean that dbSink must complete
before httpSink completes resulting in a large memory leak and no
httpresponse ever being sent. The parallel haskell people added "par" to
be like "seq". A primitive likethis would solve the problem.
> In short, lots of concurrency and non-determinism. Fine! That's
> what Concurrent Haskell is for. You can find a paper saying what
> Concurrent Haskell is intended for.
> http://www.dcs.gla.ac.uk/~simonpj/papers.html
> (under "monads, state, and concurrency").
I guess you are on top of this. I will download the paper now.
-Alex-
___________________________________________________________________
S. Alexander Jacobson i2x Media
1-212-697-0184 voice 1-212-697-1427 fax
