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.
> John.Ellson@att.com