™ | ZokuTalk™ Lisp, Smalltalk, + Others Hybrid

... reinventiing computer languages ...
... booting ...
... parser and compiler in progress ...

NanoBlog ZokuTalk Article Series Index
Objects, An Expanded Meta Definition
Collected Notes Other Language Paradigms
Meta Protocol
Current Progress
Project Manager Upgraded
ZokuTalk 1.0 2019 Target

ZokuTalk™ Objects, An Expanded Meta Definition
by Peter William Lount, 20190628
Copyright 1997-2019, all rights reserved.

What are #ZokuTalk #Objects?

1) Entities with a #Unique Identity (OID & VID).

2) Abstract Datatypes with relevant related data or object items.

3) Related code methods (aka functions) that operate on the data.

4) The ability to #Encapsulate the items in this list.

5) #Sending and #Receiving #Messages between objects is the big idea not functions.

6) A process or #Thread of #Execution.

7) Uniform default Semantics for single threaded, multi-threaded, multi-process and multi-node consistent execution.

8) Objects are immutable when versioned.

9) Objects are versioned when committed within an #ACID #Transaction.

10) All computation is performed within a #Transaction environment.

11) Object versions may be #Durable by #Persisting their #state.

12) Objects can have #Consistency Verification and Validations applied any time and at commit time for "data validation 101 safety" purposes.

13) #Transaction instances (by default) link the version of code that the objects are using tying code to the versioned object instances for longterm debugging and validation purposes. You always know what code modified what object state changes.

14) ZokuTalk objects are connected entities that tie together the above, and other, essential aspects into a consistent system for maximum capabilities and safety for real world pragmatic applications and systems.

15) ZokuTalk objects make use of a powerful minimized uniform EBNF Grammar known as the #MOBS syntax for #Messages, #Objects and data, #Block closure #Syntax.

16) All #MetaProgramming is done using the full MOBS syntax for maximum power.

17) The #ZokuTalk #ExecutionEngine is fully object oriented and first class meta execution objects; regular objects are executed by the execution engine and may access their refelective metadata via the #meta object in the current execution context.

18) ZokuTalk objects exist within a transaction meta execution context that may or may not place additional runtime constraints upon them for resource usage, security or other purposes. This is one reason #Live runtime #DynamicTyping is so important.

19) Objects have an 'object header' and a 'behavior' aka 'class' pointer; objects can have an internal byte array, an internal object pointer array, and named instance object pointer variables. Similar to Smalltalk's approach. Foreign Objects have an 'object header' and a 'behavior' pointer prepended. Alternatively objects may have different memory layout representations, for example instead of instance variable object pointers they can have slot objects for an instance variable.

ZokuTalk™ Collected Notes on Language Paradigms
by Peter William Lount, 20190628
Copyright 1997-2019, all rights reserved.

Collected notes on aspects of ZokuTalk and other language paradigms such as Pure Functional Programming Languages and Pure Functional Datastructures (aka datastructures restricted as Directed Acyclic Graphcs (DAGs) due to the top down linked structure being easy to use safely). The Lisp heritage of ZokuTalk via Smalltalk is also covered as well as ZokuTalk's incorporation of other powerful Lisp concepts.

Unlike Pure Functional Programming languages #ZokuTalk isn't afraid of changing state of data objects nor of side effects or runtime errors (arguably #Smalltalk like systems are far better at error handling). The #Principle of #Encapsulation is the anthesis of some #FP systems.

#ZokuTalk can use the simplistic #Monad objects that hide the actual changing of state or dealing with side effects that are required lies for the facade of Pure Functional Bliss. #ValueHolders and many other kinds of Monads have existed in Smalltalk like systems forever.

A primary reason for a powerful #MOBS syntax in #ZokuTalk is providing one powerful programming language for all general purpose & meta programming alike. All little languages other than atomic data items like numbers, symbols, characters, strings, ..., all use MOBS syntax.

As much of the #ZokuTalk system as possible is in the #ZokuTalk object library. We shall see if the entire system can represent itself in the object library, in theory there isn't a reason why not, in practice theory isn't always the best choice. :-)

In the real world all systems have to deal with "side effects" and external systems be it interfacing with Operating Systems APIs (Win32 dlls, Unix shared libraries, ...), input and output of data and objects from other systems, errors in communications or what not. Embrace it.

Considering how #ZokuTalk might compile directly to #FPGA. Work on this idea will develop over time as I learn #FPGA in depth and complete the #ZokuTalk compiler for X64, ARM and #RiscV 32, 64 and 128 bit cpus. A direct FPGA output would be quite different than any of these.

Distinctions: 1) Imperative programming, assigning values to variables. 2) Functional programming, applying arguements to functions. Recursive. #ZokuTalk #Smalltalk allow both approaches using full pure functional block closures and the #curry methods on collections.

The sum function example can be done in Smalltalk and #ZokuTalk in the exact same way using recursion and not using assignment to variables. Advantage #ZokuTalk.

Pure Functional programming languages do not allow for side effects and thus can't take advantage of the assignment to variables not thus their virgin purity prevents them from sticking data into instance variable slots of the abstract types known as Objects that merge code+data.

Pure Functional Languages (and data structures) attempt to impose a kind of sexual purity on programming but like the priesthood it is a lie as the evil side effects rear their ungly state changing reality under the covers... #State must be saved in variables in real systems.

Is #Smalltalk a #Functional language? Is #Lisp #Object #Oriented? link, link. #ZokuTalk evolves upon Lisp, Smalltalk, Erlang, and 100+ other languages including #PureFunctional #DataStructures and #FP capabilities and #ACID #Transactions.

However #ZokuTalk goes far beyond mere one directional limited #DAC Directed Acyclic Graphs, a serious real world limitation of Pure Functional Datastructures by embracing bidirection cyclic network graphs of connected objects that enable full connectivity while being #ACID safe.

Basically the limited functional programming notion of #DAC unidirectional datastructures is such a severe limitation that I spend the time to invent a means to enable fully cyclic network graphcs of connnected objects as the application systems require.

The #ZokuTalk fully cyclic connected networks of objects of real world application systems are fully permitted and new connections, editing existing connections, deleting connections, annotating connections, ..., can all happen within tiny #ACID #Transactions for #maximal safety.

Pure functional datastructures are the wrong model to adopt as it doesn't meet the needs other than some speciailized datastructures such as #GIT's commit tree. The more powerful #Principle to adopt are #ACID #Transactions that enable #safe (dis)connection of objects.

While some internal structures within #ZokuTalk have pure functional datastructure characteristics many internal structures have bidirectional connections to permit network traversal in both directions when needed. The best of both worlds with ease. No #DAC contortions required.

It turns out that #Smalltalk, and #ZokuTalk, inherits many capabilities from #Lisp #AI systems. In many ways ZokuTalk is a reworking of Lisp and a cleaning up of Smalltalk that eliminates all the legacy cruft from Smalltalk-80 et al..

Smalltalk and #ZokuTalk have many functional and even #PureFunctional capabilities. For example Boolean's "ifTrue:ifFalse" and Object's/UndefintedObject's "ifNil:ifNotNil:" message variants are fully #PureFunctions that make use of full #BlockClosures aka functional #Lambdas.

#ZokuTalk evolves #Lisp and #Smalltalk while providing a far more powerful safe computational environment that enables full network connected real world modeled objects instead of merely tree datastructures that limit pure functional datastructures.

#Lisp {link} is quite powerful in its own right.

#ZokuTalk takes the important capabilities of Lisp and evolves them further while using #AlanKay’s Big Idea of #MessagePassing #BetweenObjects and full #BlockClosures to get work done.

In reviewing a number of functional programming languages to see if there were any compelling benefits to incorporate into #ZokuTalk it turns out that some FP ideas are best to be avoided or done a different or better way.

In reviewing Clojure it became apparent that the designer was making design choices for the language that were almost 180 degrees in the opposite direction from the design choices already made for #ZokuTalk. That's what happens when first principles collide.

Of the 50 or 60 or so design decisions in common with #ZokuTalk and #Clojure it turns out that only a few were choosen that are the same, the vast majority of their design choices would be a lessening of power for #ZokuTalk users. Their solutions involved too much complexity.

The ideas of #ZokuTalk aim to deliver power to the end users including power users, as well as developers. The goal is to make programming easier while providing powerful capabilities that keep the data objects safe.

#ZokuTalk's implementation of #ACID #Transactions provides a far more powerful and compelling process scaffolding for all aspects of computing than does the pure functional langauges or pure functional datastructures could ever provide. Transactions beat FP solutions hands down.

While the #ZokuTalk grammar EBNF didn't require any changes to support #ACID #Tranactions the typical "virtual machine" required massive changes and was jettisoned for the far superior #BareMetal #FullyObjectOriented #ExecutionEngine approach.

In addition there are extensive new objects in the object library to support the #ACID #Transaction paradigm of #ZokuTalk. You can think of the runtime execution engine as being similar to C's libC runtime, there are a set of objects that implement the engine that are needed.

Really this isn't any different than most languages that require a virtual machine other than that there is no existence of "byte codes" in the #ZokuTalk execution engine as byte codes are ultimately self defeating due to limiting possible compile time optimizations.

A primary advantages of #ZokuTalk's direct #ExecutionEngine being on the #BareMetal is maximizing the power of current advanced CPUs for optimizations. This allows the execution engine object oriented design to be intimately connected to the actual machine for performance.

#ZokuTalk's compiler, being implemented, is targetting Intel/AMD 64 bit and 32 bit processors, then ARM variants in 32 bits and 64 bits. The #RiscV #ISA variants are also being targetted in 32, 64 and 128 bit as they are the future and for use with #FPGA chips.

#ZokuTalk is more functional than functional languages. 🙂🖖

Zokutalk is functional plus.

Zokutalk #Objects plus #ACID #Transactions are more powerful than any pure functional programming language or pure functional datastructure.

#Network > #Tree

In #ZokuTalk at development time and runtime the "types" of parameters to methods, temporary variables in methods, and instance variables in objects can be collected via #DynamicTypeInference so you can see and examine the actual flow of objects throughout the pathways of flow.

In #ZokuTalk you can make use of the data and Object Verification and Validation library of objects to perform runtime and compile time "class" or "type" verification and validation aka data input 101. Using #Slots as instance variables you can put contraints on the contents.

In #ZokuTalk you are free to constrain your data and object flows as you see fit or require for proper functioning of your application or systems. You can also leave it wide open as most Smalltalk applications systems have benefitted from. Slot constraints limit where needed.

It turns out that locking everything down as staticly typed and pure functional languages force you to do is like having your application objects and data walk around town wearing straight jackets that prevent them from taking certain streets or avenues or subway train routes.

Experience has found that the more highly contrained your application & systems objects and data are the more code bloat you'll have especially in staticly typed or pure functional languages where you end up with a combinitorial explosion of not needed variations of code.

One of the #Principles that #SteveJobs applied to his products is that the code not written has fewer bugs. In other words, the tighter the application and systems code the fewer bugs it is likely to have. A bloated application with N times the code has more bugs most likely.

Pure functional types and their alleged type safety do not guarantee a correct program. Fact. Types give a false sense of security. Observation.

Remember you are free to use your pure functional language all you wish. No one is stopping you other than you.

#ZokuTalk provides a more powerful pragmatic approach than pure functional languages could ever provide while adopting all compelling capabilities from FP and pure functional datastructures and expanding far beyond. #Network datastructures > #PureFunctional #DACs. Fact.

link Smalltalk fortunately is a language that lets one reprogram the OO model towards a better invented future #OMO (Objects Messaging Objects). In evolving #ZokuTalk from #Lisp, #Smalltalk, #Erlang, and a host of other language capabilities what matters are design principles.

Sure one can go in and add in some quick features to the grammar and many Smalltalk's have done that. To go deeper takes time and thoughtful application of #principles of #design to not just extend but also prune the grammar to its bare essentials to reveal the full power.

Once the grammar of Smalltalk has been pruned down to it's essential core the language can really evolve and gain the full power of #compelling #capabilities from first principles not to mention a few other languages with something serious to offer. link

It works fine in the large when one is carefully methodical about the transformations one is making. The OO model, grammar and capabilities of #ZokuTalk are a massive improvement yet maintain core compatibility. As for bad style choices, well bad design leads to bad code.

A large team of 150 people to 500 people are going to create a lot of code in any language. It is not possible for a single person to comprehend every single chunk of code in their brain at once. This is more of a human team organization issue and staff turnover challenge.

Alien technologies coming from #ZokuDotCom and it's #ZokuTalk linguistic powerhouse. It will blow your collective hiveminds! New dimensional doorways open up gates to entirely new futures! Applications and systems beyond tomorrow! link

#Exploding #Myths about #Smalltalk. From large teams to the individual, Smalltalk is about making software more accessible and easier to develop and modify. "I made up the term 'object-oriented,' and I can tell you I did not have C++ in mind." - A. Kay link

"In the early 2000s, the U.S. joint military used Smalltalk to write a million-line battle simulation program called JWARS. It actually outperformed a similar simulation called STORM written in C++ by the U.S. Air Force."

"... That by itself was an astonishing testament to the capabilities of the language."

I was part of the core team that built das #Kapital at 60 Wall St..

"Smalltalk was used by JP Morgan to write their massive financial risk management system called Kapital. In fact, Smalltalk is quite popular in the financial industry; other users include Desjardins and UBS."

It works fine in the large when one is carefully methodical about the transformations one is making. The OO model, grammar and capabilities of #ZokuTalk are a massive improvement yet maintain core compatibility. As for bad style choices, well bad design leads to bad code.

#Scalability in computer languages. What does it mean? What metrics are used? Some have put forth the notion that team size of developers is one metric for scalability, 10 or so, 150, 500, larger teams. What are the issues when there are massive numbers of people vs a few?

#Math #Maths #Smalltalk #ZokuTalk Sane systems use one based indexing. He he. Actually ZokuTalk also supports zero based indexing as it's important to be compatible with foreign iCk(); languages that are zero based. ZokuTalk has a unified interface to foreign systems.

~"The lambda calculus was introduced by Alonzo Church in the 1930s. He isolated what is now called the #untyped #lambda #calculus. He also introduced a computationally weaker, but logically consistent system, known as the simply typed lambda calculus." Lambda Calculus

ZokuTalk™'s Meta Protocol
by Peter William Lount
Copyright 1997-2019, all rights reserved.

ZokuTalk™ EBNF Keywords:

Singleton-Instances EBNF Keywords:

Pseudo-Variables EBNF Keywords:

The global namespace object root node:

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.

A core observation is that everytime you need special syntax the language loses genericity and makes life difficult for programmers, users, and power users alike. The core design principle to come out of this observation is that in ZokuTalk there is only one language syntax for all forms of programming, no little languages, just the full power of the MOBS syntax. Messages as the big idea as Alan Kay imagined. Objects that fuse data, relationships and functions aka methods into discrete related pieces of code and data. One MOBS syntax to rule them all.

The EBNF based Grammar Syntax definition of ZokuTalk has three main areas to implement the core MOBS syntax. Code is Data is Objects is Code ... is an important #Homoiconic Principle in the design of the ZokuTalk grammar. This has lead to a reduction of the grammar to its essence to support source code, data atoms and literals, blocks and objects. A uniform grammar is essential to keeping a language mean and lean for maximal computational capbilities. It turns out that decluttering computer language grammars makes them far more powerful.

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. To support sane mapping of foreign functions, that only use a single function name yet have multiple parameters, to ZokuTalk method names "Function Keywords" were added to the ZokuTalk grammar.

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.

In ZokuTalk the base namespace is called "zoku". Elements of this system "dictionary" or rooted namespace can be accessed using the namespace syntax. For example, zoku::core lets you access the core namespace inside the zoku namespace. Note that "::" is a binary message that namespaces understand and which are used to navigate the name space tree. Namespacs are still a work in progress and will likely change or be refined for ZokuTalk 1.0.

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. Most aspects of ZokuTalk a quite fixed and locked down at this point, however some aspects are not yet fixed in stone and are likely to change.

Current progress towards ZokuTalk 1.0
2017 and 2018 saw significant advancements in the design and implmentation of ZokuTalk. Implementation work began on the Parser and Compiler impmenentation in 2018. A large amount of time has been committed to learning what to change and what not to when it comes to the ZokuTalk EBNF Grammar Syntax. Also learning parser writing at the same time as attempting to pin down a new language syntax was a bit of a challenge. After a number of false starts the parser is about 1/2 done.

In 2017 the ZokuTalk Language EBNF was nailed down and frozen with only a few minor improvements made to the ZokuTalk EBNF Grammar since then. Foreign Function Keyword message syntax was added to support mapping of C, C++, Java, ... and other "round parenthesis" languages which have a single "identifier" for their function names while having zero, one or many unnamed parameters.

Expressions recently were improved so that they can have more than one statement in them including temporary variable definitions, of course the last statement in the expression list of statements is the one whose object value is result of the immediate execution of the expression to be compatible with existing more limited expression syntax in Smalltalk systems.

Single colons, ":", as "binary operator message sends" are being considered for inclusion in ZokuTalk's grammar; this is an influence of Cuis Smalltalk but was also considered before, it seems that Cuis is using the binary operator message ":" to number to construct instances of the Time object which is rather nice. As this usage would obliviate a special syntax for time data it is worthwhile including the generic ":" binary operator in ZokuTalk.

Double colons, "::", without any characters in between them are also being considered as binary operator message characters. The first usecase for this would be Namespaces. While many Smalltalk's use the period "." as a name space seperator which is also how a number of non-Smalltalk languages write namespaces the period is already used for a number of grammar elements and wouldn't be using a generic message send approach. As much as possible ZokuTalk aims to make use of message sending to implment capabilities as it is far more flexible and more powerful usually. The use of the double colon binary message send for namespaces would go something like this, "zoku::core::Object subclass: #Point" to create a subclass. The first send of "::" to the namespace "zoku::core" gets one the "core" namespace where the class Object lives, to obtain "Object" one uses the second message send of "::". This might be how it's done, we'll see, this part is open to change. Fortunately if it's implmented this way it's implmenetation is essentially entirely in the object library and can be altered easily.


20190112 ZokuTalk Source Code Project Managment Milestone Arhieved!
ZokuTalk now has a Project Manager that can do two things, (1) In the middle of January 2019 the ProjectManager class in the Pharo Smalltalk development environment was enhanced to support the latest Pharo Smalltalk, this enables the project manager instance to emit the ZokuTalk code base in Legacy Smalltalk Source Code Chunk Format for moving it forward to newer versions of Pharo Smalltalk (version 7 is on the horizon). In addition the project manager was enhanced to emit the ZokuTalk code base in ZokuTalk Source Code MOBS Format (Message, Object & Data, Block Syntax). Two files are emitted, a Smalltalk version and a ZokuTalk version of the code base the project manager is looking at. I generally have it emit the source code at every image save.

Another project manager instance was also set up to collect up all the source code that will be exported from Pharo Smalltalk under the MIT License for incorporation as code into the ZokuTalk system. This is an ongoing project as the methods need to be minimal Smalltalk syntax to be compatible with the ZokuTalk minimal syntax as there are many syntaxes eliminated from ZokuTalk as they are done a different way or not used. For example, Smalltalk primitive syntax is entirely eliminated and a more modern approach taken at the Execution Engine level.

In any event the Bonai pruning of any MIT Licensed Pharo Smalltalk source code will take time. All primitives referred to will need to be rewritten. Any classes not being exported will need to not be referred to. For the most part the classes being borrowed are base classes inherited from Smalltalk-80 excluding all GUI classes.

ZokuTalk 1.0 2019 Target
ZokuTalk 1.0 is being worked on for a 2019 release date; fingers crossed. The first version of the ZokuTalk compilier is currently about 1/3rd completed.

Pharo Smalltalk is currently being used as one of the tools for the development of ZokuTalk as it's a mature and stable Smalltalk. In addition many objects and their methods are being carefully selected and added to a Bonsai trimmed set of classes and methods being ported over to form a core set of seed code for ZokuTalk. However all primitives required will be rewritten from scratch as the legacy primitive syntax and virtual machine designs have been abandonded for a direct ZokuTalk BareMetal Runtime Execution Engine for the purposes of raw performance and more powerful capabilities.