[plt-scheme] A crazy idea (fMUMPS)
--- Noel Welsh <noelwelsh at yahoo.com> wrote:
>
>
> --- Greg Woodhouse <gregory.woodhouse at sbcglobal.net> wrote:
>
> > At the time, I wrote a package I could use myself
> > by creating hand-edited XML documents ... I never got
> around to
> > creating a more friendly interface.
>
> An idea:
>
> Let's say you specify a language for writing these
> interfaces. From this language you can generate a UI to
> build them, as well as the transformations to generate
> whatever code you want.
In fact, this is what I started to do (in MUMPS), but I found it
difficult to justify the work if no one else was using the tool, which
is why I never completed it. Actually, there was a second reason, too:
I wasn't really that happy with the use of XML as a template language,
as I found it clumsy to work without a specialized editor.
S-expressions or just a CFG seem(s) simpler.
> As I know nothing about HL7 (I
> looked at the HL7 website and ran away),
I don't blame you. I'm actually not a big HL7 fan, it just happens to
be the industry standard.
> I'll use a
> different example.
>
> Imagine you want to allow people to create multiple choice
> tests. You say something like:
>
> "A multiple choice test is one or more sections. Each
> section is contains one or more questions. Each question
> is a problem, a list of solutions, and a correct solution."
>
> From this you can create a grammar something like:
>
> mc-test := section
> | section sections*
> section := test
> | test tests*
> etc...
Okay, that makes sense.
>
> You'll probably want type annotations on the grammar as
> well.
Yes, with HL7 this is a must. In fact, the biggest chunk of code was
roughly
while not end of message
get segment
for each field in segment
set t = field type
case t of
Int:
do something
Float:
do something
...
Of course, they were all HL7 data types, and there are a lot of them,
so I ended up putting the translation rules is a separate file (table)
I called the QUERY DEFINITION file. Types were inferred from the
message and segment names, and the field types, coupled with what I
call "data bindings" were used to retrieve the values varying from run
to run and marshall them into a message using encoding rules
appropriate to the type. Of course, the the types were complex, and
could even be recursively defined in some cases. That makes it even
more "interesting".
> From this grammar it is reasonably simple to create
> a structure editor that allows you to create a mc-test (say
> via a web interface), and also to specify transformations
> on that test (say, marking it). All a good fun application
> of PL theory [things like zippers, folds, strategic
> programming], and a useful product at the end.
>
> Apologies if that is obvious.
Well, no...
>
> I'm not clear if you want to do your day job better, or are
> interested in striking out on your own.
Last I checked, I've been at my "day job" since 1991. That probably
says something (good or bad) about me. Whether I might end up trying to
create a new product (commercial or open source) is really an open
question. For the time being, I'm keeping myself entertained by
exploring new ideas as much as anything else.
> The advice I'd
> give in each situation is slightly different; my previous
> response was targeted more at the later.
Really? I would have guessed the reverse.
I hope you don't mind if I copy Hardhats on this message. The
discussion may be of some interest there, too.
>
> HTH,
> Noel
>
> Email: noelwelsh <at> yahoo <dot> com noel <at> untyped <dot> com
> AIM: noelhwelsh
> Blogs: http://monospaced.blogspot.com/
> http://www.untyped.com/untyping/
>
>
>
>
> __________________________________
> Yahoo! for Good - Make a difference this year.
> http://brand.yahoo.com/cybergivingweek2005/
>
===
Gregory Woodhouse <gregory.woodhouse at sbcglobal.net>
"Interaction is the mind-body problem of computing."
--Philip L. Wadler