Planet Smalltalk

October 03, 2015

Pharo Weekly - Steady progress is Pharo rythm

16696 Execution Demo with Reflectivity

16694 optionMetalevel and some cleanups

16697 NautliusPluginManager context menu broken
16685 remove ThemeIcons references in GTools

16702 remove ThemeIcons references in GTInspector

16701 remove ThemeIcons references in Catalog

16700 remove ThemeIcons references in GTSpotter
16680 remove direct references to icontheme classes
16602 Only get a basic command line handler in the bootstrap (avoid startup preferences)
16686 remove ThemeIcons references in ShoreLine

16673 Senders of… highlights wrong code segment
16691 MouseFocus and triggering modal dialogs from mouse event dispatcher

16690 Spec WidgetBuilt is send with an Adapter but it should be a widget (Morph)

16068 Debugger is losing the source code changes on method context change

16688 Coverage Demo with Reflectivity

16490 MorphSlot

16682 Syntax Error when recompiling the image

16679 links on Slots: add all reifications

16645 RBParser should not accept # <whitespace> and # <number>

16655 Menu stay up icon isnt removed
16674 Navigate from Variables to AST Node accessing that variable

16677 #after on Globals and Slots

16676 Desktop Logo hidden behind Background image

16660 improve #isUsed for Behaviours

16669 MetaLinks on Slots

16670 optionInlineCondition: do not inline condition

16668 Variables button throws KeynotFound when a variable is selected
16663 Minor tweaks to the Nautilus variable menu

16667 do not inline meta link: #optionInlineMetaObject

14618 Add a comment describing RBFileBlocksRule

16654 test for #optionOneShot and accessors for pre-defined options

16662 SlotClassBuilderError –> tClassBuilderError

16658 Reflectivity: crash on Morph Invalidate
16661 compatibility check when putting links on variables

10219 Completion: enter on accept awkwardness

16659 add #entity reification
16652 Menues now have a very strange reddish color

16631 Move integration rules to a PharoCriticRules class
16647 Nautilus Variable Menu Improvement

16648 ThemeSettings protocol cleanup

16649 Links of Globals and Class Vars: implement all reifications + extend for Globals
16646 test + fix: #after mit access to temp in method

16642 availableReifications: return the list of supported reifications for an entity

16632 RBParser should reject – space literal

16640 Reflectivity: add support for reifications #name and #value for Class Variables
16591 #findVariable:ifNone: methods needs to go back to Opal

16633 Rename layout to classLayout (step 1 add accessor)

16639 fix non common smalltalk syntax in PointTest

16620 Add a category “Pharo integration rules” to the critics browser

15858 review rule RBAbstractClassRule

16402 Diff view partly broken (Refactorgin ChangesBrowser)

16600 System-Changes should not depend on system-FileRegistry

16616 “Eliminate guarding clauses” critic is named wrong and maybe should be removed

16624 SimpleBorder borderStyle should initialize its width to a number

16622 Merge latest rubric fixes

16603 System-Hashing should not depend on Graphics Primitives

16615 Improve ContributingToTheCatalogHelp

16614 To use at:ifPresent:ifAbsent:, ifPresent block argument should not be mandatory
16597 DNU RBParseErrorNode>>statements: when | is placed before a .

16599 Compression should not depend on Graphics-Display Object (leftover)

16610 test: block body vs block
16606 remove bubble like ballon tooltip from menus

16605 senders/implementors window shows unrelated content

16598 Cannot save the contents of the standard workspace to disk

16596 #before for Class Variable
16595 Get rid of UnicodeInitialization in the bootstrap

16594 System-Changes should not depend on Text-Core
16523 Nautilus Regex Search Box borken

16587 Deprecate SmalltalkImage>>#logChange:

16573 Monticello should not depend on System-FileRegistry
16589 #instead for block sequence

16588 Integrate Catalog 0.9

16586 Load latest version of CodeImporter

16581 one-shot links

16582 Reflectivity: #instead for sequence nodes

15260 WriteStream on new string

16578 Add an id to Session

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