Programming Language for Games, part 3

[Walter Bright via Digitalmars-d]

On 11/1/2014 1:33 PM, bearophile wrote:
> Walter Bright:
> D is better here, because it doesn't introduce magically named variables.

I agree that the implicit variable is not good.


>> * D does the check function thing using compile time function execution to
>> check template arguments.
> This is not nearly enough. I have written a lot about this.

I don't agree. Compile time checking can only be done on compile time arguments 
(obviously) and template functions can arbitrarily check compile time arguments.

I know you've suggested extensive data flow analysis, but Jonathan's language 
doesn't do that at all and he neither mentioned nor alluded to the concept of that.


>> * D also has full compile time function execution - it's a very heavily used
>> feature. It's mainly used for metaprogramming, introspection, checking of
>> template arguments, etc. Someone has written a ray tracer that runs at compile
>> time in D. D's compile time execution doesn't go as far as running external
>> functions in DLLs.
>
> His "compile time execution" is different and probably better: the whole
> language is available because it uses an intermediate bytecode. This makes it
> more flexible and avoids the need of having essentially two different
> implementations of the language.

He has two implementations - a bytecode interpreter, and a C code generator.

D's CTFE restrictions are:
1. no global variables
2. no pointer math
3. no external code execution

While this prevents you from running space invaders at compile time, I haven't 
seen much of any practical limitation for things that CTFE is used for.


>> The ascii_map function will work, however.
> The ASCII map example doesn't work in D because of reasons I have explained a
> lot in past posts.

Like what?