--- Kevin Toppenberg <[EMAIL PROTECTED]> wrote:
>
> It also seems that Haskell may be a cool tool for some aspects such
> as data
> relations. But for other parts it may require one to stand on one's
> head to
> get the job done.
I think you might be surprised, actually. Being accustomed to
procedural languages like MUMPS, you might *think* you'd have to stand
on your head to do anything realistic in Haskell, but I believe that a
web server (HTTP/1.1) written in Haskell is only about 1500 lines, and
is about 70% as fast as Apache.
>
> Lets take a "Haskell VistA" example, where all of VistA is rewritten
> in
> Haskell. Sure one can map data relationships. But at some point I
> will
> have some job that needs to be done in an sequential fashion. First
> I
> register a patient...
Think about it as a constraint. You can't enter a progress note for a
patient that isn't registered.
> ...then I enter a progress note.
But this is a little more tricky. I've been thinking about different
ways of handling actions like this, and haven't really settled on what
I think is the ideal solution. Haskell handles actions through monads.
The basic idea is that when an action appears in your program, then it
will be carried out at some future time, but *you* don't actually carry
out the action. Philip Wadler wrote a delightful little article (which
I quote in my signature) comparing this all to the mind-body problem,
and the difference between thinking about registering a patient and
actually registering the patient. Continuing with the theme of
Cartesian dualism, he even compares interpreter or VM to the pineal
gland (which Descartes thought provided the mind-body link)! Now, what
a monad does is allow you to "bind" variables to actions, which mean
you say that actions A, B and C occur as a kind of a bucket brigade,
with A generating the value a, which is "handed off" to B, and so
forth. But again, you don't really "do" this, you say that this is the
relationship that needs to hold between those actions.
I'm not completely sold on this approach to actions, because it does
seem awfully abstract, and it does seem a bit like splitting hairs,
too. I also wonder if programmers should really have to think about
arcane notions like monads. In fact, when you read a variable, you
initialize a whole sequence of actions that are handled behind the
scenes. The whole point of compilers, operating systems, or a DBMS is
to provide you with a simple set of abstractions that keeps you from
having to worry about what's really happening "under the hood".
In fact, Haskell takes the approach of providing "syntactic sugar" that
hides the actual monad operations, allowing you to write code that
looks suspiciously sequential. To steal an example from Thompson's
textbook, you can write
addOneInt :: IO ()
addOneInt
= do line <- getLine
putStrLn (show (1 + read line :: Int))
and if you want my opinion, even *that* looks awfully complicated.
But technically, this is just another way of writing
addOneInt
= getLine >>= \line ->
putStrLn (show (1 + read line :: Int))
where the "bind" operator (>>=) is the hand-off in the bucket brigade.
Basically, the idea is that you can only pass values along using >>= so
you can't shoot yourself in the foot by comparing values that might
have been resulted from intervening actions (like reads) being
performed.
Bear in mind that I've spent a long time working with VistA and seen a
lot of broken or fragile code. A big part of the appeal of this
approach is to make the code less fragile and more easily maintainable.
In fact, it does turn out that functional programs tend to be shorter
by a factor of four or more, and they tend to be quite robust. One
common use of functional programming is in the development of safety
critical systems (something that should surely be of interest to the
VistA community). Finally, my experience is that functional programs
are much easier to "keep in your head" and to reason about.
> I would find it
> difficult
> to shape this problem in my head otherwise.
>
> Kevin
===
Gregory Woodhouse <[EMAIL PROTECTED]>
"Interaction is the mind-body problem of computing."
--Philip Wadler
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
