[gameprogrammer] Re: Scripting engines: Upvalues and function refs
- From: Bob Pendleton <bob@xxxxxxxxxxxxx>
- To: Gameprogrammer Mailing List <gameprogrammer@xxxxxxxxxxxxx>
- Date: Sat, 03 Apr 2004 15:36:03 -0600
I found that paper on line at:
http://ncstrl.mit.edu/Dienst/UI/2.0/Describe/ncstrl.mit_ai%2fAIM-199?abstract=
On Fri, 2004-04-02 at 03:30, David Olofson wrote:
> Dunno if this is the best list for this question, but I guess some
> people around here have some experience with implementing scripting
> engines. (And either way, if this gets through, it means I'm still on
> the new list. ;-)
>
> Anyway, here goes:
>
> I'm hacking a new version of EEL; the scripting engine used in
> Audiality. (A major rewrite. This one's using a mostly RT safe
> virtual machine instead of executing from the source.)
>
> A. I have local functions with upvalues. (Full
> lexical scoping, implemented by backtracing
> the call stack.)
>
> B. The top level of a source file (module) is
> compiled as a top level functions, so any
> "top level" functions are actually local
> functions to that module.
>
> C. The language supports only dynamically typed
> variables at this point. (Statically typed
> variables on the TODO, for performance and
> improved compile time error checking.)
>
> D. Function calls can be either "hardwired" at
> compile time, or called through references.
>
>
> Now, if you consider the above, you'll probably realize that this
> causes some problems:
>
> 1. When calling via references, you have no clue
> what you're calling at compile time. (Not a
> major issue in itself, though the run time
> checking will impact performance a bit.)
>
> 2. All directly callable functions are actually
> local functions, and may try to use upvalues.
> What looks like global variables in a module
> are actually locals of the top level function,
> and "normal" functions access them as upvalues.
>
> 3. You can't easilly tell what register frame to
> pass as "upvalue frame" to a function.
>
> 4. You may end up violating the scoping rules,
> trying to call functions that are not callable
> from the current context. (Even if you grab
> the function reference when the function has
> a valid context, that context may no longer
> exist when someone decides to call via that
> reference!)
>
>
> I'm thinking about not allowing getting references to functions using
> upvalues. That may seem like an obvious and logical restriction, but
> note that this prevents you from calling functions that use "globals"
> on the module level via references...
>
> Another solution is to make top level functions and global variables
> of modules special; more like in C, C++ and (Object) Pascal. I don't
> quite like it, though. I want the scoping rules to be complemely
> conistent, so you can do *anything* in any scope, within reasonable
> limits. (Local functions, local classes etc...)
>
> It would be kinda' kewl if I could just make it impossible to pass
> references to local functions to contexts that cannot call them, but
> I can't quite see how to do that in a logical and comprehensible way,
> since any dynamically typed variable or argument can hold a function
> reference... (That is, I can't prevent illegal reference passing by
> restricting the scope of the reference type, or something like that.)
>
>
> Any ideas? How do other languages with upvalues handle function
> pointers/references?
>
>
> //David Olofson - Programmer, Composer, Open Source Advocate
>
> .- Audiality -----------------------------------------------.
> | Free/Open Source audio engine for games and multimedia. |
> | MIDI, modular synthesis, real time effects, scripting,... |
> `-----------------------------------> http://audiality.org -'
> --- http://olofson.net --- http://www.reologica.se ---
>
--
+---------------------------------------+
+ Bob Pendleton: writer and programmer. +
+ email: Bob@xxxxxxxxxxxxx +
+ web: www.GameProgrammer.com +
+---------------------------------------+
Other related posts:
