[plt-scheme] A crazy idea (fMUMPS)

Let me add something to this post.

Greg and I have corresponded a couple of times last month, and I 
encouraged him to post here for several reasons:

1. Health informatics is an up-and-coming field. MUMPS is one of those 
standards that has evolved in this area. Neither Python nor Perl nor 
any of our other friends have made an in-road yet. Perhaps Scheme/FP 
could be first in some app area.

2. This is probably not a one person job though some superhacker may 
get very far on his own, assuming no other directions. So posting here 
to look for help appeared appropriate. This is not a small job because 
in the end someone will have to construct a full-flegded fMUMPS app and 
demonstrate that is better than CobolMUMPS in some systematic fashion. 
Greg is your way in.

3. I could even see research bits in this area. Greg mentions 
verification problems, but there are clearly algorithmic problems and 
many others. (Speed won't come for free here.) You might even be able 
to raise NIH funding eventually.

So this is a potential target for someone who thinks Scheme/FP is a 
good thing (tm) and wants to prove it with someone one day.

-- Matthias



On Dec 27, 2005, at 1:22 AM, Gregory Woodhouse wrote:

>
> 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
>
>
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme