Fear and loathing of the "perlification" of Smalltalk
Peter William Lount
peter at smalltalk.org
Wed Sep 5 05:05:20 UTC 2007
Jason Johnson wrote:
> On 9/5/07, Peter William Lount <peter at smalltalk.org> wrote:
>> You are still stuck on byte codes eh? That is so 1960's. I invite you
>> into the innovation frame of mind, discard what you think you know about
>> this topic, and open your eyes wide open and imagine a future with
>> powerful blocks. We are just scratching the surface with this one new
>> block feature. I've invented ten more powerful capabilities for blocks
>> and integrated them so they work well.
>> There are many ways to implement the two evaluators for blocks. For
>> example, depending on your byte code set you could have a bit for a
>> flag, or you could duplicate the byte codes with one set for each
>> evaluation type. Or you could get rid of byte codes all together which
>> is the better approach.
> What Smalltalk system doesn't use byte codes?
> As far as the blocks question, I think it's not a bad idea. The idea
> of a block is already overloaded somewhat with:
> [ "..." ] fork
Hmmm.... that's actually a good question... a number of them use native
code but may actually use byte codes as an intermediate step... Byte
codes are fine but they loose information that advanced compilation
techniques really need. I believe that there are papers out there on
this... can't remember the titles at the moment... Byte codes is just
one way to implement the world.
The version of Smalltalk that I'm working, on, known as ZokuTalk(tm)
won't use byte codes at all anywhere. It goes from the parse tree
structure to another set of internal representations (which don't look
like byte codes) and then to native machine code... that's the design
anyway. There are no saved byte codes. At this time I'm working on the
compiler. ZokuTalk is a layer upon the ZokuScript(tm) language. The
intention of ZokuTalk is to be highly compatible with the Smalltalk code
base and language syntax. ZokuTalk translates into ZokuScript and then
to native code through a number of internal layers none of which are
byte codes. ZokuScript is a decedent of Smalltalk, Lisp and a group of
other languages and takes Smalltalk and object languages to a whole new
level. Blocks feature prominently in ZokuScript as does a whole new meta
facility. In fact there are about ten or fifteen new dimensions of
capability that I've been able to integrate into Blocks. Messages are
also fully first class objects for the first time in any language.
Remember Alan Kay said: "Smalltalk is object-oriented, but it should
have been message oriented" and "The big idea is 'messaging'". Those are
key thoughts for a meta system. The breakthrough achieved in the
ZokuScript syntax is the integration of meta syntax using fully
recognizable Smalltalk style syntax and message sending itself to
implement and access all aspects of the entire system, even components
inside the virtual machine (if you want to call it that). No additional
syntax characters were needed! So I gather that there is at least one
version of Smalltalk that doesn't use byte codes.
The Self language takes things the other extreme and minimizes the set
of byte codes to seven core codes. Then methods are compiled to native
code on the fly, and with multiple compiled versions based upon the
actual parameter objects that are passed into the methods. So a method
might have a version optimized for integer parameters and another for
floating point or yet another for fractions; plus a general purpose
version. There is no need really for Self to have byte codes at all
other than as a compact representation.
Also the Audition Smalltalk clone that the now defunct Synaptec
Corporation of Vancouver, BC was working on for the National Research
Council of Canada wasn't based upon byte codes but upon a Forth like
virtual machine with an unlimited extensible set of primitive operations
that implemented and allowed for low level extensions (and for
variations in the input syntax of methods). Oh, this is one project that
makes me shy of various input syntaxes for methods, since it just makes
life confusing. Having one potent yet simple and beautify language that
can handle a huge variety of problem representations is valuable.
Smalltalk can represent a lot, however, with some judicious extensions
it can handle much larger set of inputs.
Merging of Blocks and Methods in ZokuScript and Also Potentially for
For example, blocks and methods at the source code level are 95% the
same. In ZokuScript they become the same and completely interchangeable.
Sure at run time the system needs to implement them differently. This
enables the elimination of the Smalltalk legacy chunk format for source
code that serves little purpose anymore. It also makes supporting other
object models trivial at the source code level.
Here is an example of a "method" being defined as a "block" and stored
as a method on a class, Person. Note how the block includes a name, thus
the block is a keyword named block.
Object subClass: #Person.
aBlock := [firstName: firstNameString lastName: lastNameString |
firstName := firstNameString.
lastName := lastNameString
Person addInstanceMethod: aBlock.
Part of the point of merged blocks and method source syntax is the
elimination of a cryptic syntax, the source code chunk format; another
point is the options it opens for alternative object models; another and
very important benefit is that the source code falls into one uniform
syntax with the maximum expressive power from each element of the
syntax; this results in a language integration that is flexible and
powerful. At least that's the goal.
The above integration of block and method syntax would also work for
Smalltalk quite wonderfully. That is why I share it with the group. I've
shared it with others before but it's time to let the wider world know
about it. I hope that you see the benefits and think it valuable enough
to add to your Smalltalk system.
Welcome to one of the futures of Smalltalk, ZokuScript.
ZokuTalk and ZokuScript are trademarks of Active Information Corporation.
More information about the Squeak-dev