Planet Smalltalk

September 30, 2015

Marten Feldtmann - PUM, Gemstone and VASmalltalk as a REST client

PUM (now somewhere with a version around 08.06.01-02.06.27) is able to create a VASmalltalk client source code to create classes needed in the API definitions. It creates the API calls and all the needed Abt* methods on the class side … now the time of testing and simple client writing starts in VA.

Filed under: Smalltalk Tagged: Gemstone, PUM, REST client, Smalltalk

Marten Feldtmann - VASmalltalk, HTTPClient and cookies …

While writing a RESTClient Runtime for VASmalltalk for my Gemstone system I needed to write a HTTPClient able to handle my cookie send from Gemstone. How is it done ?

Create a subclass from SstHttpClient and add an instance variable (e.g. sessionCookie) to hold the cookie returned from the server.

Now overwrite the following method to set the cookie when sending the request:

buildHttpPOSTFor: aUrl using: basicAuthCredential
req := self templateHttpPOSTMessage copy.
basicAuthCredential isNil
ifFalse: [req header authorization: basicAuthCredential].
req header
url: (self requestUriForUrl: aUrl);
host: aUrl hostport.

sessionCookie notNil ifTrue:[ req header cookie: sessionCookie ].

And in the case of a POST call I changed my calling method to the following stuff to catch the value of the cookie delivered by the server:

callAPI: urlString method: httpMethodName parameter: parameter resultModel: resultClass
| response tempURL parameterAsJSONString responseAsString cookie |

tempURL := self baseURL copy.
tempURL path: urlString.
parameterAsJSONString := parameter isNil ifTrue:[ nil ] ifFalse:[ NeoJSONWriter toString: parameter ].
response := self post: parameterAsJSONString typed: 'application/json' at: tempURL.
(cookie := response header setCookie) isNil ifFalse:[ sessionCookie := cookie ].

Filed under: Smalltalk Tagged: Cookies, Smalltalk

Marten Feldtmann - Smalltalk User Meeting in Hamburg cancelled …

… and Meetup group just before closing …

Filed under: Smalltalk Tagged: Meetup, Smalltalk

Torsten Bergmann - Grafeo for Pharo 5

Grafeo is a nice Morphic graph editing toolkit by Eiichiro Ito. It forms the basis for Fluo (Video here). It was updated to Pharo 5.

Torsten Bergmann - Pi Podcast

with Tim Rowledge, known from Squeak Smalltalk VM/development for Scratch.

Torsten Bergmann - Pharo 5 Reflectivity

Torsten Bergmann - Setup Cuis with Git

Torsten Bergmann - Smalltalk on Code.talks 2015

There is a presentation of a Smalltalk project from Christian Haider (Smalltalked Visuals GmbH) at Code.talks 2015 in Hamburg today. You may know him from his SmallCharts project and the PDF4Smalltalk open source PDF library for Smalltalk.

September 29, 2015

Torsten Bergmann - Kendrick Book

There is more documentation for Kendrick (which is built on top of Pharo) - the Kendrick book. Nice!

Torsten Bergmann - Explora in Pharo

Explora is a visualisation tool for the analysis of multiple metrics of software corpora. It includes the PolyGrid, a novel visualisation technique that encourages users to detect patterns among metrics. Done in Pharo Smalltalk.

The project is on STHub, either on:!/~merino/Explora or!/~merino/Explora2

Torsten Bergmann - Bee Smalltalk

The prerelease of Bee Smalltalk from 2014 is still not accessible on GitHub as it was stated in the announcement. So I thought the project is dead. But now a new blog post appeared. Looks like there is still activity. Looking forward in trying out.

Pharo News - Pharo Touch Demo

<p>Pharo touch demo with the new OSWindows architecture, touch events, vector graphics using Athens and libsdl2.</p> <p><figure><img src="/files/posts/pharotouch.jpg"></img><figcaption></figcaption></figure></p> <p>Video on youtube: <a href=""></a></p>

Pharo News - Pharo Touch Demo

<p>Pharo touch demo with the new OSWindows architecture, touch events, vector graphics using Athens and libsdl2.</p> <p><figure><img src="/files/posts/pharotouch.jpg"></img><figcaption></figcaption></figure></p> <p>Video on youtube: <a href=""></a></p>

September 28, 2015

Bee SmaRT - Blogging back

Wow, one blink of an eye and around a year passes! It's been a long time since the last post... you'll have to excuse me, but I find it very hard to make a pause to write here when at the same time I'm facing amazing problems such as the ones Bee poses. I'll try writing here more frequently, I hope I'll have the needed will power to keep doing the exercise.

Anyway, in case you were wondering, yes! there's been a whole lot of work done since last year and I'm going show some of the advances in the Smalltalks, which happens to be hosted in Buenos Aires this year. For a while I've been rounding corners of the self-hosted system, implementing missing primitives, working in the debugger, user interface, garbage collection and more. The next posts will describe some of that work, hope to see you soon!

Torsten Bergmann - Live Robot programming with Pharo

Torsten Bergmann - Pharo Touch Demo

September 27, 2015

Torsten Bergmann - Ephemeric Cloud to a MongoDB hosted at Digital Ocean

Crossconnecting the web with Pharo. Read more.

Pharo Weekly - Multiple Desktops for Pharo

Julien Delplanque provided this week a goodie to switch between 
"desktops" - but his initial solution was more or less hiding windows
and not really switching between real Pharo worlds/desktops.

I gave him some tips what could be done on the pharo-user list. Havent heard
from him afterwards.

Now I was able to spend a few hours on this topic myself and implemented 
a full multiple desktop solution myself.

This works in Pharo 5 only (currently) and requires latest VM (at least on Windows)
from to get the keyboard shortcuts right.

To try:

  Gofer new
    smalltalkhubUser: 'TorstenBergmann' project: 'DesktopManager';

The goodie has some nice features like keyboard navigation, world menu
integration and even a custom spotter with preview of the desktops.

Quick start:
 - evaluate the above expression in a Pharo 5 image
 - check the world menu "Desktop"
 - you can press CTRL + D and then CTRL + A (= Desktop Add) to add a new desktop 
 - you can press CTRL + D and then CTRL + D (= Desktop Desktop) to open the overview
 - you can press CTRL + D and then CTRL + P (= Desktop Previous) to navigate to the previous desktop
 - you can press CTRL + D and then CTRL + N (= Desktop Next) to navigate to the next desktop

The code is hopefully a good example on how to build a custom spotter, shortcuts, inspector extensions, ...
Additionally all this is described in a new article including screenshots
and a guide on how to use this new goodie:

Actually the article took more time to write than coding but I hope 
it helps explaining Pharo and why it is a power tool. 

Project is on!/~TorstenBergmann/DesktopManager
Article and code is still subject to change.

Have fun

September 26, 2015

Pharo Weekly - Ephemeric Cloud to a MongoDB hosted at Digital Ocean


Good news everyone! :)

Today I have successfully connected an application published in
Ephemeric Cloud to a MongoDB hosted at Digital Ocean!

It became possible due to a stunnel support implemented in Ephemeric
Cloud runtime – the utility allows to create secure tunnels between
applications. Thus the communication between an ephemeric instance and
a droplet is encrypted and safe. Configuration is extremely simple –
just put a stunnel.conf and the certificate files to your Image
archive before publishing it.

This approach is universal and it allows to connect Pharo Images to
any service providers or dedicated servers. Therefore Ephemeric cloud
becomes more than just Pharocloud but an universal tool to develop and
publish Pharo web applications. Another good thing is that it has a
free tier :)

Please try it out and tell me what you think.

You can find some documentation here:


Pierce Ng - WaterMint-HTML

I’m putting together a small library for generating HTML programmatically a la Seaside, called WaterMint. Here’s an example:

| html |
html := WMHtmlCanvas new.
html html with: [ 
    html head with: [ html title: 'WaterMint' ].
    html body with: [ 
        html h1: 'WATERMINT'.
        html div id: 'foo'; class: 'foo'; with: [ html p: 'Foo!' ].
        html div id: 'bar'; with: [ html p: 'Bar!' ].
        html h1: 'BAZ!' ]].
 html render.

The output:

<div class="foo" id="foo"><p>Foo!</p></div><div id="bar">

Code is on SmalltalkHub. It is far from complete, of course. I have not written any example to render forms and the library has as yet no facility to deal with Javascript.

September 25, 2015

Torsten Bergmann - Keyboard control for a Smalltalk IDE, part 2

Torsten Bergmann - L Peter Deutsch and Allan Schiffman

In the 1984 POPL conference there appeared a paper, Efficient Implementation of the Smalltalk-80 System, by L Peter Deutsch and Allan Schiffman. This paper introduced the first truly modern just-in-time compiler and described several novel implementation techniques, still in widespread use, to improve the performance of object-oriented languages.

September 24, 2015

Göran Krampe - Adding objects to Ni!

So... Ni has almost reached the point where I can see objects appearing. The following describes the design I currently have in mind, read it and tell me what you think so I can scrap it and start over ;)

Introducing Dictionary

Before we get to objects, we need something else - a Dictionary. A Dictionary is just a key/value collection - the name comes from Smalltalk, in many other languages they are called Map or HashTable and in Nim it's called a Table. Rebol uses the word "Context", and that is the word I have used so far in the Ni sources and articles. But nah, sorry Rebol, calling it a Dictionary makes it easier to understand IMHO.

Dictionaries and Blocks are the two primary plain data structures in Ni. Other more specialized collections would be constructed as objects (just like in Smalltalk) or added as a Ni extension. In this sense Ni is a bit like Javascript. It's not purely OO as Smalltalk is, where both these are represented as objects. But IMHO as long as that fact doesn't cause "gotchas" it's fine.

As many languages before Ni has shown - having language syntax support for Dictionaries can be very useful.

I earlier hinted on using curly braces { ... } for this, and I still think that's more useful than using them as a second asymmetrical (thus nestable) string delimiter, as Rebol does. Also, we generally like to follow Nim when it comes to details like this.

I kept brooding over this, what would be the best way to make it very readable and still fit in with The Way of the Ni Knights? First I was trying to mimic Javascript but it felt clumsy, then one morning it dawned upon me that the cleanest solution is the most obvious solution. And what is that then?

Well, how about if we combine the characteristics of a Paren (has no Dictionary of bindings, and evaluates containing code, when evaluated, to a single result) and a Block (gets its own activation record when evaluated and thus has a Dictionary of bindings, but does not evaluate its code when evaluated, only when explicitly done so via do).

And yes... I should have read more Rebol - because creating objects in Rebol works quite similarly :)

A Dictionary could then be created like this:

nimrod { a = 2 b = 3 }

And it would evaluate immediately as a Paren does, but it would also (upon evaluation) create an activation record with a Dictionary, like a Block does. And when the evaluation is done, it would return that Dictionary as its value! It's darn beautiful if you ask me. There is no need for special syntax inside the Curly, it's just arbitrary Ni code like in a Block! Muuaahhahaa! Yeah, yeah, all you Rebolers think this is old stuff of course. ;)

So the above could also be done more explicitly using a block like this:

nimrod do [ a = 2 b = 3 bindings ] We need to use do to run the block since blocks do not evaluate by themselves, and the block ends with bindings which would return the local Dictionary of the activation record.

A larger example:

``` nimrod myDict = {

age = 46
interests = [programming boats badminton]
name = "Göran"
echo ("Just created " & name)      # Remember, this is just code!

} echo (myDict at: 'name) echo (myDict at: 'interests) ```

Tada! So now we have Dictionaries.

Punting on Modules

In Ni, lookups are done lexically "outwards" until we reach the root Context. The root Context is our global namespace. Modules is in many languages a hot topic. Ni tries to learn its ways before introducing a Module system, but it most likely will be something derived from Dictionary, or nothing at all :)

Introducing Object

A Dictionary is just a "plain datatype" or in other words, we can't associate "methods" with it. We can define infix functions usable on Dictionaries of course, and at: is an example of that, but there is no polymorphic dispatch going on on the Ni level (but inside the interpreter we use Nim methods to gain polymorphism for builtin datatypes).

Let's first suppose that an Object in Ni is in essence a Dictionary but a bit different. It feels natural that an object can be modelled as a Dictionary to hold the "instance variables". Just like we create Funcs from Blocks we could then create Objects from Dictionaries using an object word:

``` nimrod rectangle = object {

x = 0
y = 0
width = 0
height = 0

} ``` This is an object that is quite silly, because it has no behavior. The idea of objects holding their own instance based behavior may look neat in theory but is pretty useless in practice I think. Most prototype based languages seem to evolve some kind of class mechanism to have shared sets of behaviors that we can reason about. Ni thus punts on any "instance based" lookup for behaviors, instead I am focusing on a mixin-style ordered lookup by making the object have a block of Traits:

``` nimrod rect = object {

traits = [Positionable Rectangle]
x = 0
y = 0
width = 0
height = 0

} `` So in summary, we introduce an **Object** that we create using theobjectword that takes a **Dictionary** as input. This is an instance, not a class. The Dictionary can hold a special keytraits` which has a block of Traits in order. A Trait is the closest we get to a class in Ni, but it defines no structure and it also doesn't inherit from other Traits, it's just a Dictionary of named Funcs really.

So a more complete example could look like:

``` nimrod

A set of behaviors for a Point that has an x and y

We use capital letter for Traits. The trait word takes

a Context and creates a Trait for us.

Point = trait { x = func [.x] # A getter, note the .-scoping y = func [.y] x:y: = func [:.x :.y] # A setter, note the .-scoping moveX:y: = func [self moveX: :dx self moveY: :dy] # Self calls moveX: = func [.x = .x + :dx] moveY: = func [.y = .y + :dy] }

One more Trait, a set of behaviors for a Rectangle with width and height

Rectangle = trait { area = func [.width * .height] extent: = func [:extent .width = extent x .height = extent y] }

An object which uses a single Trait

origo = object { traits = [Point] x = 0 y = 0 }

An object which uses two Traits, lookup is in order so conflicts are just shadowed

If you wish to resolve conflicts you create yet another Trait and put it first patching it up

rect = object {

traits = [Point Rectangle]

x = 0 y = 0 width = 0 height = 0 }

Creating new objects is easily done copying an existing object

rect2 = copy rect

And you can always make funcs taking arguments returning new objects

just like you typically do in Nim instead of constructors.

newRectangle = func [ :x :y :w :h

object {
    traits = [Point Rectangle]
    x = ..x # This will refer to the x argument in the func
    y = ..y
    width = ..w
    height = ..h

} ]

And then we can easily call it, this time using Rebol

style argument passing instead of a Smalltalk style keyword

message. As one sees fit.

rect3 = newRectangle 100 100 640 400

Polymorphic dispatch, both objects respond to the getter x

[rect origo] do: [echo :each x] ```

There are many details here one can discuss, but some thoughts:

  • I find the above object model to feel less "confusing" than a delegation model, still need to bang on it for real though.
  • I avoid instance specific behaviors since I doubt they are useful.
  • A Trait is also created from a Dictionary. Purely a set of behaviors, clean, simple.
  • I reserve the key traits for the slot in the object holding the Block of Traits. Fine! :)
  • Lookup is by order, thus conflicts are ok, the Trait coming first simply wins.
  • Inheritance and composition can be done in many ways here using copying of prototypes and manipulating the traits block
  • Not inheriting structure doesn't feel like a great loss, and actually, since an Object is basically a Context - inheritance of structure can also be done via a simple initialize pattern letting the Traits in order initialize their variables.
  • Ability to call "super" etc, well, it can also be added, although I am curious if one can avoid classic OO design where it easily becomes something you want to do.

I am really interested what kind of feedback I can get on this, a lot of other developers/language designers out there are much more educated than I am!

Object dispatch

But how is the dispatch done?

I think I will try making Object nodes affect the lookup of the word coming right after. This means methods are strictly called with the receiver object on the left.

  1. When Ni first encounters rect it will notice it's an Object, remember that, and continue to the next node.
  2. Before the regular lookup of the next word, we first need to let rect look it up among its traits. If we find a func we call it with self bound to rect, thus methods like this overrides any available infix func we could have found.
  3. If we didn't find anything, we continue normal lookup of the word since it may be a regular non polymorphic infix function.

Now we have the first seed of an Object model! Will it work? Haven't got a clue. Time to hack it. But... it does look doable and I think I like it.

Torsten Bergmann - Ecstatic

Ecstatic - a static website generator for Pharo based on Pillar.

September 23, 2015

Torsten Bergmann - Validating Metric Thresholds with Developers: An Early Result

This paper reports the first results of an empirical study aimed at validating relative metric thresholds with developers. The study was conducted on 79 Pharo applications and using four source code metrics

Noury Bouraqadi - Open Position for a PhD Student on Hot Software Update in Robotic Applications

CONTACT Prof. S. Ducasse, stephane.ducasse AT, INRIA, France Prof. N. Bouraqadi, noury.bouraqadi AT, Mines Douai, France Dr. M. Denker, marcus.denker AT, INRIA, France Dr. L. Fabresse, luc.fabresse AT, Mines Douai, France CONTEXT Building next generation systems that can not be stopped is an interesting challenge for industry. Indded, when we need… Continue reading

September 22, 2015

Göran Krampe - Ni design decisions!

So... my little Ni language got some attention since it was first on Hackernews, then TheRegister, all over Twitter and also Reddit.

But I think it managed to come relatively unscathed out of it, although it REALLY is pre-alpha-not-even-complete-eats-your-harddrive early and you know, I really have no idea if it ever will go the distance since it takes quite a bit of work to get a language to actually be used. But I am going to stick with it.

Anyway, I have been experimenting with "arg words" and "lookup scoping" while thinking about how to add objects, and a few other things. This article doesn't introduce how I want to do objects, but the next one does (I split it in two). This article however covers a bunch of loose ends and my ideas on how to tackle them in Ni. And I will try to make this understandable even if you don't know Ni. ;)

Argwords design mistake

Argwords (Ni's mechanism for accessing arguments inside a function) as they stand today are neat but suffer from an embarrassing "design mistake". Simple blocks work fine, for example like these, similar to Smalltalk:

  • [:a :b a + b]
  • [:a > :b]

The first one seems "just like Smalltalk". It looks like the arguments are declared at the beginning, but note that there is no separator between those "declarations" and the rest of the code like Smalltalk has (the |). This is because an argword in Ni is an operation, not a declaration. So :a means "pull in the next argument from the callsite (evaluating it first), store the value in local variable a" and the value of :a is the argument pulled in.

This means the second example works fine, since the value of :a is whatever we pulled in, and since the argwords can come anywhere in the block, we can call the <-word immediately like that.

So what is the mistake?

Well, let's say we do something like [ifelse (:a > 0) [a + :b] [0]]. It says "pull in a and if it's bigger than zero, pull in b and add them together and return that, otherwise don't pull in a second argument and just return 0". One can definitely question the usefulness of such dynamic arity :) but anyway, let's see what nirepl says:

```nimrod gokr@yoda:~/nim/ni$ nirepl We are the knights who say... Ni! Enter shrubbery... eh, code and an empty line will evaluate previous lines, so hit enter twice. do [ifelse (:a > 0) [a + :b] [0]] 1 2

Oops, sorry about that: Can not evaluate 1 + [0] ```

Hehe, what? Ahh... so :b tries to pull in the next argument at the call site, but this is a nested block so it doesn't try to pull in 2 but instead tries to pull in "whatever comes next in the block where this block is defined". And that happens to be the else-block of ifelse... ooops. And yeah, Ni doesn't have any proper error model yet, any ideas on that is appreciated.

So the current design issue means... argwords in nested blocks will not work as expected - since we use blocks for control structures! It means that you would need to rewrite this example as [if (:a <= 0) [0] a + :b] which would work fine, since now :b is not in a nested block.

I don't have a good idea on how to make this work when nested, perhaps I will let this one just be a "language-gotcha" for now.

Scoped lookup

One thing I am experimenting with in Ni, which doesn't exist in either Rebol (I think) or Smalltalk, is different variants of lookups for words.

Currently, regular word lookup starts by looking in the local scope, then in the outer lexical scope and outwards out to the root activation of the interpreter (global scope). This is the default lookup which means you have shadowing on all levels. But then one can already use two different prefixes to change that behavior:

  • ..banana - similar to filepaths this means only look in nearest outer lexical scope
  • .banana - similar to filepaths this means only look in local scope

The idea is to use this both for access and left side in an assignment. BUT... I am having regrets, I think I will change it to:

  • banana - start in local and go all the way out for access. Assignment however is local only.
  • .banana - only access and assign in "self" which typically will be bound to an object or module. This is instance variable access.
  • ..banana - start in the "outer" scope and go all the way out. Both for access and assignment.

So the default scoping, x without a prefix, will work fine for local variables, arguments and other things outside in the outer scopes. When assigning it will however always be in the local scope.

For instance variables in objects you will have to use .x, both for access and assignment. So those are explicitly different from all other variables, which I think is good in a language like Ni where we do not declare any variables. See upcoming article for more on Objects.

NOTE: Since do not declare the names of variables - typos can only be discovered via heuristics, like "never assigned to nor an argument in this function" or "assigned to but never used" etc.

Finally using ..x we are basically depending on an external environment to define x for us. It's kinda like "I wish for an x" and we presume someone will make sure it's out there somewhere. Exactly what "outer" scope means may be different depending on context. In a Func, it's just in the defining outer scope.

Introducing undef

One other thing. I am considering introducing undef in addition to nil. Smalltalk suffers from its fair share of DNUs (doesNotUnderstand exception) due to variables being nil, most often not having been initialized to a proper value. But quite often in Smalltalk nil is also used as a proper value meaning "no value", in that case it doesn't mean "not set". Thus separating undef from nil seems like a useful idea.

So if a word evaluates to nil there is at least a binding for it, but it has nil as its value. If a word evaluates to undef there was no binding found at all. I would like a short and punchy name though, undef is quite boring. Perhaps eki? :)

Exclamation point and question mark

In Rebol question marks are used as the last character of words to functions that evaluate to a boolean. Ruby does something similar I think and it's a good thing, so Ni adopts that. There is however nothing special about the ?-character, it's just a convention.

The exclamation point is used in Rebol as a marker of a datatype word. Rebol has lots of datatypes and likes to easily test values if they are of a certain datatype. One can also add type declarations of arguments to functions, although they are checked only at runtime. Ni is more Smalltalk-like and it seems to me that relying on polymorphism is more sound. Smalltalk code very seldom tests like that, and if it's done we typically frown upon it. This makes the ! free for some other use or convention, ideas welcome.

The word consisting solely of ? could be used to test if a word is defined, so banana ? would be the same as banana != undef.

Indexing and refinements

Also, two other issues that I really haven't given proper thought:

  • Indexing. In Nim you do x[1] and x[1] = 2 but in Smalltalk you use messages instead like x at: 1 or x at: 1 put: 2.
  • Rebol refinements. In Rebol this can also double for indexing so the above would be x/1 and x/1 = 2. Otherwise Rebol uses words for indexing similar to Smalltalk.

For the moment I consider going the Smalltalk route for indexing, since that works already and even though it's "longer to type" it works fine in Smalltalk. It also honours encapsulation.

Refinements in Rebol are kinda slick. They are used in two different ways - either as "indexing" or "member access", or as a way to pass "flags" or optional arguments to functions. Smalltalk works without explicit member access from the outside, you need a setter or getter and that seems fine to me and ensures encapsulation. I also think foo/bar looks kinda odd to read for member access or indexing.

The flags to functions and optional arguments seems useful though and can be likened with the --opt that Unix uses. The obvious advantage is that they are boolean in nature, so shorter to write /short instead of short: true and they can also appear in any order and they are optional.

Smalltalk does not have anything resembling this, there you often end up with a fairly clumsy approach with many similar keyword messages with various subsets of keywords, each calling the complete one with all keywords, supplying default values for those missing.

I am more of a Linux than a Windows guy, and I don't really like the "path" usage of refinements in Rebol. One idea is then to introduce a new kind of word: an option word. They would start with - (and be more than 1 character long so we can still have - for "minus") and they would evaluate to themselves. The magic would however be in the mechanism of argwords, when an argword is evaluated, and it instead pulls in an option-word, it would:

  1. Gobble it up and create a local binding for the option word to true
  2. Continue pulling to get a "real" argument

This means option words must come before an argument, otherwise they will not be pulled in.


nimrod plus = funci [:a :b if hhgttg ? [return 42] # hhgttg is available as a local word if negated ? [return ((a + b) ..negated)] # Note how we need to use ..negated in order to avoid the local shadow return a + b] 1 plus -hhgttg 3 # When plus is pulling b it will also pull in -hhgttg 1 plus 3 1 plus -negated 3

One can also imagine optional arguments (where the value is something else than true) like Rebol has by simply using a ::

```nimrod concat = funci [:a :b if separator ? [return a & separator & b] return a & b ] "bar" concat "foo" "bar" concat -separator: ", " "foo"


Now we quickly realize that infix functions taking only one regular argument will have issues with passing optional arguments... Options work, but not optional arguments since they would be pulled in "backwards". And another thing, if you haven't yet pulled all arguments you are not sure if you have pulled all options... In other words, if your function offers options, it should probably start by pulling in all arg words like concat does above.

Ok, let's chalk these oddities up as "language warts" for now. :)


A number of words could be used to access and manipulate the internal machinery of Ni, like the activation stack and the current scope. Smalltalk has superb power by reifying the stack and making it available via the pseudo variable thisContext so doing something similar seems obvious.

  • self - the nearest outer Object. This is mainly used for calling methods on self and passing self as argument, since state is accessed via .-scoping. There is no super concept.
  • context - the nearest Context which can be the Context inside a function. It enables reflection on what locals are defined etc.
  • activation - the current activation record. This would be the same as thisContext in Smalltalk (since Smalltalk calls them "contexts").

I will start with these I think.

Until next time, happy coding

Torsten Bergmann - Eliots Spur talk on SPLASH 2015

Eliot Miranda is invited to give a talk at SPLASH 2015 in Pittsburgh. He's going to talk about Spur, his latest Smalltalk memory manager, and exaptation in software design, since Spur exapts a couple of key architectural features of fast Smalltalk VMs to provide efficient support for schema evolution and hence live programming.

Fri 23 - Fri 30 October 2015 Pittsburgh, Pennsylvania, United States

Torsten Bergmann - Keyboard controlled code editor

September 21, 2015

Göran Krampe - Guts of Ni

This article describes some core parts of the current implementation of the Ni language. It's not a tutorial, introduction or manual. It's in fact kinda incoherent - but so is Ni :)

The parser

The Ni parser is a straight forward hand made recursive descent parser. Hmmm, now that I look closer I realize it's not recursive. Its just a very simple while loop character by character and maintaining some state. It should be easy to read and understand and given that the grammar is so simple, it hasn't changed much lately. It could probably be made faster by using more procs and less methods, but it's probably plenty fast since the grammar is so simple.

The parser constructs an AST consisting of instances of subclasses of Node. A Node is a regular ref object which is Nim terminology for a GC controlled object allocated on the heap. Its worth noting that the parser can be used alone without the interpreter, but the ni module (the interpreter) obviously depends on the parser module.

Nodes, Nodes...

In Ni everything is a Node, but they come in different families:

  • Values - fundamental "things" typically represented internally by the corresponding Nim type
  • Words - the bread and butter of Ni, kinda like Smalltalk Symbols but have different prefixes making them behave differently
  • Composites - the three base collections of Ni: Blocks, Contexts (Context not implemented yet) and Parens.
  • Derived composites - these are created from a Composite, like a Func or an Object (Object not implemented yet).

Values in Ni are not Ni objects (although they are indeed Nim objects) like in Smalltalk. They can instead be viewed as fundamental datatypes, but the Ni interpreter is designed so that you can add more of these in separate extension modules.

Words are pervasive in the language, just like messages are pervasive in Smalltalk. They are kinda like variables in other languages, but using different prefixes the word behaves differently.

Composites are fundamental collections and they are supported by specific literal syntax in the parser, [], {}, ().

Finally, derived Composites are things one can create using a Composite as input. A Func is a function and it's created from a Block. Objects are yet to be implemented.


All atomic values are wrapped using one subclass of Node for each kind, and currently we have: int, float, string, bool and nil. The values true, false and nil are represented with three singleton Values that are held by the interpreter. Those three singletons are bound to the words true, false and nil in the root context, which is the global namespace.

New kinds of values can relatively easily be added to Ni since I intentionally made the parser be pluggable for this. However I do not like the abundance of builtin types that Rebol/Red has, it feels like a mistake to hardwire so much into the language itself. But this way we are free to experiment with such extension modules.


Ni uses the term "word" much like Rebol does. There are however quite a few differences in what kinds of words Ni supports. A word is just a string, but it's wrapped in a Word node and there are a number of different subclasses of Word which behaves differently and use different prefixes.

  • EvalWord: The most common kind of word, no prefix. All eval words delegates evaluation to whatever it is bound to. In this way they act much like variables do in most other languages.
  • LitWord: A literal word. Uses the '-prefix and is used when one wants to refer to the word as a value itself. Evaluates to itself.
  • GetWord: Uses the ̂^-prefix. The get words do not delegate evaluation, instead they skip evaluation and "evaluate" to whatever it is bound to.
  • EvalArgWord: Used to "pull in" arguments to Funcs, uses :-prefix. Evaluates the argument in the callsite context and pulls in the result, this is like "normal" argument passing in most languages.
  • GetArgWord: Uses the :^-prefix and evaluates to the argument itself, the AST node. No evaluation of the node is made. This enables Ni functions to manipulate the AST.

All words (well, currently only EvalWords and GetWords, but I should make it work for ArgWords and LitWords too) can also, just before the word itself, be additionally prefixed with . or ... This affects lookup and is similar to how one refers to the current or parent directory in Unix. The rules I have in mind currently goes like this:

  • ..x: assignment and lookup is in the nearest outer lexical environment only.
  • .x: assignment and lookup is in the local context only.
  • x: assignment and lookup is in the local context, but lookup continues outward to the surrounding lexical environment and beyond.

I have been mulling these rules over, but I think this logic would make it fairly reasonable. Any feedback appreciated!

Comparing with Rebol. As far as I know the . and ..-prefixes does not have a counterpart in Rebol. Rebol has get words and eval words, but uses :-prefix instead of ^-prefix for get words. The reason Ni deviates is to use : for arg words instead, mimicking Smalltalk block syntax. Rebol does not have arg words at all, but Rebol does have set words which Ni does not have (again to support keywords). Ni instead implements assignment as a primitive infix function.

I also experimented earlier with bindings etc, but currently Ni doesn't work like that. Exactly how different environments can be used dynamically - is still an open design question. Scoping is however mainly lexical but I can imagine mechanisms to control this, and also reification mechanisms in order to reflect on and manipulate the activation record spaghetti stack.


There are three different composites in Ni, each formed by literal syntax [], () and {} respectively. These are called Blocks, Parens and Contexts.

Block and Paren is a wrapped seq of Nodes, seq being the dynamic array type of Nim. Currently they differ only in behavior since Parens evaluate by evaluating its child nodes one by one and returning the last result. Blocks just evaluate to themselves. To evaluate a Block as code you need to explicity do so using the do word.

Contexts are being implemented. A Context has a Nim Table internally making it the fundament of both objects and "Dictionaries", much like in Javascript.

Objects are being implemented and are fundamentally like Contexts, but with special evaluation behavior.

Relying on Nim

The Ni interpreter tries to be very simple and reuses as much of Nim's machinery as possible:

  • A call in Ni results in a call in Nim. This means Ni maintains no call stack of its own.
  • Ni has no memory model of its own, we use Nim's very capable garbage collected memory model.
  • Ni is a plain interpreter, not a JIT. The emphasis is instead on hackability, portability but also very much mixing with Nim.
  • Ni primitives are Nim procs. It's very easy to bind words to primitive procs in Nim.
  • Dynamic dispatch in Ni (for Values) relies on dynamic dispatch in Nim, methods. Multiple dispatch is also used for number coercions and similar.
  • Nim has very strong macro mechanisms which I hope to eventually use to generate glue code to expose Nim libraries in Ni.

The things described in this article tend to evolved from day to day, but hopefully this better explains a bit about how Ni is constructed!