[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtm-perl
Subject:    Re: [gtm-perl] Mumps Gymnastics
From:       Jim Self <jaself () ucdavis ! edu>
Date:       2001-01-19 1:17:50
[Download RAW message or body]

Thomas Good wrote:
>On Wed, 17 Jan 2001, Jim Self wrote:
>
>> Do you have a relational model in postgres where prognote is a simple
>> relation that you can access totally with 'SELECT *'? Relations where a
row
>> could be represented with a delimited string would require a single
>> subscript in a corresponding MUMPS equivalent.
>
>Now you're talking, Captain.  This turned on the lightbulb...I can
>see some pages of Dick's book in my head right now.  I wondered what all
>the subscripts were about.  It now makes sense.
>
>> If you prefer to contruct your HTML reports in Perl then you could have
>> MUMPS just return the rows of a relation from a single FOR (essentially
>> "SELECT *") and do the splitting and joining of those strings in Perl.
>> Actually, a simple relational interface to GTM should be fairly easy to
>> build.
>
>Bingo.  Let's say a pipe delimiter?

Whatever you want. In MUMPS, you can use any string as a delimiter for
another to split or join strings with $PIECE. Fileman uses the hat character
("^") as primary delimiter. I often use TAB. One feature of DTM that I have
become very attached to that is not yet in GT.M is the ability to split a
string to multiple variables in a single SET. Incidently, I like the Perl
equivalents better. 

FWIW, here is a split function I wrote to help me with conversion of some of
my DTM applications.

split(%src,%dlm,%vlist) ;split a string by delimiter vars in list
	;returns number of vars in list
	;usage - s %=$$split(src,dlm,"d1,d2,d3,..")
	n i,v f i=1:1:$l(%vlist,",") s v=$p(%vlist,",",i) s:v'=""
@v=$p(%src,%dlm,i)
	q i

The 3rd line will probably be broken by email. The function returns the
number of variable names in the list.

>This is the HL7 std, fits nicely into Unix and perl and is also a Postgres
>std.

I think that most of the target systems for the original HL7 were MUMPS
based medical information systems. That reminds me that I meant to reply to
a question you asked related to HL7. If I didn't mention it before, there is
quite a bit of HL7/MUMPS at http://www.hardhats.org

>My 6 year old was walking down the street in Brooklyn the other
>day (where he attends school) and he was singing: 'I'm Popeye the Sailor
>Man' - several passersby replied in unison: 'Toot toot!'  The value of the
>pipe delimiter [ as Jungian archetype ] explained in a surrealist fable.
>You see both computing and Brooklyn are examples of surreal estate.  ;-)

It takes a special effort to remember my 6 year olds now. The memories are
obscured by their present image as young adults. I do know that a happy 6
year old is a marvel and a joy to behold. I am sure I would have joined in
the chorus if I had been there.

>> Beyond simple applications, I think the best use of MUMPS the language is
>> for implementing Query languages or dbms or (my personal interest)
>> multi-model Information Sytems.
>
>It has alot of similarities to perl.  The major enhancement is the
>idea of persistence of the global variable.  Of course you and Steve
>(and Ariel) are bridging this gap with the Berkeley db.

I expect that a comparable bridge to GT.M will be both simpler and faster.

>For me I
>just have to get my brain wrapped around the mumps lexicon and rules
>of usage which are superficially so diff from C/perl.

Exactly the reverse of my problem with Perl/C. I find the prospect of
working with Perl on M globals very appealing, especially as an option that
complements our existing MUMPS applications.

>The sparse array is the other thing that throws me a bit

If you consider just one subscript level, it should be familiar to you as a
hash or associative array in Perl, except that keys have a defined ordering
so you can easily step through ranges of keys without having to retrieve and
sort the whole thing. Useful for efficiently discovering variations on names
or words with a common prefix.

>...but as I
>said above, using subscripts to recreate relational grids makes alot
>more sense this morning than it did 24 hrs ago.  (It's tough being
>a concrete thinker...the antithesis of this Ramachandran fellow you
>mentioned.)
>
>A theoretical question:  in mental health our auditors really dislike
>seeing any blanks in the data.  A 'No Data' or 'Not Applicable' is
>much preferred to a NULL.  Doesn't this sort of defeat the idea of
>a sparse array?

Our pathologists make a similar distinction in their reports between a blank
section of a report and an explicit statement of 'No significant findings'.
The blank leaves open the possibility that they forgot to fill in a section.
In a context with limited options there may be no difference.

The purpose of the sparse array is to provide meaningful indexes and
flexibility to scalably accommodate pretty much any database model.

>UPDATE script SET line = 'He's dead, Jim.'
>WHERE line IS NULL
>AND character = 'McCoy, Leonard';
>
>This makes sense in SQL.  But it seems at odds with the Mumps
>strategy of not populating the tree with dead leaves.   Not so?

I don't see the problem. Relational database model is easily represented in
MUMPS, but MUMPS can also represent hierarchical and network and object
models etc.

>Hmm.  Maybe we keep it sparse and let perl fill in the 'Not Applicable'
>blanks?

If a blank in some context always means 'Not Applicable' that should be
explicitly indicated in the database definition - once. Why waste space by
storing it in every record? Perhaps if there is a significant performance
panalty to tradeoff against.

>
>Say - do you have electricity out there today Jim?  It's all over
>the news here this morning -  the energy crisis in California...
>that and Jesse Jackson.  Boy we love a good scandal.

Rolling blackouts in Davis but not at VMTH or my home so far. I am thinking
about getting extra batteries for my laptop and maybe some solar panels just
in case.

---------------------------------------
Jim Self
Manager and Chief Developer
VMTH Computer Services, UC Davis
(http://www.vmth.ucdavis.edu/us/jaself)

[prev in list] [next in list] [prev in thread] [next in thread]