Re: [Algorithms] Complexity of new hardware

[Nicholas \Indy\ R. <ar...@gm...>]

On Tue, Apr 21, 2009 at 5:41 PM, Pal-Kristian Engstad
<pal...@na...> wrote:
> Indeed. Most game-programmers and to some extent game designers, want to
> work on a lot of 3D math. This requires quite a bit of math and using
> infix notation for this is definitely mind-boggling, even for seasoned
> Lisp/Schemers. The second reason is that s-expressions work well for
> expressions, but for sequencing, the syntax is less than stellar.

I do wonder if an infix macro would do the majority of the job, for
instance in places where infix would prove advantageous you could do
something such as:

(define (math-me x y z) (infix x + 2 * (y ^ sqrt(z))))

The macro would be fairly trivial (as far as operator precedence goes)
and would keep such code out of the compiler itself. Additionally it
should also be pretty easy to write code in you're editor (presumably
emacs if we are writing code in a lisp) that could transform prefix
into infix and vice versa.

> third reason is that it is quite possible to have strong macro systems
> (see e.g. Dylan and to a certain extent OCaml) without s-expressions.

I have yet to actually use Dylan, but I have used OCaml and the camlp4
preprocessor, I however found macros being much less intuitive when
the language doesn't model the transformation tree quite so well. I'd
like to know if the problem wasn't so large in Dylan.

> The devil is in the details, I am afraid. As an example (and I'm not
> saying this is impossible with static type checking), in a completely
> dynamic setting it is quite feasible to: introduce new fields in a data
> structure (compile and send to game), edit (static) data that uses the
> data structure (compile and send to game) and finally compile functions
> that reference the data structure and send it to the game (at which
> point the new data is actually used). I know AliceML has a solution to
> this, but from what I've heard, it was quite a challenge.

Yes, this is of course a problem with using more strict and static
run-time data formats. But I have found this problem in Dynamic
Languages as well, often times I've found that the default record
types in some dynamic languages, don't often support introduction of
new fields. This becomes much easier if you can support dynamic
non-contiguous records, and this can still interface very well in a
statically typed language. But It's often the case that in static
languages you want static records. In which case you have no choice
then stopping the world, and upgrading every piece of data, and this
would require a lot of allocations/deallocations, This would lead to
large pauses while upgrading data-types, while that might not be often
enough to matter. When it had to happen, it would certainly put a
stall to the quick incremental cycle  you otherwise have going on.

Nicholas "Indy" Ray