OK. I see there is a middle ground. I'm not a language expert so
I must admit that I find the distinction between a variable and a once-named
object a bit subtle, but I can see the possibilities.
> 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 guess that depends on the application. One application that I have in mind
is to photorealistically render pieces of electronic equipment in a
telephone network so that it can be visualized and managed remotely. Many of
the structures that I want to render are regular, e.g 20 ICs on a
board, 20 boards in a shelf, 4 shelves in a bay, 10 bays in an
equipment-aisle, .....
Can a declarative language provide an equivalent to a translate-and-copy-n-times
iterator?
> (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?)
Ahh. I think we're getting to the problem here. Perhaps the issue is
not the language style per se, but the ability to write unbounded
expressions in the language?
You further emphasize this concern below.
> > For example, in tsipp (a tcl extension) I can write:
>
> I admit ignorance of tsipp/tcl. I will attempt to correct this.
ftp://harbor.ecn.purdue.edu/pub/tcl/extensions/tsipp3.1a.tar.gz
plus prequisites as identified in that file.
> > 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.
Perhaps VRML should address this issue directly, and perhaps
independently of language style? I wonder if VRML should
borrow the idea of a computation quantity like "Teleclicks" from
Telescript? (ref: "Agents Away," Peter Wayner, Byte, May 1994, pp 113-118)
The VRML file could be required to contain an estimate
of the computational requirements of the structure in some normalized
measurement unit. This doesn't have to be a burden on the human, it
can be measured by the author's VRML editor or viewer and simply
appended to the file.
You could also have separate estimates for each component in a
composite scene and possibly alternate representations of each
component each with different estimates. Using this information a
browser could use a rendering technique that is within its display time
budget and which is appropriate for the size of each component from
the current viewpoint.
> 3) Extensibility
> a) Adding new native types becomes difficult. When is the
> last time YOU extended the C language?
Well, no I haven't ever extended C, but I did write an extension to
tcl this week! (unlucky shot ;-)
> 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.
I fear that I beginning to show my bias, but in tcl everything is a
string, so typing is not a problem. (Unless you feel that the
language should be strongly typed?)
> 4) Security -- postscript has a known security hole, because it
> has a generalized escape mechanism that allows an arbitrary
> system program ot be launched.
A very valid concern. Raw tcl also has many operations that you wouldn't
want to expose to an unknown script. However there is already a
solution in SafeTcl. SafeTcl restricts the capability of the
interpreter to a known set of safe operations without any escapes.
> I can be swayed on this, but my gut feeling is to stay away
> from proceedural langagues.
I would like to learn about declarative alternatives, but I guess
my education is such that I think I could write the kind of
applications I am interested in in a procedural VRML and I
I don't yet know how to do them in a declarative language.
John Ellson
AT&T Bell Labs