It's not *so* much a question of difficult (poor phrasing on my part),
as it is of *fast*. C is a moderately sophisticated language, and
interpreting it on-the-fly is no small trick. The syntax isn't as rich
and complex as, say, Ada, but it's an order of magnitude more work to
interpret than Lisp (which is nearly trivial) and Forth (which is even
more trivial). And while yacc isn't half-bad, it's none too speedy --
often a fraction the speed of a hand-tuned parser.
And while C isn't *too* hard to write an interpreter for, it's still
not easy. A good C interpreter needs to understand a fair number of
different syntactic structures -- to understand them well enough to
get all the semantics right, you need a good deal of code. Whereas,
again, the semantics of Lisp are fairly simple (so long as you're
not trying to implement Common Lisp), and those of Forth are *really*
trivial.
I've written more than one system in lex and yacc; my firm,
Intermetrics, is primarily a compiler company. (For example, the
project I'm currently involved with is writing the fastest Ada parser
in the world, which is no small trick.) And while you can write
*some* sort of interpreter pretty easily for any language, writing
a *good* one, much less a fast one, isn't nearly so simple. (Heck,
you can always code it in Prolog -- trivial to code, but runs like
mud. Been there, done that...)
Anyway, the point is that a good C interpreter would be a good deal of
work. A C++ interpreter (which is really what most existing Inventor
code appears to be in) would be more. It might be within our
capabilities, but I'm skeptical -- I haven't seen that kind of
expertise within this project yet. (I'm certainly not good enough to
do it well, and I *do* have significant parsing experience.)
Just to make it a little worse -- I suspect that plain C++ isn't
actually good enough for our purposes. I'd bet that we're going to
encounter some very real problems trying to make our code reasonably
"distributed", and find ourselves wishing we had could mess with the
language a bit. If we go with C++, our hands *will* be tied; the
resistance to deviation from the standard will be enormous. A dialect
of Lisp, on the other hand, we can basically mess with to our hearts'
content, to get it exactly right for our needs. (I'm not certain that
this will become an issue, but I intuitively suspect it will.)
I don't think going with C++ as our dynamic language is impossible.
I *do* think it's a mediocre fit -- we're not trying to solve quite
the same problem that SGI was with Open Inventor. And I think it's
a good deal harder than going with a Lispoid language instead...
-- Justin
Who is comparatively weak on visualization
technology, but *does* know languages...
Random Quote du Jour:
"What is this? Where is everyone? Oh shit. I'm dead. And I told
Gwendolyn I'd be back for dinner. Hello? Hello? Anyone there? This
is worse than I imagined. And I thought being dead was like a long
vacation, except you don't get paid. Oh nononono! Here comes God
and I haven't any clean underwear!"
-- from KlingKlangKlatch