We have moved this blog entirely to here: http://redline.st
Quite a few people have asked me if Redline Smalltalk will support the use of InvokeDynamic, and the answer is YES.
What I am juggling are the various demands of the project, work life and personal life. As far as Redline is concerned the goal first and foremost is to get it working, then make it fast. Work is continuing daily on this front and we are starting to get some contributors which is very exciting.
For more information on InvokeDynamic I suggest you look at Charles Nutter’s excellent post on the topic here.
There have been a lot of changes under the covers of Redline Smalltalk as it gets more and more functionality and significant architectural changes to make it a real Smalltalk. A real Smalltalk that is fully dynamic, and with message sending at every level.
I’m very proud of where I have come with Redline Smalltalk and how much of a real Smalltalk it is. It has been quite a challenge in time management and there have also been many versions of Redline, including large re-writes as the commit logs and CHANGES file will attest.
What has not been changed is my desire to have a real Smalltalk you can run on the Java Virtual Machine; allow you to call other code on the JVM not written in Smalltalk; and have other code call your Smalltalk.
What still needs to change are some of the posts here that are no longer correct as they don’t refer to the current implementation of Redline Smalltalk. I’m confident the current incarnation of Redline will be the one that makes it to a V1.0. As such it is now time to delete these old incorrect posts and begin a new series that is correct.
I hope you will follow along with the renewed series “Smalltalk in small talks.” and continue to take an interest or even participate in the development of Redline Smalltalk.
First I want to let you know that Redline Smalltalk will be presented at the 19th annual International Smalltalk Conference is in the heart of historic Edinburgh
Secondly, Redline Smalltalk is moving forward and gaining momentum. Below is an example class from the emerging Runtime:
Object < #Behavior - new "Answer a new initialized instance of the receiver." ^ self basicNew initialize - basicNew "Primitive. Answer an instance of the receiver (which is a class)." <primitive: 70>
If your at ESUG be sure to say hi.
This is just a brief post to let you know what is happening with Redline Smalltalk.
Currently I am streamlining the grammar after discovering a big delay in parsing caused during backtracking in the grammar. The new streamlined grammar is smaller and much more efficient than the previous. It has no backtracking at all and no grammar conflicts (so far).
I attended Smalltalk Solutions 2011 in Las Vegas and presented Redline Smalltalk with Sean T Allen. You can see the video here: http://vimeo.com/22084832 The presentation was well received and Sean and I presented again at the New York Smalltalk users group. Sean and I want all our presentations to be both informative and entertaining.
I’m currently trying to get funds to present at ESUG Smalltalk 2011 in Scotland. If you want to help you can here: http://pledgie.com/campaigns/15176
I’ll try and post again to the series but getting Redline to V1.0 is the major push right now.
The goal of this ‘small talk’ is to provide information on some of the dynamics of Redline and which classes are responsible for implementing it.
Like the previous talk you can download the sources from github then checkout the tag with ‘git checkout FINDING’.
Smalltalk expressions can contain class names, for example ‘Object new’. When first seen by the interpreter they are translated into a reference to an object instance. Translation from a name into an instance involves looking up the class name in the global dictionary “Smalltalk” to get the associated class object. When found the class object is returned and pushed onto the stack. When not found in the dictionary a class is dynamically loaded from its source.
Loading a class dynamically from it’s source involves finding the class source file and loading and interpreting it. Finding the source file requires searching the source paths given to Redline with the “sourcepath” option. The following is the process for finding a class source file:
Name space support and how name spaces are paralleled in the file system will be covered in greater detail when name space support is added to the subclass creation messages.
The process of finding and loading classes is performed by the class Smalltalk (st.redline.smalltalk.Smalltalk)
Note: a “Smalltalk” global dictionary instance is not actually global to all Smalltalk code running in the Java Virtual Machine. There can be multiple “Smalltalk” instances, one per application, running in the JVM. All class objects are global to the instance that loaded them. This allows dynamic changes to objects to be kept separate between applications on the same JVM.
Smalltalk has clearly defined rules for finding the method to be executed in response to a message send. These rules are detailed in the “Blue Book” on pages 61 – 66. In a nutshell when a message is sent the search for the method that matches the selector is carried out as follows:
There is a variation of this method look up process when the message being sent is to the pseudo-variable (receiver) super. Please see the “Blue Book” on pages 61 – 66 for details. The class RObject (st.redline.smalltalk.RObject) implements the method look up and dispatch.
Each method in Redline is a subclass of the class RMethod (st.redline.smalltalk.RMethod). Defining and using a proper object for each method is expected to help in debugging, performance tuning and the dynamics expected of Smalltalk. Using a Java Method object would not have been possible since it is “final” meaning it can’t be subclassed.
To find out what Redline is doing there is a -v (–verbose) option. When turned on Redline will output messages showing in detail the processing it is performing.
A Java logging framework (SL4J) is used to perform logging output. Using a Java logging framework may appear heavy handed but Redline Web Applications will be deployed to Web Containers and will be expected to fit into those containers logging requirements.
SL4J provides a logging API where the implementation can be changed at deployment time. This provides the most flexibility for Redline Applications. SL4J’s Simple logger implementation is the default used by Redline. Note that it is possible to specify the -v (–verbose) option to Redline and see no output when configured with a logging implementation that has turned off INFO level messages.
The Next Step
In the next instalment of Redline: Smalltalk in “small talks”’ may be a little longer in the making as I am preparing a presentation on Redline for Smalltalk Solutions 2011. However, work on the code won’t stop making the next instalment bigger than usual. If you get to Smalltalk Solutions 2011 please come and say hello.
In Part 1 of ‘Message in a bottle’ we parsed a Smalltalk source file to create a tree of nodes that represents the program. We added ANTLR grammar to recognise the structure of Unary Messages and we integrated the parts to allow us to parse Smalltalk source files. In this part, Part 2 of ‘Message in a bottle’, we will make the changes necessary to generate Java bytecode from a tree of input nodes and execute them on the Java Virtual Machine.
It is suggested that you read this to understand what bytecodes are and this to understand how the Java Virtual Machine executes bytecodes.
Like the previous talk you can download the sources from github then checkout the tag with ‘git checkout MESSAGING2’. I’m assuming that those following along are looking at the ‘CHANGES’ file and comparing the ‘diffs’ to see what has changed.
To be executed by the Java Virtual Machine a program must be enclosed in a Java class. The job of turning the parse tree nodes into a Java class is carried out by the Analyser class. The Analyser inspects each node and calls the Generator class to generate the necessary bytecodes. The Generator uses the ASM library to emit Java bytecodes. The result of analysis is an array of bytes that define the generated class in Java class file format.
The array of bytecodes created by the Analyser is turned into an instance of Java Class (java.lang.Class) within the JVM by the Smalltalk class, which implements Java ClassLoader functionality. This Java representation of the Smalltalk program is executed by calling the newInstance() method on the Java class.
Each Java class is generated with an <init> method which is called by the JVM when each instance of the class is created. The instructions defined by the Smalltalk program source are encoded in the <init> method.
The steps in generating, loading and executing a Smalltalk program are summarised as follows:
The Java class generated from Smalltalk source is a subclass of ProtoObject. The generated classes name is the name of the input source file. For example, the source file ‘src/smalltalk/Test.st’ generates the class Test in the package ‘src.smalltalk’. The sequence of Smalltalk statements defined by the source file are encoded in the <init> method of the generated class. The equivalent Java source would be:
| package src.smalltalk; import st.redline.smalltalk.ProtoObject; public class Test extends ProtoObject { public Test() { // sequence of Smalltalk statements here. } } |
A Smalltalk source file is treated as a sequence of message sends which is in keeping with Smalltalk philosophy and dynamics. These message sends may define a class, a method, class instance variables or a sequence of message sends that perform other logic. Treating the source file this way gives the flexibility that a source file is not tied to a class or required to define a class, enabling a wider set of uses and a simpler Redline implementation. Those familiar with Ruby would recognise this approach.
Sending messages to objects is what Smalltalk is all about and now we can generate bytecode that does exactly that, for Unary Messages. To understand how a message send translates into Java bytecode we need to trace the analysis of a UnaryMessageSend node. Given the source defined in ‘src/test/smalltalk/Test.st’:
| Object new name |
When parsed we get a tree which contains the following UnaryMessageSend node:
When the Analyser visits the UnaryMessageSend node it carries out the following process:
In summary; the generated Test class is given a no-arg constructor that looks for the object named “Object” and makes two calls to ProtoObject.send(): the first to send the “new” message to “Object”, and the second to send “name” to the result of the previous call. If the source defined in ‘src/test/smalltalk/Test.st’ were converted in Java it would look roughly like the following:
| public class Test extends ProtoObject { public Test() { ProtoObject o1 = ((Smalltalk) Thread.currentThread().getContextClassLoader()).basicAt(“Object”); ProtoObject o2 = ProtoObject.send(o1, “new”); ProtoObject o3 = ProtoObject.send(o2, “name”); } } |
The above processing is illustrated when you run the MESSAGE2 tagged version of the Redline. Using ‘stic’ on the file ‘src/test/smalltlak/Test.st’ outputs the following trace – annotated to show the relationship to the processing outlined above:
| ./stic src/test/smalltalk/Test.st
visit(49, 33, ‘src/test/smalltalk/Test’, ‘null’, ‘st/…/ProtoObject’, null) #3 lookup ‘Object’ using basicAt(…) method of Smalltalk class. visitMethodInsn(184, ‘…/Thread’, ‘currentThread’, ‘()Ljava/lang/Thread;’) #5 call send(…) method of ProtoObject to send the message ‘new’. visitLdcInsn(new) #7 call send(…) method of ProtoObject to send the message ‘name’. visitLdcInsn(name) *Output by the method send(…) in ProtoObject when the above code is executed: send(null, ‘new’) |
The # annotation refers to the associated Analyser process.
+ Java Method argument descriptors have been shortened
Please take note that currently there are no Smalltalk classes in the runtime so you will get a ClassNotFoundException when running this example. This will be fixed in the next instalment where we resolve classes and add some initial Smalltalk runtime classes.
The Parts
This section details the classes introduced in this ‘small talk’ and the role that the class plays.
Generator: st.redline.smalltalk.interpreter.Generator
Provides a high level abstraction for defining a Java class on top of the ASM Library.
ProtoObject: st.redline.smalltalk.ProtoObject
Provides the base of every object in the Redline Smalltalk system.
The Next Step
In the next installment of Redline: Smalltalk in “small talks”’ we will enable the resolving of Smalltalk classes at runtime. This involves finding the source for a class and loading, compiling and executing it.
I have found that very elegant and simple languages are usually based on a strong principle that is uniformly applied and in Smalltalk that principle is message passing, and it provides the base of everything that makes Smalltalk great. It has even been said that message passing is more important than objects in OOP. Hopefully before the time we finish Redline the elegance of Smalltalk and the importance of message passing will become evident.
The goal of this ‘small talk’ (part 1 and part 2) is to be able to send messages to Smalltalk objects and like Smalltalk itself this ability will lay the foundation for all the other features we will add. Part 1 of ‘Message in a bottle’ will make the changes necessary to parse Smalltalk source code containing Unary Messages into a tree of nodes that represent that input. In Part 2 of ‘Message in a bottle’ we will make the changes necessary to generate Java bytecode from input nodes and execute that bytecode which will result in messages being passed to objects.
Like the previous talk you can download the sources from github then checkout the tag with ‘git checkout MESSAGING1’. I’m assuming that those following along are looking at the ‘CHANGES’ file and comparing the ‘diffs’ to see what has changed.
Sending messages to objects is what makes things happen in Smalltalk and I literally mean everything. Message passing is the founding principle and it is uniformly applied. If you are familiar with other programming languages then message passing’s effect on the execution of the program is most like calling a method or function.
Everything in Smalltalk is expressed as message passing: the sending of a message to a receiver with optional arguments, including all syntactic constructs. This uniformity and consistency makes Smalltalk incredibly easy to learn and enables new syntax to be added at any time. For example, the method “on:do” which provides exception handling wont be found in the Smalltalk-80 Kernel but it will be found in the Pharo Smalltalk, and yet it looks like it was always part of the language.
The following is the Smalltalk syntax rule and a few examples, however for a full explanation it is recommended you read the relevant section of the ‘Blue Book’:
| receiver message [: argument ] |
| Account new account debit: 100 customer name uppercase 100 * 1.5 widget moveTo: position * offset account balance negative ifTrue: [ account overdrawn ] |
The receiver is the object to which the message is sent. The result of a message expression can itself be the receiver of another expression with evaluation from left to right. The first example shows the message ‘new’ being sent to the Class ‘Account’. The last example above shows three messages, ‘balance’, ‘negative’ and ‘ifTrue:’ with ‘negative’ and ‘ifTrue:’ each sent to the result of the previous send. The last message (ifTrue:) takes an optional argument which is another message send in a [] which denotes a block of code that can be passed around and evaluated later. It is convention in Smalltalk for messages that take arguments to be followed by a colon ‘:’. It is possible for the argument to a message to be the result of another message send as shown in the second last example ‘widget moveTo:’.
The example ‘100 * 1.5’ is evaluated just like the other message sends, with ‘100’ being a number object and the receiver of the message ‘*’. A message like ‘*’ is called a binary message and they take one argument which in this case is the number object ‘1.5’. Again, it is possible for the argument to a message to be result of another message send, so we could have ‘100 * 1.5 + 2’, where ‘*’ and ‘+’ are both binary messages.
You now know all the Smalltalk syntax you need to move forward. Of course there are some other things to know in order to define the methods that are invoked in response to messages but these too are created by sending messages to objects. The compiler and environment add a few short-cuts to aid in the expressing of message sends but under the covers they send messages to objects as well. That’s the beauty of the Smalltalk principle of message passing when uniformly applied.
For Redline to send messages to objects we need a way of breaking up input into chunks we can understand and determining which of those chunks represent a receiver, a message and any possible optional arguments, which themselves may be a message send. To accomplish this in a small step we will implement just enough of the Smalltalk language to recognise a message send without any arguments which is called a “Unary Message”. An example of a Unary Message is ‘Object new’ where the receiver (‘Object class’) is sent the message ‘new’. What we will do is:
The following is the initial grammar (in ANTLR format) that we have in place to break up the Smalltalk source into understandable chunks, keeping in mind that we have kept just enough of the full grammar to understand Unary Messages and we will be adding to this grammar with each ‘small talks’ installment. The grammar itself was deduced from the last few pages of the ‘Blue Book’ which provides a ‘railroad‘ diagram of the Smalltalk Grammar and from my previous work on implementing Smalltalk. Using the grammar and the ANTLR plug-in you can see a ‘railroad’ view.
| program returns [Program n] : sequence EOF {$n = new Program($sequence.n);} ; sequence returns [Sequence n] : statements {$n = new Sequence($statements.n);} ; statements returns [Statements n] : statementList ‘.’? {$n = new Statements($statementList.n);} ; statementList returns [StatementList n] : { $n = new StatementList(); } expression {$n.add($expression.n);} ; expression returns [Expression n] : cascade {$n = new Expression($cascade.n);} ; cascade returns [Cascade n] : messageSend {$n = new Cascade($messageSend.n);} ; messageSend returns [MessageSend n] : unaryMessageSend {$n = new MessageSend($unaryMessageSend.n);} ; unaryMessageSend returns [UnaryMessageSend n] : primary {$n = new UnaryMessageSend($primary.n);} (unaryMessage {$n.add($unaryMessage.n);})+ ; unaryMessage returns [UnaryMessage n] : NAME {$n = new UnaryMessage($NAME.text);} ; primary returns [Primary n] : variable {$n = $variable.n;} ; variable returns [Variable n] : NAME {$n = new Variable($NAME.text);} ; |
The top level node that is returned by the parser is Program. The ‘program’ rule represents the top level rule and it returns the Program node which is the root of all the other nodes that make up the tree structure of the parsed Smalltalk program. Right at the bottom of the grammar, when a unary messages is recognized a UnaryMessage node is created to hold information about the unary message and that node is returned up a level to the rule above it. The ‘unaryMessageSend’ rule says that a unary message send can be made up of a primary and one or more unary messages. As each unary message is recognised it is added to the UnaryMessageSend node and when no more unary messages are recognised the UnaryMessageSend node is returned up a level. This process continues until the top level node is reached because we have no more input to parse. The ‘primary’ rule in our initial grammar is used to recognize the receiver of the message sends, and only ‘primary variables’ for now. A graph of this process is shown below for the input “Object new name” (see src/test/smalltalk/Test.st):
The tree of nodes that are returned by the parser contains a representation of the Smalltalk program that was parsed. This tree is then processed using the Interpreter and Analyser classes. The Analyser class along with the node classes implement a Visitor pattern so each node can be processed by the Interpreter. The main classes involved in this processing are described next in ‘The Parts’ section.
When you have checked out and compiled the source for this talk you can run ‘stic’ against the test input ‘src/test/smalltalk/Test.st’ and you should see the following output:
| Object new name |
* Currently for demonstration purposes the nodes ‘variable’ and ‘unaryMessage’ print their values when visited by the analyser and this will be changed in later talks.
The Parts
This section details the main classes used to interpret the source and the role that the class plays.
Analyser: st.redline.smalltalk.interpreter.Analyser
The Analyser class analyses each node in the tree of nodes and gathers information and decides what message sends should be generated in response to the input node. Part 2 of ‘Message in a bottle’ will cover this aspect in more detail.
BasicNode: st.redline.smalltalk.interpreter.BasicNode
The BasicNode class provides a base for parsed nodes with each of its subclasses representing a specific element of Smalltalk. A BasicNode represents a singular element like a String or a Number, while BasicListNode represents an element with one or more associated nodes, like a literal Array. There is a subclass of BasicNode or BasicListNode for each Smalltalk language construct represented in the grammar file.
Smalltalk: st.redline.smalltalk.Smalltalk
To enable Smalltalk to be embedded in your Application or to be used stand alone there is a single entry point to Redline which is the Java Class named Smalltalk (st.redline.smalltalk.Smalltalk), and to use Redline Smalltalk you need to create an instance of this Java class.
Environment: st.redline.smalltalk.Environment
Redline runs in a self contained environment and this environment is passed to the Smalltalk instance when it is created. This environment is referenced whenever the Smalltalk instance requires information like command line arguments or operating system properties. This approach is loosely modeled on Ruby Rack and will allow Redline Smalltalk to be more easily integrated and to be used in situations where user sessions need to be kept separate like in a Web Container.
The Next Step
In the next installment of Redline: Smalltalk in “small talks”’ we will analyse the tree of nodes that represent a Smalltalk program to generate Java Virtual Machine bytecode for each node and execute it, resulting in running Smalltalk programs!
“The Customer is always right” – Haruo Minami
Establishing a feedback loop is important so we need to get something running in Redline Smalltalk a.s.a.p. and by the end of this ‘talk’ you will have a running program called ‘stic’. The Smalltalk Invoke Command (stic) program will invoke the compiler and produce some output so you know all the parts are there and working. Stic will be the primary way we will get feedback with each incremental change, giving us a point of reference for our discussions. You are the Customer and your feedback on each ‘talk’ and the proposed next ‘talk’ is crucial to making this series successful. When you have built and run the ‘stic’ command you should get the following output:
| $ ./stic usage: stic [options] <source files> -?,–help print this message |
* Windows users do not have to enter ‘./’, just ‘stic’
The goal of this ‘small talk’ is to setup the Projects build files and create the ‘stic’ program that we can enhance with each talk. We will know the Project is setup correctly when we can repeatedly and reliably build and test the Project sources, and it would be nice to support building from a popular IDE like IntelliJ or Eclipse.
You can download the sources from github then checkout the tag with ‘git checkout PROJECT_SETUP’.
The following table describes the Project dependencies and how they are used in the Project:
| Tool | Description |
| JDK 5 or higher | Compiles the programs we will write. Source compatibility is set to Java 5. |
| Apache Ant | Controls the build pipeline. Input to Ant is the ‘build.xml’ file. |
| ANTLR | Processes and supports the Smalltalk lexer and parser generated from the ‘smalltalk.g’ grammar file. |
| ANTLRWorks | Plug-in used by IDE for the development and testing of the Smalltalk grammar. |
| JUnit | Provides a unit testing framework. Each increment to the project will be driven and supported using Tests. |
| Apache CLI | Provides parsing of the command line and printing of usage help. |
* Note: Additional dependencies will be identified as needed.
The Project files are folders are organised as follows:
I hope that the project structure is straight forward: source is in a sub-folder of ‘src’, required libraries in the ‘lib’ folder and Project configuration and scripts in the root folder.
While the project isn’t built using the Apache Maven build tool the typical Maven project structure has been used to make it easy for those wanting to adapt it for use with Maven. This ‘Maven’ like approach means we have separated our source (src) into sub-folders related to testing (test) and non-testing (main) and those sub-folders are further separated into language.
Project configuration files are provided in the Project sources for both Eclipse and for IntelliJ and each will be kept up to date with each installment. However, the ANTLRWorks plug-in you need to install manually as it is not automatically installed when loading the Project.
To install the ANTLRWorks plug-in for Intellij you need to go to Settings (ctrl-alt-s or File->Settings menu) and then to the plug-in manager (click plug-ins). Then click the ‘Available’ tab and in the Search field enter ‘ANTLRWorks’. The plug-in should be listed and you can right-click on it and select ‘Download and install’. You may need to restart IntelliJ. To see what ANTLRWorks can do I recommend watching the ANTLR series by Scott Stanchfield. We will refer to this series later when developing the Smalltalk grammar.
To install the ANTLRWorks plug-in for Eclipse requires several detailed steps and it is best to watch the first installment of the ANTLR series by Scott Stanchfield. We will refer to this series later when developing the Smalltalk grammar.
The Project build process is controlled by Apache Ant and the ‘build.xml’ file to provide the following build targets:
| Target | Description |
| build | Generate, Compile and Test sources. |
| clean | Clean-up artifacts. |
| compile | Compile sources. |
| generate | Generate sources from grammar. |
| jar | Create Java Archive. |
| package | Package Redline Smalltalk for use. This is the default target and running ‘ant’ without any arguments runs this target. |
| test | Runs all levels of tests against the code base. |
| unit-test | Runs the Unit-Tests against the code base |
* running ant with only ‘-p’ will list the build targets.
The favoured approach for building the project is from the command line because this represents a more controlled and consistent environment than building via an IDE. The command line approach is easily integrated with Continuous Integration tools like Hudson. To build the project you need to have Apache Ant installed and on your path. Once this is done you can build the project by running ‘ant’ without any arguments. Here is a transcript of my run:
| $ ant Buildfile: build.xml clean: [delete] Deleting directory /home/jladd/dev/redline-smalltalk/out [delete] Deleting directory /home/jladd/dev/redline-smalltalk/src/main/generated init: [mkdir] Created dir: /home/jladd/dev/redline-smalltalk/out generate: compile: [javac] Compiling 2 source files to /home/jladd/dev/redline-smalltalk/out [javac] Compiling 2 source files to /home/jladd/dev/redline-smalltalk/out [javac] Compiling 3 source files to /home/jladd/dev/redline-smalltalk/out unit-test: [mkdir] Created dir: /home/jladd/dev/redline-smalltalk/out/test-results [junit] Running st.redline.smalltalk.SticTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.054 sec test: build: jar: [jar] Building jar: /home/jladd/dev/redline-smalltalk/out/redline-smalltalk.jar package: BUILD SUCCESSFUL Total time: 1 second |
* blank lines removed
When you run the build, the grammar file (src/main/grammar/smalltalk.g) is processed by the ANTLR tool and two source files are generated from it: ‘SmalltalkLexer.java’ and ‘SmalltalkParser.java’ (src/main/generated). These two files provide the ability to process Smalltalk source files into a tree of nodes. However, we do not currently invoke these generated files but we will in the next installment of ‘small talks’.
After compilation succeeds the test suite is run – if any tests fail, the build will also fail. When the tests have passed the compiled Java files (.class) are bundled into an archive (out/redline-smalltalk.jar); jar files are are easier to use and distribute than separate files.
On successful completion of the build the command line tool ‘stic’ can be used. The ‘stic’ command invokes the Java Virtual Machine asking it to execute the Stic Class (st.redline.smalltalk.Stic) passing it any command line arguments.
Hopefully your building of the Project is without error and you can run ‘stic’ which we will use extensively from now on. Should you have problems with the build then be sure to comment in the blog, or raise an issue in github.
In the next installment of Redline: Smalltalk in “small talks”’ we get into Smalltalk, its grammar and parse a Smalltalk source file by calling the SmalltalkLexer and SmalltalkParser generated with the ANTLR tools. This will involve adding to the Smalltalk.g grammar file and working with the ANTLRWorks plug-in in the IDE. We will also put the first stone in place of our supporting Runtime.
Redline Smalltalk is an implementation of the Smalltalk programming language for the Java Virtual Machine, and you are invited to follow along and participate in Redline’s implementation, or implement your own Smalltalk or another language. It is hoped that the techniques used and the process of language implementation are of interest to readers even if Smalltalk is not your primary programming language.
The topics of Compiler Construction (lexing and parsing), Bytecode manipulation, Test Driven Development (TDD), Behavior Driven Design (BDD), Object Oriented Design (OOD) and the building and running an Open Source Software (OSS) project will be covered with real working examples.
Getting feedback from working code is the paramount goal of these “small talks” so you will have something working in just a few talks. Your feedback and participation is welcomed and you can comment on each “talk” via the Redline Blog or anytime using the email address object at redline.st
The “small talks” will start from “scratch” and build out a Smalltalk until it can run a reasonable Web Application hosted on a suitable JVM based Web Container like Jetty or Tomcat. Although building from “scratch”, the risk that this project will not succeed is very small as the building of Redline Smalltalk has been happening for some time and all the hard to implement features have been done, like Smalltalk blocks with special “return” semantics.
The series of “small talks” on implementing Redline Smalltalk was inspired by the work “Scheme from scratch” by Peter Michaux.
To quote Peter Michaux, “This exploration is not for novice programmers. It is a tutorial introduction for novice language implementers and enthusiasts from the perspective of a novice language implementer and enthusiast”. As a novice language implementer I will do my best to explain topics before we tackle them, to provide references to additional information and to keep the level of detail high enough that those without a deep understanding (me) of compilers and virtual machines can follow along.
You have some experience developing Java Applications using JUnit, Mokito, Ant, Git, Eclipse or IntelliJ. You know a little bit about Compiler Construction and the Antlr tools. Smalltalk knowledge is not essential as each part of the language will be described as it is implemented, however, it will be handy to have a copy of Smalltalk-80 The Language and its Implementation by Adele Goldberg, David Robson, and Michael A. Harrison (‘The Blue Book’) and have Pharo Smalltalk installed on your machine. What to install and when to install it will be covered in greater detail in future “talks”.
Redline Smalltalk is targeting the Java Virtual Machine as it is the predominant Virtual Machine used to run Applications and there is a wealth of Java Libraries that can be used by a Smalltalk to implement sophisticated concurrent Applications. You will be able to call Smalltalk from Java and Java from Smalltalk. The bytecode generation layer will be decoupled so another generator for another target could be “plugged” in if the JVM isn’t for you.
Redline Smalltalk is released under the MIT License. See the LICENSE file in the source bundle.
