Immediate/Compile Time Execution for
Kevin
nnoydb at excite.com
Mon Feb 23 08:28:05 EST 2004
> Ken Ray:
> on preOpenStack
> start using "libMyStuff.mc"
> end preOpenStack
> It simply looks for a stack with that name in the current directory and
> then loads it as a library. The stack doesn't have to be already open
> and in memory to be able to "library" it.
Thanks, I was not aware of this the documentation did not elude it in any way.
Is is possible to call it like so:
start using "../common/utils.rev" (and is this multi-platform compatible)
I ask since I am not readily at a computer with RR to test it myself.
> Rob Cozen:
> As others have noted, there is considerable discussion of this
> subject in the List archives.
> The solution I have proposed, and would be interested in hearing your
> reaction to, is support for an external symbol table stack that would
> be referenced by the Script Editor when compiling.
> Using the symbol table, a developer could:
> 1. Declare constants globally instead of inside every script that
> references them
>
> 2. Explicitly type variables, including pointers & handles
>
> 3. Define record structure field names, assigning variable type & offset
>
> 4. Define system call names, including # of arguments & "system glue"
> (eg: register assignment) info
>
> The compiler would check the symbol table stack(s) [if present] when
> resolving symbols.
This would definitely be a step in the appropriate direction. However, if Runtime
exposed a lower level API the xTalk,Transcript ... community could build language
extensions. Thus releasing Runtime developers to focus more important things.
Personally, I have always been a low level developer I prefer creating my own constructs
and expanding on those already present. If I do not like something about a language
I would like to have the power to correct it or circumvent it.
> Brian Yennie:
>
> I'm a bit lost as to where you're headed with this, but hopefully some
> of this background helps:
> * Transcript is compiled into bytecode when you save a script. It is
> not purely interpreted- think Java (conceptually at least).
> * The "do" command allows you to execute arbitrary scripts at runtime,
> but is subject to the scriptLimits property.
> * You can write your own "handlers" to add commands and functions to
> the language
> * You can write externals in C or C++ to add commands and functions to
> the language
> * There are no #if, #include, #define, etc directives, but there is
> "start using" , "insert script" and constant declarations.
> * commandNames(), functionNames(), externalCommands() and
> externalFunctions() can give you a list of all built-in commands and
> functions, along with external commands and functions.
Thanks, for the education! My purpose originally was to simply be educated
about the compile time/immediate constructs available to me. Since it seems
the documentation I have fails to address those individuals interested on the lower
level facilities. Now I would like to persuade RR to give developers access to the
the lower level building blocks so we can extend the language ourselves.
_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
More information about the use-livecode
mailing list