At the end of his posting about UIL, WINTERP, and Lisp, Omar suggests an even Lispier alternative to WINTERP, that you:

"Use LISP entirely. Don't even bother with C, C++, Pascal, FORTRAN, or anything similar. Start with LISP. Develop everything in LISP. This seems to be the most intuitive alternative, but it requires a lot of work. And it's not entirely portable, at least not yet."

Yeah, a LOT of work. There is a big problem with rewriting X-Windows in Lisp, which I learned from working on Garnet with CMU Common Lisp and CLX.

http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/la...

The problem is that CLX (the Common Lisp X11 client library) doesn't support ANY of the standard XLib based libraries, or the client side libraries for X11 server extensions like Display PostScript.

And that problem has only gotten much worse over time as the X client libraries have gotten more and more bloated as they replicate and extend everything the X-Windows server does and much more.

So with CLX, which is the X-Windows protocol client side implemented in pure Lisp, you are stuck with the generic X wire protocol, no XLib based C libraries like Display PostScript (which seemed like a good idea at the time in 1992), not even the MIT-SHM the shared memory extension, no Xt, no Motif, no OLIT, no GTK, no KDE, no NOTHING! You're on your own, buddy.

You might as well just use Lisp's foreign function interface to wrap the entire MOTIF library and translate all the #defines in the .h files into Lisp code so you can refer to symbols and ids by name instead of hex numbers. And that's essentially what WINTERP did with XLisp, so you're back where you started ("client-side NeWS without the postscript imaging model", as Neils puts it).

https://www.cliki.net/CLX

Here's Omar's posting about UIL, WINTERP, and Lisp:

Date: 19 Jan 90 09:53:11 GMT
From: umich!umeecs!anon@yale-zoo.arpa (Omar S. Juma)
Subject: Re: To UIL or not to UIL?
To: xp...@expo.lcs.mit.edu

In article <11658.632634712@hplnpm> mayer%...@HPLABS.HPL.HP.COM (Niels P. Mayer) writes:

[Heavily edited]

>
> ...rumor... ...UIL...
> ...didn't meet HP's quality...
> ...poop...
> ...UIL SUCKS... ...silly...
>...buggy... ...inelegant...
> ...doesn't make life... ...easier...
>...completely nonstandard...
>

I absolutely agree. I've only had 4 years of serious software
experience, and UIL is the worst language/compiler combination I
have ever seen. Nothing, not even working with punch cards, has left me
with a more bitter taste in my mouth. If UIL were a car, not even the
Russians would want to manufacture it. If UIL were a--but, wait a
minute, let's be objective for a minute:

* The UIL compiler does not invoke cpp before it starts its
journey. Yo, DEC!!! Even xrdb uses cpp. There are several
advantages to using cpp. Hey, guys, ever heard of macros? Huh?
What's that you say? You wanted to create your own macro
facility? Oh, I see, in the next version. When's that? Huh?
Next year? Oh. But what do we do in the meantime? Huh? Did
you say "copy and paste"? Isn't that kind of inelegant? I tried
that. It bloated the simplest UIL files to thousands of lines.
What? Yeah, thousands, not hundreds. Made them difficult to
edit. Huh? Split the files, you said? I dunno, that's kind of
old-fashioned, rather stupid. Say what? I can run the file
through cpp first? Yeah, I tried that, in fact, since I had no
intention of wading through huge UIL files; it gave me vertigo.
Huh? You want to know how that worked, you say? Well, I ran
into this problem, see. After I did a few nice macros and got
ready and all, I ran the UIL compiler. I got this strange error
message. It told me that maximum line length was 132 characters.
Huh? Well, see, some of my macros were rather long, like 140
characters, see, and I couldn't make them less than 132 short of
compressing all the whitespace out of the macro and turning it
into one huge token. Huh? You never thought anyone would ever
write macros bigger than 132 characters? Oh, well, I did.

[Quiz of the decade: Where did DEC come up with 132? What, is
it 128 and a bit?]

* Defective error reporting. What do I mean by defective? Like,
it's almost impossible to figure out what the UIL compiler means
when it complains about something. Like, if you forget a
semicolon someplace, the compiler pukes into its own food, eats
it back again, and pukes it out again, and just gets totally ill,
dude.

* Documentation. Huh? Did someone say documentation?

* Language design. Whoever designed UIL must have been heavily
involved in BASIC and FORTRAN, because that's as sophisticated as
it ever gets. The language is extremely simple-minded. No
conditional processing. No interface actions. No anything. All
UIL offers is a substitute to writing out almost the exact same
stuff in a C program. Yes, I know that writing it in C would be
even more time-consuming, but there I have access to powerful
macros and procedural mechanisms, not to mention conditional
processing, that can make life easier. Any intelligence in the
interface must be performed in the program anyway; you can't
delegate any actions to the UIL portion, as Niels says. Which
brings me to wonder why OSF never gave Open Dialogue any serious
consideration (please, don't tell me about "demonstration
technology"). If not the entire Open Dialogue system, then at
least the language, which was several generations ahead of UIL.
My personal impression is that DEC shoved UIL down OSF's throat
as its "contribution", though in effect all it's done is cause
people to waste inordinate amounts of time and effort creating
workarounds.

* Scale. You really cannot write a serious application using UIL
and its compiler. The mechanism simply cannot handle the sheer
volume of text required to describe the interface. You need an
intermediate agent, and OSF just didn't think it was necessary to
supply one. I would have settled for preinvoking cpp, but even
that is not enough.

* Elegance. If you try to develop an application using creation
callbacks and the other standard mechanisms supplied by OSF, you
will end up with a horrendous piece of noodle code on your hands.
UIL lends itself very well to kludgy solutions; I tried hard to
extricate myself from all this mess, but it was not possible
unless I adopted several coding and pre-compilation standards.
In essence, I've spent the better part of two months fighting the
UIL mechanism, trying to create a logical framework around which
I can develop several large applications, and I'm getting close
to completely throwing in the towel and starting from scratch
with WINTERP. I've looked everywhere, and all I see is square
pegs that have been shoved and squeezed into round holes. You
can't go very far with such a setup.

* Extensibility. Are you kidding me? Extend UIL? I'd rather go
gene splicing than try to tack on more crud to UIL. DEC has
supplied what can be generously called as an embryonic extension
mechanism. It's badly documented, and from what I've seen by
wading through the code, they never really thought anyone would
want to extend it. Like, dude, there's everything you'll ever
need there anyway, so why bother?

I'm really sorry to be saying all of this, but UIL is not a solution.
Unfortunately, unless OSF is willing to break with tradition and supply a
completely different mechanism for the next release of Motif, we are
stuck with UIL for quite a while. Which means we will all waste more
time and energy coming up with solutions. Here's some alternatives:

* Create a wrapper around UIL. Bury it under a ton of macros,
processing languages, prepackaged C code. Then it may be
possible to develop an interactive interface editor that uses
these mechanisms. This is what I'm currently trying to do, but
as I said, I'm thinking of giving it up.

* Get the format for UID files and develop your own UIL language
and compiler. This is fairly time-intensive, but offers the
chance to start from zero and build the system correctly.

* Use WINTERP. I'm just not sure about this now, but it's starting
to make more and more sense.

* Use LISP entirely. Don't even bother with C, C++, Pascal,
FORTRAN, or anything similar. Start with LISP. Develop
everything in LISP. This seems to be the most intuitive
alternative, but it requires a lot of work. And it's not
entirely portable, at least not yet.

I could go on...

an...@eecs.umich.edu

...anon...