... reinvention in process ...
... rebooting ...
Smalltalk Blocks and Closures
ZokuTalk
On Messaging, Objects, Encapsulation, Late Binding, & Idempotence
Smalltalk Systems
Components
Contribute
Smalltalk Blocks and Closures
by Peter Lount, 20201016.
In the video "Smalltalk blocks and closures origin and evolution" by Juan Escalada we explore the history and evolution of the humble yet super powerful block.
"Even though there probably isn't a Smalltalk developer who doesn't use Block on a daily basis, it's not common knowledge that they are based on the idea of Anonymous Functions, nor that their Closures' origins can be traced back to Scheme.
The idea of this talk is to analyze the origin of this tool that defined Smalltalk, it's evolution until it became the full closure that we know today, and have a better idea of the potential advantages it provides." - Juan Escalada
Nor is it known that many of the blocks used in the base classes and users applications are actually technically Functional Programming based upon the age old principle of "idempotent" functions and computations where the input data (and objects) alone are used to computer the results of the block with no other external inputs the results will be the same everytime. If the idempotence property is present this means that the block of code is purely functional and will always produce the same results given the same imputs. However this isn't enforced in Smalltalk, it's easy for a block of code to access an external source of information, such as the system time, that can then change the computational results. In many functional languages idempotence is enforced.
In the ZokuTalk variant of Smalltalk a block may be configured with a message to enforce an idempotent or pure functional computation; for example, "aList doIdempotently: [:each| each doSomeComputationWithInput: anObject]" makes sure that "anObject" and it's connected graph is the only external piece of data to the block that is accessed in the example.
Many existing methods are functional in every Smalltalk system, for example, the classes True and False implement #ifTrue:, #ifFalse:, #ifTrue:ifFalse:, & #ifFalse:ifTrue:. These four utterly essential methods in Smalltalk and ZokuTalk are pure functional blocks of code! They are idempotent as well based upon the receiver and their input parameter blocks, keep everything the same (idempotence principle) and they will be fully pure and deterministic, and thus functionally pure. Of course the true and false parameter input blocks are not necessarily an idempotent computation and usually due to the state changes within the objects changed by computations in the block are decidely not idempotent (the non-functional state change approach to computational systems that produce real world results).
The history of the Smalltalk block goes deep into the Church and Turing theories of computation. "Annoymous Functions" are merely at one level "functions with no name" which is what blocks are. It should be noted that Smalltalk's blocks track back to Alonzo Church's "untyped lambda theory" without the OCD (Obsessive Compulsive Distorder) use of excessive "static type specification" of every receiver of a message, of every parameter, of every return value from a method or a block. ZokuTalk of course carries forward this Smalltalk lineage of the extremely more powerfull untyped approach while enabling "type" (really class) "conversions" and "data validation and verification rules" using the full power of the ZokuTalk MOBS (Messages between Objects within code Blocks Syntax) language, no overly simplistic "type specifications" that (1) lie about the types permitted, "int * foo" lies in C & C++ for instance because "null" isn't listed as a valid type on the pointer to an integer variable foo; really in C it should be "int,null * foo" to be a proper type specitication language.
In ZokuTalk you can use the VerificationAndValidation library of objects to filter and convert objects based upon their class (aka type) or any other attribute at all or both! You can't tell C that you only want that pointer to foo to have the integer values 0 to 100. In ZokuTalk the Validation and Verification object library enables you to construct the most powerful validation and conversion rules because it lets you do so in the exact same MOBS language that you write all your other code in!
The main places where data valiation, verification, converstion, filtering and other similar rules are appropriate are parameters to "system primitives", "foreign functions", "between inter application interfaces" (for integrity and security), data input 101, and "transaction consistency" reasons.
It's decidedly and certainly not appropriate to put type specifications on every variable, every method parameter, every method return value; to do so is bordering on an Obsessive Compulsive Disorder (OCD) in the computer industry; it's no wonder it's accepted though given the often extreme pedantic and savant nature of some to many programmers. Don't kill the messenger please, just reporting observations from decades of working with a lot of programmers. Thanks.
The power of Blocks can't be understated especially with the natural and easy syntax of blocks used in Smalltalk and ZokuTalk language syntax. The humble uncluttered block, [...], that computes something, "...", is at it's core very clean and simple syntax yet provides extreme powers to the developer. This is taken even further in ZokuTalk where blocks obtain superpower status and are extended and useful in so many more ways!
ZokuTalk™ Articles
ZokuTalk is an independent indevelopment reboot of Lisp, Smalltalk, Erlang, Forth, and a host of other languages; ZokuTalk inherits capabilities from these languages while avoiding, ahem, less optimal solutions from a large host of over 100+ other languages that have been scoured for compelling innovative capabilities.
At the core of ZokuTalk is the notion of MOBS, Messages being sent between Objects (as well as data) with Block lambda contexts in an uniform powerful Syntax. A minimal ZokuTalk MOBS syntax intersects with a minimal Smalltalk syntax by design. ZokuTalk's MOBS fully supports Alan Kay's big idea of messages being passed between objects in many ways not found in object systems; in addition Alan Kay recognized the important Homoiconic, same glyph, same syntax, notions from Lisp, these are infused into this core MOBS syntax: Code is Data is Objects is Code is Objects is Data is Code.
Pharo Smalltalk is currently being used as the development platform with work progressing towards independence day with a new form of direct baremetal fully object oriented execution engine not based on virtual machine designs; a new Project Manager enables ZokuTalk to emit both legacy Smalltalk source code format as well as the refined MOBS source code+object+data format. Essence# Smalltalk was the first Smalltalk to adopt a portion of ZokuTalk's MOBS syntax.
On Messaging, Objects, Encapsulation, Late Binding, & Idempotence
by Peter Lount, 20190629.
Expanding on Dr. Alan Kay's often quoted statement, the most important big idea is messages being passed between objects. Objects are also key as they provide packages of related data items and code that performs operations on the data or using the data for real world computations. Encapsulation of related data items and related code methods provides protection and hiding of the "state" aka the data that relates to the state of the object. The processing details are hidden and encapsulated within code methods which also provide "Untyped Lambda Calculus" late binding of messages to methods at runtime; there is only one "type", that of Object where everything is an object that responds to messages sent to it at runtime.
It is interesting that some in the Pure Functional Langauge domain have misinterpreted Alan Kay's comment to mean that "messages alone" are the big idea and that you don't require the storing or accessing of "state" (aka data, values in variables of an object) in Objects. They make this mistake or distortion of the full Alan Kay statement so that they can preserve their notion of "functional purity" aka "referential transparency" aka "reproducable deterministic behavior" aka "idempotence" of their pure function computational model where "pure functions" only compute using the function's inputs to produce it's outputs. The notion of an object violates this "pure" model as it stores state beyond the life of the pure function or accesses stored state not passed into the pure function.
The Pure Functional Language focus is needlessly too narrowed to the scope of a single pure function as their primary approach. Referential Transparency, Reproducable Deterministic Behavior, & Idempotence can be achieved in any scope size of computation involving millions of objects and thousands of methods as long as the entire computation scope has the pure or idempotent property of only computing using the inputs to compute the outputs (and not accessing stored state that was not part of the set of inputs or writing state that was not part of the output set of objects; actually this can be relaxed in some cases such as writing a not used for input log file).
The image above is an example of the use of an idempotent reproducable deterministic computation in ZokuTalk using the wider scope within a Block that contains an Object of the Cube class that instantiates an instance and fills in the x, y, and z dimensions using the input parameters to the block and then computes the result in an idempotent manner. This example is quite simple and can be done in any Smalltalk by sending the block value or value:value:value: with the inputs. ZokuTalk takes it further by ensuring that the computation within the block is a "pure isolated transaction" by preventing it from accessing state from outside the block and raising an exception if the code attempts to do so.
One reason that idempotent computations and processing is important and useful is that if a block of code, with as many objects as you want, is referrentially transparent, has reproducable deterministic behavior and is idempotent, aka a pure block, it can safely be executed in parallel with a simple fork operation in Smalltalk type systems, or even better it can be executed in parallel using a native operating system thread of its own (as long as the language system has parallel garbage collection or can guarantee no movement of the objects in the native os forked off threads, and can guarantee isolation from other threads modifying objects in use by computation thread).
In ZokuTalk enforcing "pure isolated transactions" provides a systematic gurrantee that such parallel execution is isolated thus thread safe as long as you also heed thread synchronization such as using a Future object, parallel join or other thread synchronization techniques.
Pure functions as well as pure referentially transparent idempotent blocks of code are timeless, in that they can be computed in parallel at any time in the past and present. If the results of the computation are cached one need not recompute when the same inputs are used again and referrentially transparency is achieved; many compilers make use this technique to great effect for optimizations.
There are many benefits to the ideas from pure functional programming languages that ZokuTalk has inherited, and that even other languages can take advantage of if the programmer takes the manual care to ensure the idempotence principle. Heck, in one video game I wrote in 6502 Assembly Language the game map generator was fully idempotent across copies of the game by just typing in the same 12 hexidecimal number into other copies the game! I wrote that game back in the mid 1980's before I even new about pure functional languages showing that these techniques have been around since the dawn of time of computing.
Smalltalk Systems
There are many excellent Smalltalk Systems, open source and commercial, for you to learn from, have fun with, use to build apps, deploy serious applications within companies large and small as well as on the web or phones. A number of the commercial Smalltalks also have free personal use or good development licenses, check them out.
OpenSource (License)
Pharo Smalltalk (MIT).
Squeak Smalltalk (MIT, portions Apache).
Cuis Smalltalk (MIT).
GNU Smalltalk (GPL).
Dolphin Smalltalk (MIT)
Amber Smalltalk (MIT).
Redline Smalltalk (MIT).
Essence# Smalltalk (BSD).
Susie Scripting Smalltalk (Public Domain).
Little Smalltalk (Various, Public Domain, MIT, ...).
Bee Smalltalk. (MIT), release coming soon apparently. GitHub. Bee Blog. Paper (PDF).
Newspeak Lanaguage (Apache 2.0 license, portions MIT).
Scratch Smalltalk Wiki (GPLv2 and Scratch Source Code License).
Commercial
Cincom VisualWorks Smalltalk
Instantiations VisualAge Smalltalk
GemTalkSystems Database Server Smalltalk
Smalltalk/MT
Smalltalk/X (Free to use).
Smalltalk Like
Self Language
io Language
Slate Language
Components & Sub Systems
Usefull Smalltalk open source components and sub systems:
SeaSide web app engine (Pharo, Squeak, Gemstone/S, Cincom, etc.
Useful Smalltalk open source components from Peter W. Lount:
SortCritter for Multi Column Sorting.
ProjectManager for easy project file outs.
Contribute to Building the Smalltalk Community
To contribute an article, item of interest, name of a Smalltalk not listed, link to a cool component or sub system, to help rebooting the site, etc please send a an old fassioned not snail message to "c o m m u ni t y bu il d ing" at this web site name... with all the spaces removed.
Version: 20201016_v001