Spry on Roads Less Taken

Spry Error Handling

Wed, 21 Apr 2021 00:00:00 +0000

Work on Spry continues… in small spurts. :) One thing that I have pushed ahead of me for far too long is error handling. People interested in Spry have been asking about it and yes, I decided to start getting a handle on it.

In fact, I wrote this article last year but forgot to get it done and published!

Error handling is an interesting topic, earlier it wasn’t really much controversy around it but the advent of new techniques (Optionals etc) in combination with languages making… “interesting” choices (I am looking at you Go) has made this subject fairly hot. So what do we want in Spry??

Revisiting Spry

Fri, 05 Jun 2020 00:00:00 +0000

After a period of slower progress I got reignited regarding Spry . So far I have written a lot of articles about Spry, and during this time things have evolved and changed.

So I am now trying to “clean house” on where Spry stands today. This sweep through the old articles is a first step, then I will update the language manual to be 100% in sync with the implementation.

Let’s go through the articles from the beginning!

Benchmarking Spry vs Squeak

Fri, 26 Aug 2016 00:00:00 +0000

Spry is evolving quite nicely during my night hours. Focusing on performance is however still premature, but I do want to verify that I am not barking up the wrong tree, like … in the wrong forest even. So I make trivial benchmarks from time to time, just to see and learn.

Some background on the Spry implementation may be interesting. Spry is implemented in Nim as a direct AST interpreter, it’s not a JIT, in only about 2000 lines of code. It has a recursive classic “naive” design and uses a spaghetti stack of activation records, all allocated on the heap relying fully on Nim’s GC to do it’s work. It also relies on Nim’s method dynamic dispatch in the interpreter loop for dispatching on the different AST nodes. Blocks are true closures and control structures like timesRepeat: are implemented as primitives, normally not cheating. Suffice to say, there are LOTS of things we can do to make Spry run faster!

The philosophy of implementation is to keep Spry very small and “shallow” which means we rely as much as possible on the shoulders of others. In this case, primarily Nim and it’s superb features, performance and standard library.

Enough jibbering, let’s do some silly damn lies - ehrm, I mean silly tests!

Is Spry a Smalltalk?

Tue, 19 Jul 2016 00:00:00 +0000

I love Smalltalk and I have been in love with it since approximately 1994. I have used VisualWorks, VisualAge (IBM Smalltalk), Dolphin Smalltalk, GemStone, Squeak and Pharo quite a lot, and I was very active in the Squeak community for a long period.

But the last few years, finally, I have started to feel the “burn”… as in “Let’s burn our disk packs!” . And last year I started doing something about it - and the result is Spry . Spry is only at version 0.break-your-hd and several key parts are still missing, but its getting interesting already.

Now… is Spry a Smalltalk? And what would that even mean?

I think the reason I am writing this article is because I am feeling a slight frustration that not more people in the Smalltalk community find Spry interesting. :)

And sure, who am I to think Spry is anything remotely interesting… but I would have loved more interest. It may of course change when Spry starts being useful… or perhaps the lack of interest is because it’s not “a Smalltalk”?

Smalltalk family Link to heading

The Smalltalk family of languages has a fair bit of variation, for example Self is clearly in this family, although it doesn’t even have classes, but it maintains a similar “feel” and shares several Smalltalk “values”. There have been a lot of Smalltalks over the years, even at PARC they made different variants before releasing Smalltalk-80.

So… if we look at Spry, can it be considered a member of the Smalltalk family?

There is an ANSI standard of Smalltalk - but not many people care about it, except for some vendors perhaps. I should note however that Seaside apparently (I think) has brought around a certain focus on the ANSI standard since every Smalltalk implementation on earth wants to be able to run Seaside and Seaside tries to enforce relying on the ANSI standard (correct me if I am wrong).

Most Smalltalk implementations share a range of characteristics, and a lot of them also follow the ANSI standard, but they can still differ on pretty major points.

My personal take on things in Smalltalk that are pretty darn important and/or unique are:

Everything is an object including meta levels
A solid model for object oriented programming
The image model
100% live system
The browser based IDE with advanced cross referencing, workspaces and debuggers
The keyword syntax and message cascades
Message based execution model
Dynamic typing and polymorphism
Closures everywhere with lightweight syntax and non local return
Very capable Collections and a good standard library

Not all Smalltalks cover all 10. For example, there are several Smalltalks without the image model and without a browser based IDE. Self and Slate and other prototypical derivatives don’t have classes. Some Smalltalks have much less evolved class libraries for sure, and some are more shallow in the “turtle department”.

In Spry we are deviating on a range of these points, but we are also definitely matching some of them!

Spry Performance

Tue, 24 May 2016 00:00:00 +0000

When writing Spry I am so far mainly ignoring performance. The general execution of Spry code will be a regular interpreter (although stackless I hope) and not a JIT. But that doesn’t prevent us from playing around and learning something!

In this article I do some silly experiments around interpreter startup time and fooling around with 40 million element arrays. As usual, I am fully aware that the languages (Pharo Smalltalk, NodeJS, Python) I compare with a) have lots of other ways to do things b) may not have been used exactly as someone else would have done it. A truck load of salt required. Now… let’s go!

Spry vs Allen

Sat, 14 May 2016 00:00:00 +0000

Allen Wirfs-Brock wrote down a bullet list of what he thought actually made it possible for the Alan Kay team to create Smalltalk , and many other ground breaking things, at Xerox PARC in the 70s. Let’s take a look at his bullets one by one and see how it applies to Spry and my puny little effort around it :)

Spry Modules, part II

Tue, 03 May 2016 00:00:00 +0000

In the last article I outlined a simple model of modules and that is kinda implemented but needs a few fixes. The next step is how to find and combine modules and this is an area where I want to push the envelope a bit. Most popular package/module systems today are quite trivial in nature. Often it’s a command line tool that queries central catalog(s) and then proceeds by downloading code in the form of source files onto disk. Then the compiler or runtime environment finds and loads the code by simply looking for files on disk. There are several parts of this that are very primitive.

When I built SqueakMap waaay back I was already then tainted with the idea of shared object models and one of the primary ideas in SqueakMap was to make sure each local Smalltalk environment got a full live object model of the catalog which then could be queried, viewed and reasoned about inside the Smalltalk environment. Much more powerful than a bunch of JSON files on disk. This led to the approach of downloading the full catalog in a serialized form - and then loading it into Squeak .

With Spry I want us to create a simpler meta model - at least for starters - but with an even smarter infrastructure backing it…

Spry Modules

Sat, 16 Apr 2016 00:00:00 +0000

As discussed in the previous article I want Spry to have a trivially accessible persistence mechanism enabling something similar to the Smalltalk image model, but based on a database. The memory organisation in Spry is basically nested Maps. After dwelling a bit on the inevitable hard question about modules and namespaces I have decided on a design that I hope will turn out simple and reasonably powerful!

Smalltalk has a Dictionary holding all the globals forming “the roots” of the object memory. In Smalltalk this Dictionary is also itself a global variable accessible as Smalltalk, in other words Smalltalk == (Smalltalk at: #Smalltalk). The primary use of Smalltalk is to hold all classes by name, so they are all reachable as globals. Obviously Smalltalk can also hold any kind of object (not just classes) as a global.

Spry also has such a top level Dictionary, but in Spry we call a Dictionary a Map to be a little bit more aligned in terminology with other languages (and it’s shorter). This top level Map is the root Map and it is accessible via the word root. In Spry the root word is actually bound to a primitive function returning this Map, so in Spry we also have root == (root at: 'root).

Ok, so Spry has a Map of globals and one way of using Spry is simply by populating root with words bound to functions making these functions globally accessible, it’s how I have done it so far. Yeah, yeah, I know, but for smaller systems it probably works just fine!

But…

Spry image model

Sat, 09 Apr 2016 00:00:00 +0000

In developing Spry - renamed from Ni - I am getting closer to the Really Fun Stuff.

As a Smalltalker I dream “bigger” than just managing source code as text in files…

Smalltalk uses the “image model” in which the system is alive and running all the time, the full development environment is also live together with your application, and we are in fact modifying object structures when we develop Smalltalk programs. We can also snapshot that object memory onto disk and fire it up somewhere else. Several Lisp implementations have used a similar approach I think.

The image model has tons of really cool benefits, I don’t have time repeating all of them, but a modern implementation of the idea should take a few things into account that was not considered in the 1970s:

The “image” in Spry will be buildable from source
You should be able to use Spry without the image mechanism (you can already)
Spry code will have a readable text format and file structure
The image model does not have to be all or nothing, it can be partial
The image mechanism will be a module for the Spry VM, so you can skip it entirely

Some argue that the image model has downsides - like being an “ivory tower” incapable of interacting with the outside world. The Smalltalk environments have indeed historically suffered a bit in varying degree, but we can easily find ways around those issues while still reaping the awesomeness of a fully live programming environment, especially if we give the above items proper thought from the start.

With Spry I think I have a beginning to a novel approach… as well as taking the above into account.

Ni renamed to Spry!

Fri, 08 Apr 2016 00:00:00 +0000

When I started out implementing my own language in Nim I named it “Ni” without that much thought actually. It was a pun on “smaller than Nim” (obviously one letter shorter!) and of course with a reference to Monty Python .

But… really, the name “Ni” sucks. It’s hard to say in general and since it’s often mentioned together with Nim the confusion is obvious. And it also turned out to be less than optimal to google for.

Adding objects to Ni!

Fri, 25 Sep 2015 00:00:00 +0000

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 ;)

Ni design decisions!

Wed, 23 Sep 2015 00:00:00 +0000

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. ;)

Guts of Ni

Tue, 22 Sep 2015 00:00:00 +0000

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

Who says Ni?

Wed, 16 Sep 2015 00:00:00 +0000

Ni is my own little language heavily influenced by Smalltalk but also other sources like Rebol, Forth, Lisp, Self and Nim. Ni is a bit strange, but it’s not academic and really meant to become something useful.

So put on your helmet and let me take you to the shrubbery…