This is part 4 of the increasingly mis-named Getting started with Ispec and Ioke trilogy. Last time we discussed the let keyword and I started working on the template object which represented the template to be parsed into a document.

Previously I used ISpec to assert that we could evaluate on cells on Bag. I wanted to start off this time by proving to myself that I could just as easily use activatable cells on Bag as well.

    it("should evaluate method on bag",
      bag = Bag mimic
      bag bread = method("butter")
      evaluator = Evaluator mimic(bag)
      evaluator evaluate(bread) should == "butter"
    )

As you can see, this time instead of assigning a string to a cell on the property bag an evaluating it, I instead assigned a method which returned a string to a cell and evaluated it. Sure enough it worked without any changes to the code. This creates some interesting possibilities, though I haven’t thought through all of the ramifications at the moment.

Sure enough it worked.

Next I wanted to push the envelope on Evaluator a little bit by defining the method which will do the work of parsing the template and injecting the values from the property bag into it.

describe("parsing",
    it("should return the template when the bag is nil",
      evaluator = Evaluator mimic(nil)
      template = Template mimic
      template text = "An extra special template"
 
      document = evaluator combine(template)
      document should == "An extra special template"
    )
  )

This is really a small step, and as I get more familiar with TDD and BDD, these seem to the the steps that I’m most comforable with lining up and knocking down when implementing new features. The other part of this is, doing the simplest thing that could possibly work to pass the spec / test. In this case, this is the simplest thing.

Evaluator combine = method (
  "Generates a document from a template and bag",
 
  template,
  template text
)

From here, I think that the next step is going involve using Ioke’s implementation of Regexp, which I will need to read up on. So I think I will cut this short for today and wait for next time for that topic.

The Code

The code for this example is available on github tagged as start_ispec_4

A little while ago, I issued my Summer of Learning Challenge. As a suggestion, Ioke would be a great thing to learn for those that would like to learn something this summer, but aren’t sure what to learn. My project for the challenge is Ruby based, though I have a goal for the year to learn Ioke. As you can see from my Calendar About Nothing, which currently has a 15 day string of commits, I’ve been busily plugging away at both.

A few days back, Sam Aaron stopped by and commented on part 2 of this series, pointing out an error with my code.

Oops

Well, there were two errors there. First my spec stated that Bag should evaluate nil as an empty string, but code specified that it should be nil. Secondly, I had a problem with the way I had constructed my message chain so that my spec was evaluating nil should == nil. Of course this will always evaluate to true. I patched it up with the help of some advice in the comments. In the future I’ll need to remember to be more explicit in my intent by remembering to use parens when passing parameters to methods so that they aren’t interpreted as part of the message chain.

My initial solution, which I updated to the post, was to monkeypatch bag so that the cell nil returned an empty string. This solution didn’t really set well with me, but it passed the spec so I stuck with it. After some rest, I remembered reading about the keyword let.

The joy of let

I wasn’t familiar with the let method from the other languages I use, which are primarily Ruby and C#. But a little research showed that it provided an alternate solution to the specification. Opening up the specification for let, you will see that it accepts zero or more comma separated name value pairs and a block of code. It will then create a new temporary scope where the name is assigned the value and the code block is evaluated. At the end of the execution of the code block, the scope goes away and everything returns to normal.

Evaluator = Origin mimic
 
Evaluator initialize = method (
  "Pass the property bag into the evaluator, this will be used for future evaluations.",
 
  bag,
  @bag = bag
)
 
Evaluator evaluate = macro (
  "Takes the supplied message and evaluates it on the property bag. If nil is passed, it will return an empty string",
 
  msg = call arguments first
  let(bag nil, "",
    msg evaluateOn(bag)
  )
)

This is an interesting alternative. It provides a way to temporarily modify an object while ensuring that your modifications don’t touch anything else once you are done.

Variations on a theme

One thing that I found particularly interesting is that all of the following variations seem to work

  let(@bag nil, "",
    msg evaluateOn(bag)
  )

  let(bag nil, "",
    msg evaluateOn(@bag)
  )

  let(Bag nil, "",
    msg evaluateOn(bag)
  )

I assume that the first two versions work because the sigil version of bag (@bag) simply points to the instance stored in the cell bag on the evaluator object. In other words, when using Evaluator as ground, from inside the object, bag and @bag have the same meaning. I’ll need to look into this to see if what I suspect is true.

I think that the third variation works because bag mimics Bag and so changes to Bag cascade to bag. If it is true that modifications to the parent object made after the mimic has been made will cascade to all mimics, then that is a very powerful and easily abused feature of Ioke. Again these are speculation on my part, and I will need to look into the truth of the matter.

Starting Templates

Once I had that figured out I started thinking of the next specification to tackle. I decided that if I’m going to be able to use Ioke, I’d need to figure out how to work with files. I feared that working with files might have been left out of the Ioke implementation as it is a very young language. As it turns out, I was dead wrong. The FileSystem object is implemented and quite easy to use.

Ioke and the FileSystem

I was quite happy to find a spec for the FileSystem so that I could get a feel for it. It turns out that there are a number of useful methods available and it appears to have support for Windows filesystems as well.

I decided to have my template object check to see if the string passed to it is a valid file. If it is, it will load it. If not, it will assume that the string passed to it is the template text. I made it this way for testing purposes more than anything, and may change it around if it causes issues. But it was simple to setup and it works.

 
Template = Origin mimic
 
Template load = method("load will load a template file.",
 
  template,
  if(FileSystem exists?(template),
    Template text = FileSystem readFully(template),
    Template text = template
  )
)

The Code

Current source snapshot is available on github tagged as start_ispec_3

I was recently reading a post on using Ioke’s web kit, IKanServe, on Google’s App Engine. It comes with a built-in HtmlBuilder object, but I wanted to try making something more like a rudimentary erb. Basically a way to embed code in template files.

Evaluating on the property bag

So far I have created a basic property bag, which is really just a basic Ioke Object. At it does is serve as a portable ground on which to evaluate messages on. Next there is the Evaluator which takes a bag when it’s initialized and evaluates messages against it, returning the results.

Don’t be put off by Ioke’s advanced features, it’s quite usable

When I first thought using this as an example, this was as far as I got. I figured that If I could get to the point where I could have a parameter object that could be be evaluated against from another context, I would probably have put in a siginificant amount of work for a basic example and I could wrap it up call it a day and try using it with IKanServe. Well as it turns out it wasn’t all that difficult to do. Really it was quite simple. I updated my test/evaluator_spec.ik to read:

use("test/helper")
use("evaluator")
use("bag")
 
describe("Evaluator",
  it("should have the correct kind",
    Evaluator kind should == "Evaluator"
  )
 
  it("should have accept a bag on initialization",
    bag = Bag mimic
    bag foo = "bar"
    evaluator = Evaluator mimic (bag)
    evaluator bag foo should == "bar"
  )
 
  describe("Evaluation",
    it("should evaluate nil as an empty string",
      bag = Bag mimic
      evaluator = Evaluator mimic(bag)
      evaluator evaluate(nil) should == ""
    )
 
    it("should evaluate string on bag",
      bag = Bag mimic
      bag foo = "wuzzle"
      evaluator = Evaluator mimic (bag)
      evaluator evaluate(foo) should == "wuzzle"
    )
  )
)

Looking at it now, the last spec should read “should evaluate message on bag” but you get the idea. At this point, I set out to implement this spec.

Don’t forget commas

My biggest problem by far was of my own design, and my own fault. When I first typed up the spec I left off the comma at the end of

    it("should evaluate nil as an empty string",

This caused the compiler to output a not so pretty error message, that that took me quite some time to track down. You see, I was sure that the issue was with my implementation of Evaluator rather than a syntax error in my spec. So, if you are getting an error that says that it can’t import your spec, look for syntax errors there first. You might be missing a comma.

Principle of least surprise

One of the things I really enjoy about Ruby is that it subscribes to the principle of least surprise. That is, if you don’t know the syntax for something, there is a good chance you will find it by trying the syntax that would make sense to you. I think that this is a side effect (or not so side-effecty) of what Ola Bini recently termed Syntax over Explicit APIs in the Ioke Philosophy.

In any case, the code to pass the spec was simply:

Evaluator = Origin mimic
 
Evaluator initialize = method (
  "Pass the property bag into the evaluator, this will be used for future evaluations.",
  bag,
  @bag = bag
)
 
Evaluator evaluate = macro (
  "Takes the supplied message and evaluates it on the property bag. If nil is passed, it will return an empty string",
 
  msg = call arguments first
  msg evaluateOn(@bag)
 )
)

Bag = Origin mimic
 
Bag nil = ""

I figure that there is probably a pretty big hole in my code here somewhere that I’m going to expose as I play with this more, but for now, I’m happy that it’s passing my spec.

Update: Thanks to Sam Aaron for pointing out the flaw in my spec.

Documentation arity

Before I conclude this post I wanted to mention the optional documetation that can be added to a method / macro / etc by passing the string that documents it in the first position. It reads well and it’s better than standard comments because the documentation is treated as it’s own first class member of the language.

Code

Source for this example can be found on github tagged as added_evaluator.

Now that I have downloaded and built the source for Ioke E, I wanted to start using it. After all, I made a goal back in January to start using it, but as of yet had failed to follow through with it. Oh sure, I’ve been keeping up with the blog posts and looking at it from time to time, but really hadn’t made any steps to speak of. Until today.

I think that what I really needed was to find some common ground with Ioke. Something I could call familiar and the branch out from. ISpec is where I found it. I found it in two ways really, first in the ability to write specs to test my knowledge of Ioke coding and also in reading existing specs that have been written. These specs run when you download and build Ioke from source, which incidentally, is a painless process I would recommend to any interested.

So what’s next?

Note:I’ve pushed my code out to github tagged as start_ispec

I started out by creating a directory for my project with subdirectories for src and test

~/working $ mkdir ioke-examples
~/working $ cd ioke-examples
~/working/ioke-examples $ mkdir src test

Next I created my first spec as test/bag_spec.ik.

use("ispec")
use("src/bag")
 
describe("Bag",
  it("should have the correct kind",
    Bag kind should == "Bag"
  )
 
  it("should return the values in assigned cells",
    Bag name = "cheeze"
 
    Bag name should == "cheeze"
  )
)

There is nothing really interesting being tested here, the behavior is that of pretty much any Ioke object. The only thing of note is that the use directive is from the root of the project so to specify bag.ik which as a relative path from the spec would be ../src/bag.ik, was actually just src/bag.ik. Next I made an implementation src/bag.ik as

Bag = Origin mimic

This passed. Next I started making a another spec and class. Thinking that I would keep going with this path of thought. I made test/evaluator_spec.ik as:

use("ispec")
use("src/evaluator")
 
describe("Evaluator",
  it("should have the correct kind",
    Evaluator kind should == "Evaluator"
  )
 
  describe("Evaluation",
    it("should evaluate nil as nil"
      Evaluator evaluate nil should == nil
    )
  )
)

and src/evaluator.ik as

Evaluator = Origin mimic
 
Evaluator evaluate = method (
 
)

This results in the following

~/working/ioke-examples$ ispec test
.P..
 
Pending:
 Evaluator Evaluation true (Not Yet Implemented)
 
Finished in 0.26 seconds
 
4 examples, 0 failures, 1 pending

Pretty neat that it sees it as a pending implementation. Overall this was a great success, ISpec was working, but something was still nagging me.

Something isn’t right

Maybe it’s my Ruby roots, maybe it’s that I was being picky but having to specify the source directory when referencing bag.ik and evaluator.ik just didn’t seem right. I needed something like test_helper.rb in Ruby.

I looked around for a while and finally started digging into the test directory for Ioke, which is a great reference for the language. Three cheers for TDD! After a little fiddling I found that I could make a file called test/helper.ik as follows:

use("ispec")
System loadPath << "src"

This automatically loads ISpec and also adds the src directory to System loadPath, which is a list of the locations that Ioke will look for files in the use directive.

This allowed me to change use directives at the beginning of my specs to something like:

use("test/helper")
use("bag")
 
describe("Bag", ....

Comfort level

Now that I have my ISpec basics up and running, I hope to be playing more with this interesting language. Hopefully you will be seeing more Ioke posts here soon.

I’ve now installed basic Ioke on Windows and Linux and it was painless in both cases, which was an unexpected pleasure. Once installed, you can fire up the REPL with a simple ioke at the command line. What you are presented with will look something like this:

1
2

rubyyot@atlas:~$ ioke
iik>

You are now ready to play with Ioke. It is quite different from what I’m used to. I would recommend that you try out the interactive mode as well to get your feet wet. That way you will get immediate feedback.

A few things stand out immediately when playing around with the language. The first is that there is no dot notation. Second are the concepts of cells and Ground. Third is the that it is a prototype based language.

It’s not a dot, it is a period

Object oriented programming is supposed to be littered with dots, it’s part of the language. Without the dots how are we supposed to tell where one word stops and the next begins. This is insane!

Or is it. English doesn’t use dots to separate it’s words. Tell.me.does.this.look.like.a.natural.sentence.to.you? No, it really doesn’t to me either. Asthetically, it’s only slightly betterThanCamelCase. Ok, so I get it, the whitespace separates the words , or in this case they are called messages. You may ask, “What is a period good for?” Let’s go to the REPL and find out.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

iik>; "hello world" println
hello world
+>; nil
 
iik> "hello world" println. "hello ioke" println.
hello world
hello ioke
+> nil
 
iik> "hello world" println "hello ioke" println
hello world
hello ioke
+> nil
 
iik> "hello world". println
*** - couldn't find cell 'println' on 'Ground_0x17B4DFB' (Condition Error NoSuchCell)
 
 "hello world"                                    [<init>:1:15]
 
The following restarts are available:
 0: storeValue           (Store value for: println)
 1: useValue             (Use value for: println)
 2: abort                (restart: abort)
 3: quit                 (restart: quit)
 
 dbg:1>

Wow, so what’s all that? Well I evaluated 4 statements using the REPL. The first one simply told Ioke to print the string “hello world” on the screen followed by a new line. So far so good, I’m now past the obligatory Hello World command. The line beginning with +> displays the return value of the evaluated statement. In this case it was nil, which should be familiar to those who have used Ruby and for anyone else, it means the same thing as null.

The next expression that I evaluate is two println statements each followed by a period so that the compiler will know that I handed it two statements. Sure enough, we see that both lines are printed. So, the period can be used to separate statements. Or can it, the next experession yeilds the same results without a period in sight. This is an interesting development. Perhaps I had it wrong.

To test my theory I decided to try placing a period between the string and the println message. What happened was that I got an error saying that println is not valid for Ground. Even though I’m not entirely sure what ground is at this point, it’s fairly obvious that the placement of the period caused the println message to be called on something other than the string I passed it. As a side note, the error was nicely caught by the debugger which prompted me for an action to take.

Ground, Origin and cells

So let’s see what this Ground is that the debug message was talking about. According to the documentation:

Ground is the default ground/context for evaluation.

Meaning that Ground is a high level object that is the default context for evaluation of a message. For this to become a little clearer, a little background of the Evaluation Model helpe. Here is an excerpt from the wiki that helps sort it out. It takes the code foo bar(flux bar) quux and breaks down the evaluation into steps.

1. The message foo is sent to Ground, which is the current ground and also the default receiver.
2. The message bar is sent to the result of the foo message. The value returned will be activated.
3. The cell bar contains a method in this case, and that method expects one argument, so that forces evaluation of the arguments.
4. The message flux is sent to Ground, since it’s the ground and there is no prior message inside of an argument list.
5. The message bar is sent to the result of the flux message.
6. The result of the bar message is used as the argument value given to the outside bar method.
7. The message quux is sent to the result of the initial bar message.
8. The result of the quux message is thrown away, unless this code is part of a larger piece of code.

Here we see what it means when we say that Groud is the default context. The messages foo and flux have no receiver (there are no words preceding them in the execution model) so the receiver is defaulted to Ground.

Lets now take a closer look at objects in Ioke. Each object has an infinite (at least that is how I see it in my mind, there probably is some sort of limit on it) number of storage containers called cells. You can name these cells and fill them with stuff. You can fill them with data, and objects. These would be considered cells filled with content that is not activatable. Here are some examples

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

iik> foo = Origin mimic
+>  Origin_0x26FBCA:
 
iik> foo cheese = "Cheddar"
+> "Cheddar"
 
iik> foo answer = 42
+> 42
 
iik> foo
+>  Origin_0x26FBCA:
  answer                       = 42
  cheese                       = "Cheddar"
 
iik> bar = Origin mimic
+>  Origin_0x19A1925:
 
iik> bar size = "little fish"
+> "little fish"
 
iik> foo stomach = [ bar ]
+> [ Origin_0x19A1925:
  size                         = "little fish"
]
 
iik> foo
+>  Origin_0x26FBCA:
  answer                       = 42
  cheese                       = "Cheddar"
  stomach                      = [Origin_0x19A1925]
 
iik> foo stomach[0]
+>  Origin_0x19A1925:
  size                         = "little fish"

Here I’ve made two objects, each of these objects mimics Origin. Origin being an object designed to be the starting point for other objects. It seems to be a bit lower in the object hierarchy than Ground.

You can also put activatable content in the cells, these are methods (he behavior component of the object). Here is an example using the previous objects:

1
2
3
4
5

iik> foo ask = method(question, answer)
+> ask:method(question, answer)
 
iik> foo ask ("What is the meaning of life, the universe and everything?")
+> 42

Here, I’m simply creating a method that takes a parameter called question and always returns the value of the cell answer. Because a method is activatable it is executed when the cell is referenced.

Mimics and prototypes

Ioke is a prototype based language, this is a concept that I’m having the most difficulty with. I’ve spent so much time working out the relationship between classes and objects, and here is a language that does away with the concept of classes altogether. Instead of using a class as a template for a new object instance, the new object mimics an existing object. This means that the templating comes from an instance of an existing object. I’m going to have to get used to this one.

Well I’ve cracked the seal on Ioke and it’s been a pleasant experience that still seems a bit foreign. I’m going to work with it some more and hopefully post some interesting things that I find.

A couple weeks go by, and occasionally your internal alarm goes off, telling you that you need to stop procrastinating and get it started. Yeah, I know how that is.   It’s been a couple more weeks than that and I haven’t started learning Ioke.  Sure, I’ve been busy.  Not so busy that I couldn’t have done anything.  Just busy enough that it’s been a good enough excuse.

Well, I’ll be honest.  There’s another reason why I haven’t started working on learning Ioke yet.  Truth be told, Ioke scares me a little.

Now don’t get me wrong, it’s a very interesting language;  one that I am very much wanting to learn.  It’s just that it’s outside of my comfort zone.  It’s foreign, and it uses strange terminology like mimic and Ground and macros.  It knocks me down a few notches, tells me that I may have learned other languages, but it’s different, it won’t crack so easily.

Of course, that is optimal.  I wouldn’t want to attempt to expand my horizons with a year of  Python because I already know Ruby and while there would be some lessons and perspectives to learn, my time would be better spent with something further outside my comfort zone.   Java would be a similar issue, already knowing C#, eye opening moments would be minimal.

The very fact that Ioke both interests and pushes me out of my comfort zone makes it the perfect candidate for me to learn.  It presents a challenge which is just what I need.

Knowing this, it is just a matter now of powering through the initial learning curve and getting on with the benefits.  Yeah I know, I’m getting to it.  Meanwhile, are there any goals that you have set for yourself in 2009 that you have having a hard time starting?  What is holding you back?  Anything that is pulling you out of your comfort zone?