Re: Scripts vs APIs

Linas Vepstas (
Thu, 8 Sep 1994 17:27:46 -0500

> From: (John Ellson)
> To:,,
> Cc:
> Date: Thu, 8 Sep 94 00:08:01 EDT
> I hope that VRML will at least have variables and the ability to
> define interpreted procedures and iterators so that
> regular geometric objects can be described efficiently over the net?
> If I have variables in the language don't I need a verb in the language
> to set the variable?

I want to draw a distinction between a "variable" and a "named object"
(aka "alias" aka "proxy" aka "surrogate"). Thus, I can declare

bigGreenKnob { polygon { vertex ... vertex ... }}

and use bigGreenThing as a handle refering to a large, complicated object.
If the language allows bigGreenThing to be redefined at a later time
to be something else, then bigGreenThing is a "variable". If it is
illegal to redefine bigGreenThing, then it is merely a name. The former
is the hallmark of a proceedural language, the later is that of a
declarative language. Again, the later is usually easier to handle.

Note also that you can build heirarchical objects, even recursive objects:

doorKnobCollection { bigGreenKnob, bigGreenKnob, knobby} // forward decl. of knobby
knobby { doorKnobCollection, doorKnobCollection}

This is still declarative in nature, although the language should provide
some rules for terminating recursion, and for handling forward declarations
(e.g. knobby is used before it is defined).

> It seems to me that there would be a great loss in efficiency
> without an ability to express structures in a procedural fashion.

I know of very, very few interesting structures that are easily
specified in a proceedural (algoithmic) fashion. And for these
few, I propose making them into native constructs.

(I'm thinking specifically of the iterator that draws a circle as a
series of straight lines, ditto spiral via iterated bessel functions,
various fractals, "marble texture". After that, the algorithms
start getting CPU intensive. How would you feel if you down-loaded
a VRML document that turned out to be a proceedural description
that computed radiosity?)

> For example, in tsipp (a tcl extension) I can write:

I admit ignorance of tsipp/tcl. I will attempt to correct this.

> What aspects of procedural languages in general do you see as a
> problem in VRML? Is it just a concern about the readability of stack
> based languages such as postscript?

The nervousness, possibly unfounded, is this:

1) Performance.
a) Algorithmic scene descriptions can take unbounded,
non-polynomial amounts of CPU time digest.
b) I don't feel like writing a compiler to digest the language,
but history shows that for a proceedural language, I
eventually will.
c) I'm worried about downloading the VRML script that
turns out to be a program that computes the first million
digits of pi. I guess poeple could do this in postscript,
but they don't ...

2) Unpredicatability -- I can't predict what a program does
until I run it. That includes how much memory it'll use.
That means that graceful recovery from overflows & run-time
errors become hard.

3) Extensibility
a) Adding new native types becomes difficult. When is the
last time YOU extended the C language?
b) Reprecussions of language extensions. If I add a new type,
don't I have to figure out how every operator might operate
on it? If I add a new operator, don't I have to define
what it does to each type? Could get ugly fast.

4) Security -- postscript has a known security hole, because it
has a generalized escape mechanism that allows an arbitrary
system program ot be launched.

I can be swayed on this, but my gut feeling is to stay away
from proceedural langagues.