[plt-scheme] A crazy idea (fMUMPS)

On Dec 26, 2005, at 6:18 AM, Shriram Krishnamurthi wrote:

> It would certainly be reasonable to construct a functional
> basis for Mumps -- I would recommend that anyone trying to
> do this first study Chris Okasaki's wonderful book on functional
> data-structures to get insights into how best to organize things
> underneath the surface.

I found the dissertation online (and am reading it!) It, does,  
indeed, look very interesting, and I can already see it addresses a  
number of concerns. I should order the book (and learn some ML, too).  
I've actually been rather intrigued by Haskell for a number of  
reasons (strong typing, lazy evaluation). I haven't had occasion to  
learn ML, although it's beginning to seem almost mandatory for  
functional programmers.


> But of course, no Mumps programmer
> is going to adopt this,

Unfortunately, I'm sure you're right. I have made some (unsuccessful)  
attempts to persuade fellow MUMPS programmers that functional  
programming was interesting, but only one person showed much  
interest, and he has a Lisp background. There's no one reason for my  
interest in Scheme or functional programming, but I do think that  
exploring the use of functional languages and technique in medical  
information systems would be worthwhile. Advantages range from  
improved possibilities of applying formal verification techniques to  
strong similarity code I've seen (and written) over and over to  
functional code (executing bits of code in the form of strings as a  
way of simulating higher order functions, passing bits of code to  
"iterators" as a parameter, the extensive use of symbol tables in  
ways reminiscent of closures, and so forth). I'm skeptical of the  
possibilities of implementing standard MUMPS as a functional  
application, at least if the goal is to run VistA -- and I'm not  
entirely sure there would be that much to be gained. But the  
parallels I've hinted at are tantalizing. On top of that, it made a  
big impression on me when I was forced to write code to parse through  
essentially all of VistA to build a dependency graph. Such an  
exercise should simply not be necessary! Beyond that, writing simple  
user interfaces in Java (Swing) and then making what on the surface  
appeared to be small changes to the UI and finding that it required a  
fair amount of work led me to question whether OO represents the  
right (or at least only) way to extend MUMPS. You may know that  
InterSystems has developed an OO extension to traditional MUMPS that  
is quite interesting, and there is an open source product known as  
ESI Objects doing something similar, but with which I have no  
experience.  At one point, there was discussion of extending the ANSI  
standard along OO lines, but I've started to wonder of late whether a  
functional language (even if it isn't a strict superset) would be  
worth exploring.

> so is the point to give PLT programmers
> a better set of associative libraries?

Certainly, the lack of associative data structures in Scheme has been  
a frustration to me, but I'm enough of  a neophyte, that I haven't  
been ready to say this is a language deficiency and not just a gap in  
my education. I've looked at ideas ranging from monads to  
continuation passing, but don't really think I'm on the right track.  
FWIW, the monadic style of programming in Haskell reminds me of  
device I/O (writing to a device multiple times schedules "actions"  
that will be executed sequentially, but at an unknown time). and it  
is intriguing that lists can be treated as monads, but I'm told that  
what is essential here is the non-determinism implicit in lazy  
evaluation (no Church-Rosser theorem for actions), so that seems it  
may be a bit of a false start.
>
> Shriram

I'm a programmer, but just an amateur in computer science.  
Nevertheless, the degree of coupling in code I've seen an the  
exponentially increasing cost of incremental enhancements is  
something difficult for me to forget or ignore. To me, functional  
approaches seem more promising than object oriented ones (though I'm  
not sure the categories have to be mutually exclusive), and so I  
suppose I've been trying to think through how I might go about  
developing code of the type I write in my day to day work using  
functional techniques and f functional language. (I'm also a bit of a  
pariah over on Hardhats for suggesting that a time comes when it is  
better to step back and write new code from scratch, rather than  
continuing to modify the same code.)

===
Gregory Woodhouse
gregory.woodhouse at sbcglobal.net

"Nothing is as powerful than an idea
whose time has come."
-- Victor Hugo