ZokuTalk's Meta Protocol
by Peter William Lount
Copyright 1997-2016, all rights reserved.
ZokuTalk EBNF Keywords:
Singleton-Instances EBNF Keywords nil false true
Pseudo-Variables EBNF Keywords: self super meta
The obsolete Smalltalk keyword/pseudo-variable "thisContext" is replaced by the super powerful metaprogramming keyword/pseudo-variable "meta" in ZokuTalk;
of course you can still access the current stack context by using "meta thisContext" or "meta executionContext."
The ZokuTalk keyword/pseudo-variable "meta" empowers metaprogramming with the full power of the full general purpopse
programming language so both have the same full expressive powers. All too often in programming languages
meta programming is hobbled by special language syntax or a very restricted subset of a language.
As in the case of the other keywords/pseudo-variables meta refers to an instance of the Meta class of objects, although it's not necessarily
a singleton as the keywords nil, true, or false object instances are; it's a pseudo-variable self or super keywords/psudo-variables
that refer to different objects instances or classes at different times. Any given execution context might have a different
instance of the Meta class due to various factors such as, for example, a security execution context that might restrict low level operating
An example of obsolete restricted meta programming in Smalltalk a special syntax is required for "primitives" using an archaic non-message passing
syntax for accessing a virtual machine primitive function using the ick syntax of "<primitive number>" or
some other modern variant thereof. The same non-message passing syntax is true of the so called "foreign function interface" (FFI) calls
to Dynamic Link Libraries or Shared Libraries. This "special" primitive syntax really is primitve in that it
also forces every known Smalltalk variant to have only one primitve call in a method and crippled exception handling
syntax that again is not standard general purpose programming syntax. Everytime you need special syntax
the language loses genericity and makes life difficult for programmers, users, and power users alike.
ZokuTalk's meta unifies all meta programming capabilities including all primitive activations, DLL or FFI calls
by using the exact same language syntax as general purpose programming using unary, binary and keyword message passing
and block syntax. In addition all standard exception processing behavior is as one would expect in general purpose programming.
Furthermore there are no limitations on how many low level primitive or foreign function calls one can make in any given method
although standard object oriented sytle guidelines for reuse and clarity using short methods should still be followed.
"meta primitiveadd64Integer: aInteger as64BitInteger to: bInteger as64BitInteger" is all it takes to access a low level function "primitive" in ZokuTalk,
and you can wrap standard exception handling code around it as desired or required for defensive programming 101.
Due to the nature of most primitive or FFI or DLL calls specific class types for parameters are often required to avoid runtime errors so a range
of class/type conversion methods exist, in addition to the extensive ZokuTalk Verification Library of classes.
"meta module win64Api someFunctionCallMessageAndParamtersGoHere: aParameter" is all it takes to access an already loaded
DLL, and methods exist to check for the existence of and load any given DLL according to the proper Microsoft or Unix style APIs.
Obviously differences in operating systems need to be dealt with but that can happen in the higher level ZokuTalk message passing syntax
rather than using an iCk C based language.
meta is an access doorway into the internal world of the ZokuTalk language meta environment giving access to all kinds
of objects that make up the ZokuTalk runtime environment of the running application. There are dozens of already thought of uses
for the meta keyword in ZokuTalk, and as it's a generic doorway implemented as classes in ZokuTalk it is open to expansion into new areas.
In traditional Smalltalk systems there is a dictionary instance, often of class SystemDictionary, that contains as keys the names of Classes (and other global variables)
accessible to the current running Smalltalk programs. All class names start with an uppercase letter as do "global variables". When a class name is referenced
the Smalltalk compiler looks up the name in the "Smalltalk" dictionary. In ZokuTalk this lookup occurs through the "meta classes dictionary lookup, which is part
of the ZokuTalk namespace system, meta namespace, that includes global variables and class names that are accessible within the current meta instance. In this way
as part of the ZokuTalk security system the available classes in any given execution context can be customized, expanded, filtered, restricted, or selected. For example,
in a Security Sandbox you might not want to give full access to all the classes in the full ZokuTalk execution context so that "foreign code" being executed isn't able
to read or write to the local storage device.
To support executing code in a Security Sandbox blocks of code can be executed with a new meta context instance that specifies the various security restrictions or
permissions, for example: "[:someParameter ... some code you don't trust ... ] value: aParameter metaContext: Meta secureSandboxMaximumRestriction" will execute the block
of code from some foreign source you don't trust with an instance of the Meta configured to be a maximum security sandbox that doesn't allow for reading or write to the
file system and omits all but the most basic set of system library classes. In this way code from outside souces, can in theory, be executed in a safe execution context
with limited resources to prevent actions that virus authors would love to take to infiltrate your system.
In summary, ZokuTalk adds the powerful keyword/pseudo-variable meta maintining the functionality of thisContext while providing a wide range of new
capabilities at compiletime and runtime of Zoku(tm) based programs including but not limited to:
Access to the current closure execution context is provided by the convenience method, thisContext via meta thisContext;
Primitives using Standaried Unified Message Passing Object Block Syntax;
Foreign Function Interface (FFI) using Standaried Unified Message Passing Object Block Syntax;
Uniform Execption Handling for all code in the ZokuTalk system;
Security Sandbox Contexts for executing code with specific access restrictions;
Namespace Management and Integration using a unified approach;
Access to all First Class Objects in the ZokuTalk Execution Environment, unless restricted by a Security Sandbox, enabling powerful development systems
not to mention amazing application prowess at dealilng with runtime enviroment issues;
Access all things not ZokuTalk, all things below the language, or not of the language, or of inside the language, all things from others, ... all things meta;
Many other purposes not yet disclosed.
ZokuTalk has many other capabilities that distinguish it from Smalltalk systems. ZokuTalk is based upon an evolution of Smalltalk syntax that aims to make it a much more pure
unary, binary, keyword, block & object based message syntax than other languages. Elimination of dedicated non-message passing syntax such as primitive syntax and legacy
file in chunk formats from ZokuTalk syntax helps to clean up and purify the minimal elegance of the ZokuTalk EBNF design so that one unified and uniform unary,
binary, keyword, block & object based message syntax rules them all.
It should be noted that while ZokuTalk improves upon Smalltalk in many ways including by purifying the syntax all legacy Smalltalk capabilities are preserved.
In fact many if not most Smalltalk classes should work just fine with minimal or no porting effort; a Smalltalk language specific compiler EBNF will most likely
be provided for importing your existing Smalltalk codebase with minimal changes.
As ZokuTalk unfolds into realized implementation more details will be disclosed.