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