glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [glob2-devel] scripting language


From: martin . voelkle
Subject: Re: [glob2-devel] scripting language
Date: Tue, 24 May 2005 11:30:09 +0200
User-agent: Internet Messaging Program (IMP) 3.2.7

> TEA is reentrant, and I use it at that at my job. The "states" are
> possible to save as I have a "Context" class where all variable data is
> located and these are again "streamable" (or will be, as I don't use
> this feature yet).
>
> But I quess that the state information also need to be stores in the
> glob2 type that one can manipulate from the script (or C++) api.

That can be handled by only exposing functions and no direct pointer to glob2
internal structures.

> >Actually I where aiming at a type-safe lisp with a different syntax.
> >
> >
> Ahh, I newer get use to lisp :-) I really like emacs, but I get dizzy
> when I look into there script base :-)

That's why there is the 'different syntax' part. It probably will not look like
lisp except to lisp fans where every programming language is just a downgraded
lisp.

> TEA is a clone of differant ideas, syntax is a little like C, variable
> syntax from ML, and I have a special kind of type system and it is
> extreamly typesafe (no indirect conversions at all). My primary
> mutivation to make the language was to be able to evaluate as much of
> the script before starting executing it, as this was a needed feature.

It's also an important feature for glob2. We don't want script writers having to
debug while playing each and every error the compier doesn't see.

> It is work in progress, and I am working at impl. the executer as a
> small stack machine, as the current executer is a bit slow (half speed
> as python). All the language is written in C++ :-)
>
> >The thread model is not critical as long as it can be implemented in a
> >deterministic way, and the state of the virtual machine can be
> saved/reloaded.
> >
> >
> I quess that this is possible, if I understand you right.

Let me explain it:
Imagine one of the threads is in the middle of a function and waiting for a
condition to happen. The game might be saved and stopped at that moment. When
it's reloaded and resumed, the thread state has to be exactly the same as
before. That means its stack and all the variables reached through references in
the stack have to be written with the saved game and reloaded so that execution
can be resumed right where the thread was.

Martin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]