Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Caml productivity.
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-07-31 (01:11)
From: eijiro_sumii@a...
Subject: Re: Games (Re: [Caml-list] Caml productivity.)
From: "Jonathan Coupe" <>
> Graphics Gems and Game Gems series would be good starting points.

I actually had taken looks of them during the discussions with
friends, but thank you anyway for references.

> The hard part of a games scripting language is not, generally, the symbol
> processing (take a junior programmer and les and yacc) but the runtime. Do a
> search for Unrealscript's documentation. Symbol processing barely impacts
> graphics editors at all.

Oh I see, the problem seems to be that I am saying "symbolic"
computation in a much broader (maybe too broad) sense.  As I wrote,

| By "symbolic part", I mean all parts involving more complex data
| structures than float arrays, like managing objects of various
| shapes, manipulating trees for grouping those objects, or even
| interpreting domain specific languages for describing placement and
| movement of such objects.

Language runtime is a _typical_ instance of symbolic computation in
this sense.  This is just a problem of definition and excuse me if it
was confusing (it seemed to me that many people share this definition,
but maybe not).  On the other hand,

| OCaml is very good at such a kind of programming, you know!

This point is more controversial and far beyond the ability of me
alone - please ask the people in this list!:-)

At the same time, of course, OCaml is not (yet) so good at real-time
processing, which was the first point of my first message in this list
on this topic.


To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: