]> [Excuse me for citing a personal message without prior permission. Also, excuse me for repeating all the same points as in my previous messages...] > I think you'll find that the emphasis on symbolic programming in ICFP was > typical of ICFP rather than the supposed application domain. I very much expected this response.:-) Indeed ICFP must have put _more_ emphasis, I suppose, but it is of course just one example. Also in some other CG programs involving Bezier curves, hidden line/surface removal, radiosity, polygons, meta balls, etc. etc. that I wrote, most non-trivial parts were symbolic ones. The numeric parts were "mathematics" rather than "programming" - once I solved some equations, the rest of the work was routine: it was just writing down let x = (-. b +. sqrt(b *. b -. 4. *. a *. c)) /. (2. *. a) or things like that. Chatting with game/CG professionals around me _strengthened_ this impression: the symbolic parts seem even more non-trivial in realistic applications. For instance, just imagine implementing various kinds of graphics editors or scripting languages for animation description! Unfortunately, all of these are mere personal experience and impression: just I believe that CG programs in the real world are more symbolic than classroom exercises or laboratory experiments, for the reasons that I wrote above and in my previous messages. If somebody doesn't believe this, I have no more means (and time) to convince him/her - this is just "FYI". -- Eijiro Sumii (http://www.yl.is.s.u-tokyo.ac.jp/~sumii/) Research Associate, Department of Computer Science, University of Tokyo ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners