Re: [game-lang] defining static parts of games

[Simon McGregor <londonien@xxxxxxxxx>]

Sorry for weird formatting. Posting from mobile phone again.

Not keen on the idea of metaprogramming. Users need to learn two
languages?! And I think that if we need it for something as basic as
repetition, it's a pretty sure sign that we made our language
insufficiently expressive.

Regarding non-boolean functions, I think the main question is whether
we want them as 'true' primitives or just as syntactic gloss. How to
implement any gloss is a bridge for crossing later.

I'd like to try to come up with ways to use the integers which don't
permit unrestricted quantification over them. That might require typed
variables... Maybe it's too ambitious for the moment? If we can't,
it's going to be harder to ever determine whether a program
terminates. I don't mind some language constructs causing
undecidability, but I'd prefer arithmetic not to be one of them if
possible.

If you are forced somehow to quantify only over integer "properties"
of non-integer objects, and the collection of those objects is finite,
and they can only have finitely many properties, that's still
decidable.
Anything else with infinities in it (like Z * Z) would require special
treatment.


Simon

On 8/5/10, Joel Uckelman <uckelman@xxxxxxxxx> wrote:
> Thus spake Simon McGregor:
>> On Thu, Aug 5, 2010 at 5:27 PM, Joel Uckelman <uckelman@xxxxxxxxx> wrote:
>>
>> > Some repetition syntax would be nice. I sort of feel like doing this:
>> >
>> > =A0for (int r =3D 0; r < 4; r++) {
>> > =A0 =A0for (int c =3D 0; c < 4; c++) {
>> > =A0 =A0 =A0printf("hex([%d,%d])", c, r);
>> > =A0 =A0}
>> > =A0}
>>
>> Ergggghhh. Please, please don't ;-)
>
> Are you groaning because you don't want it to look like C, or because
> you don't want metaprogramming at all?
>
>>
>> However, this doesn't have to reflect anything in the underlying
>> language model.
>> It could be pure syntactic sugar, with
>>
>> col(a) + 1 =3D col(b)
>>
>> being internally translated into
>>
>> exists((c, d), _col(a, d) and _col(b, c) and equals(d, plus(c, 1)))
>>
>
> If that's happening, though, we have to have some way of specifying
> how that translation is done. The interpreter won't be able to figure
> it out on its own what the col() function does.
>
>> ...although on second thoughts, we don't really want to be able to
>> quantify over the integers. That's a quick route to doom.
>>
>
> I think that for games with playing surfaces which are infintite in all
> directions, there's just no avoiding it.
>
> --
> J.
> _______________________________________________
> game-lang mailing list
> game-lang@xxxxxxxxx
> http://lists.ellipsis.cx/mailman/listinfo/game-lang
>
_______________________________________________
game-lang mailing list
game-lang@xxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/game-lang