Smalltalk.org™

Smalltalk.org™
... reinvention in process ...


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 system access.

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 primitive add64Integer: 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: 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.