Re: LANG: Dynamic characteristics

Mark Waks (
Thu, 14 Jul 94 13:56:57 EDT

John writes:
>Sorry, I was stuck on the wrong topic. I can see that you are talking
>about an "animation" language that is machine independent. I thought we
>were still talking about input file formats.

Oh, heavens no. The Inventor ASCII format is quite nice from a parsing
point-of-view, very regular and predictable. I could probably whip up
a reasonably good parser for it in a day or two with no trouble. (Well,
maybe a little longer if I wanted really good code -- it just begs
driving the fields off of some sort of table/tree-based system that
allows you to define in the table what fields are legal for the
current node. On the other hand, given the application, we might
consider just glossing over the question of legality entirely, since
it probably takes longer to report an error in the file than to just
put it into the graph and ignore it...)

David writes:
>The Inventor toolkit is written with C++. But C++ code is not what
>is passed around to describe Inventor scenes - rather, Inventor has
>a data interchange format for specifying scenes.

Yes and no. The problem is that the Inventor ASCII code isn't the
be-all and end-all of Inventor. If you want to do really sophisticated
dynamic stuff in it, you need to either have a C++ program that's
modifying the scene graph on the fly, or have toolkits implementing
new node types (which are again written in C++). Even doing non-
standard event handling requires some C++ code, if I'm reading the
Inventor Mentor correctly.

Basically, the topic being discussed here is how we deal with these
more-sophisticated cases, where the basic Inventor-style engines
aren't sufficient. I'm arguing that we shouldn't write these matters
directly into the language (as Meme does), but will probably want
a standard interchange language for them in the long run, and that
that probably does *not* want to be C.

BTW, people should bear in mind that, although we *do* probably have
to decide now whether or not the dynamic language is integrated with
VRML per se (because it affects the design of VRML), we do *not* have
to choose which language to go with if it's outside of VRML. We can
decide during this first cut that the dynamic language will be some
sort of object-manipulation language, and leave it at that until later.
I actually lean towards this; while I have some strong opinions, I
think it's a shade premature to decide on the dynamic language now...

-- Justin

Random Quote du Jour:

"One learns by doing, dear boy. Empiricism Uber Alles!"
-- from X-Men