Moving the blog

Well, leaving this up here, won't delete it, for all the Io related material in the archives that people might find interesting... But as far as Caribou goes, I'm moving all the updates to the new website, which is at http://www.cariboulanguage.org/.

Just a note, there's obviously a blog on the site, very simple, no more than I need... also the issue tracker is under development. I've also posted the URL to the git repository, though the source code is a little incomplete right now, but feel free to follow development if you want.

Anyway, read me soon over here!

Been busy with other things...

No new news on Moose, except that I've renamed it "Caribou". I've been busy with real life matters lately, namely getting married.

I'm now married to the most wonderful woman on the planet, Adriana and I'm taking some time away from coding for the next little while.

So ... new MacBook

Well, I went out and bought a brand shiny new aluminum MacBook... the 13.3", 2.4 GHz model. It's really nice, and one thing I've been wanting for the longest time -- NO TRACKPAD BUTTON!!! Well, I should clarify... They haven't got rid of the button, they have just made the whole trackpad a button. Which can be a little annoying, but meh.

Anyway, it's my new development machine, have to adjust to the qwerty-us layout again, but give me a week. More on Moose later.

Moose development resumes

Well, this is my first post in a long time, but some good news to announce: Moose development has resumed.

I should note right off the hop, design decisions that have been made:

The object model is very lightweight. It's actually an implementation of the id object model with one minor modification: I don't like the name "vtable" so I renamed it "behaviour". If you are not familiar with that object model, read the paper linked to get an idea.

Secondly, the language as being implemented currently is just the first stage bootstrap compiler. That is, it is going to be extremely lightweight with nothing but the absolute bare necessities required to implement a second stage compiler which will be written in the language proper. This second stage compiler will be more complete.

As you can guess from the above descriptions, Moose will be a compiled language. That is, we will generate managed C code, which our compiler will then invoke the system C compiler to generate code. That said, there will be an interactive REPL for interpreting code without compiling it. However, you will not be able to access the low level system from the REPL. That is, instead of building a virtual machine for Moose to be implemented on, we will simply allow you to access the C structures, wrap C libraries trivially, create bindings for C libraries that do not require you to actually implement some protocol in C code, and then integrate it to the virtual machine for it to be visible in Moose.

I know right now, this sounds a lot like pepsi, and you know what? It is a lot like pepsi. However, it is meant to be a general purpose language, whereas pepsi is meant to be a language used for construction of other languages as far as I've been able to tell. The primary goal for Moose is to be small (both in memory footprint, learning curve) and fast (in terms of performance, debugging, and otherwise). While that previous blurb sounds more like marketspeak, it's hard to get concrete at this stage of development since not a lot of decisions have been made yet. There are a bunch of tentative decisions that are in my head right now, but whether they'll actually work, remains to be seen.

Currently I have the object model completely implemented, tested and debugged; and have started to performance benchmark it against other models, with surprisingly good results. However, I'm going to belay posting those until the system is anything more than a few routines ontop of C. Once a parsing subsystem is implemented, and a basic set of primitive objects are in place, then I'll test again and we will see.

More will follow in the coming days, week, whenever I post again.

[UPDATE: In case you didn't infer it from my posting, this version of Moose is a complete rewrite of any other versions that have existed.]

iPhone anySIM

While not really related to this blog, I'm not starting another one just because of this.

In any event, I've recently noticed that drudge from ##iphone on freenode, and of conceitedsoftware.com fame, has stopped distributing the anySIM software unlock under concerns about the DMCA and legality of distributing it in the USA. I've started distributing it on my iPhone Installer.app repository now, as I fall outside the jurisdiction of the DMCA.

In any event, mine is live now (though it may take up until tomorrow for the DNS to propogate, so if it doesn't work right away, try again tomorrow). Open up Safari on your iPhone, and point it at: http://iphone.blurgle.ca/repo/ (the trailing slash is important). Tap "Yes" when prompted, then you will be able to install anySIM again. The 1.0.1-3 version is the same as the 1.0.1 version, but it received the version bump due to the version bump given on conceitedsoftware.com's version which removed it from their service.

If you have any problems, the instructions still exist over at conceitedsoftware.com as to how to fix it. In the coming days I'll be duplicating those over on my server.

Musings on conditional execution

Well I've been mulling over the idea lately that perhaps I should include, as a core language feature, the ability to execute "instructions" conditionally. Now I know exactly what you're thinking: "Isn't this what the if() construct, and the like are used for?" Well, you'd be absolutely right. Except one key little thing: I think that having to explicitly define if(someCondition, onTruth, otherwise) is kind of silly when one could write:

(bob age == 42) "bob is forty-two" println.
(bob age == 23) "bob is twenty-three" println.

Now this does bring into play a couple of issues. What about duplication? Multiple comparison? Fallback conditions? Performance?

Well, I can answer a couple of those right now. Let's start in no particular order with the fallback condition. Consider if you want to fall back to a traditional else block:

(
  (bob age == 42) "bob is forty-two" println.
  (bob age == 23) "bob is twenty-three" println.
  (true) "god only knows how old bob is" println.
)

Is one way to solve this, however there surely has to be a better way to accomplish this syntactically.

What about performance? Well, we'd encode a single bit in each object which basically states "yes, this object has a predicate" or not. If it does not, then the condition is expected to be true, and the code will be executed. Now, this check will add minimal time to the execution of a Moose program, as Moose is already very slow compared to some other folks expectations.

Finally, on the duplication front. There could be a syntactic extension to reduce this, but I don't see a need. Just assign your predicate to an object before hand, then use it in the parenthesis.

In any event, I cannot really answer the question about multiple comparison yet, as I haven't hashed out any ideas on that yet.

All this said however, this may very well just be a pipe dream to get rid of both for() and if() in one language, but I think it can be done w/o going declarative.

Not dead, honest!

Well, it's been quite a while since I've posted here. Basically I'll give a rundown of what I've been doing with my time, and why I've not been bothered posting here.

1) Progress on Moose has been next to nil since the start of the year; it's gone through two redesigns, and three implementations and I'm no further ahead than I was back then really.
2) Home life has been busy.
3) Our company has been expanding our network so much it's eaten into a lot of my extra time.

In any event, nothing really interesting to post about right now, other than I just received my new iPhone today, and it's really nice.

Lots of fun...

Well, my birthday came and went, and I decided now was about time to pick up a macbook; so I did that on yesterday. It's really nice looking, and speedy, I like it.

In any event, I've not been doing much work on Moose this past week, but I will endeveur to work some more on it in the coming weeks, but I make no promises of real progress until after the holidays.

Cya!

A functioning prototype

Well, I've got a very rough working version of Moose running now with a crude object system and not much else. =] In any event, I thought I'd show it (the syntax is just what comes naturally to me, it may change so don't get too attached to it, or annoyed by it). Let's start with a factorial:

fact := method(1): [ n | (n = 0) ifTrue: [return 1] ifFalse: [return n * fact(n - 1)]].

At first glance it looks a lot like Smalltalk, but it's not; it's a lot more like Io than the syntax makes it appear. I'll break down that example at a source code level, then break down (in brief) the elements that make it go.

fact := method(1)

Is akin to the Io code:

fact := method(
  if(call message arguments size != 1,
    Exception raise("Invalid number of arguments, expected 1 got " .. call message arguments size)
  )
)

Noting of course that this argument is entirely optional -- without it, calls to the returned method won't bail on any errors no matter how many (or how few) arguments you supply.

But you may be wondering, what's that ':' and [] code after it? Well, that's the body of the method -- i.e., the "connected" code block (sorta like in Ruby). Unfortunately for the moment (until I find a syntax which is better equipped to handle this case), only one code block can be connected to a message.

Now, just to finish up the comparison:

[ n | (n = 0) ifTrue: [return 1] ifFalse: [return n * fact(n - 1)]].

Is a block (lexical closure) like in Smalltalk. It expects one parameter (enforced by the method(1) declaration earlier), and checks whether the condition "n = 0" is true or not (ifTrue/ifFalse being different methods as in Io, not as in Smalltalk). The same code in Io could be written like:

block(n, (n = 0) ifTrue(return 1) ifFalse(return n * fact(n - 1))

One final note about the syntax, you'll note the trailing "."; this is a break in the message tree. In Io, you'd use ";" or a newline (provided an open parenthesis or comma wasn't the last token on that line) -- in Moose, I've elected to require a message tree termination character. This is again, something I may drop, let's not get hung up on it -- suffice to say, I put it in there as just a thought to allowing line continuation (a common complaint in Io).

Now then, the object system is really primitive. Currently, there is no form of inheritance or anything fancy like that so I'm not even sure you'd call it an object system yet, but in any event, what's happening isn't that different than what's happening in Io (except everything is being executed within the context of a single object -- the Lobby): The parsing system transforms the assignment into this call:

defineSlot(#fact): method(1): [...]

Which as you can gather, sets a slot named "fact" (# being the symbol literal character, as in Smalltalk) in the Lobby with the value of the method object as defined above. Now then, we look up the symbol "defineSlot" in the Lobby, and if it's not present blow up, otherwise continue evaluating and do the same lookups for the arguments. Note that connected code blocks are not currently arguments to the calling method as in Ruby, but separate entities which can be attached to any method even if they weren't written to take advantage of. Connected code blocks are actually said to be connected to the message of the receiving method/block/closure so you are able to do some manipulations with them.

There's a couple reasons I chose to create this extension to basic Io syntax. First off, it will help out detecting syntax errors immensely! This has been a long standing gripe of mine -- though to Io's credit, it's not an easy fix w/o changing Io's syntax. Good error reporting is critical to any language for it to be successful in my opinion, and a syntax as flexible as Io's can easily be extended to help facilitate this without giving up anything flexibility. Secondly, it just flows better in my mind.

It should also be noted that incase you didn't infer this behaviour, I should mention it explicitly: Connected code blocks activation is the responsibility of the method it's being connected to.

In any event, this is just a teaser, I need to fix up the object system as currently all that happens when you "create a new object" (integers and symbols are exceptions, they're immediate values); is it just copies the lobby, and modifies it -- which as you can imagine, can lead to some weird behaviour.

Until next time...Enjoy!

Moose: Manifesto

"Why another language?" might be the first thought a lot of people might have, and others can probably see the need: There is currently a major gap for powerful high-level languages with a small footprint both in size and memory -- which is important for embedded devices, and some general purpose software.

Small

With the trend we've been seeing over the last 25 years is an ever increasing push to smaller devices. While the trend recently has been that these smaller devices are getting more and more storage (with increasing flash sizes and increased RAM), this does not preclude the need for efficient languages. C is without a doubt the most prevalent language in this arena, and probably will be for a very long time (with good reason: it's very efficient and very fast). However, I don't see the speed issue as a big one. These embedded devices are always getting faster and faster with reduced power consumption, and for most tasks handled today, one need not have a super fast language, all the time. So long as it is easy to extend with a language like C where needed, so much the better.

Concurrency

It is inevitable that we will also see the emergence of multiple core processors in this market, and as a result, to take advantage of this extra hardware, the ability to spawn multiple threads of execution will be key. However, concurrency as it exists in most languages today is heavily burdensome, and error prone. Languages of the future will need to have a sophisticated concurrency model in order to lift some of the burden of writing concurrent code, from the programmer.

Comparative Simplicity

While the above points are important, there is also one final absolutely key element to Moose: Comparative simplicity. First, let me define comparative simplicity, as it is not likely a term you've heard before. I define comparative simplicity as being as simple as possible to perform a given task without violating any of the pre-defined key goals. That is to say, any and all code should be written as simple as possible given that it should also be as memory efficient as possible, and without sacrificing flexibility.

I'm aware that nothing here is concrete in so much as it probably should be, but this is but a first step down a long road that will be paved with many changes in the concrete representations of these abstract goals.

In any event, until next time.

Moose - A primer

Well, I'll give a quick little rundown of various items, just more of an "about Moose" than anything technical, so feel free to ignore this since it's mostly useless.

In any event, it is my opinion that Io isn't moving back towards use in an embedded market. Sure, currently it seems quite like a good tool for a control language in many applications; but as for use in embedded devices, it's sorely lacking and not looking as if it's going to be making any strides in that area any time soon. This isn't really a shot on Io, it's just there's really nobody interested in doing this -- and the more and more the language is written in itself, the less and less that is practical for embedded devices, as the memory footprint grows. This is one main area of focus for Moose.

Secondly, but more as an extension to the first point; the memory footprint must be small, and as a result, Io's choice in garbage collection strategy, just doesn't lend itself very well to operating with a small memory footprint. So instead of copying Io's mistakes, all objects will not be of the same size, as mandated by Baker's Treadmill collector, and instead, we'll use a slight variation on cheney's copying collector supporting generations initially, and eventually find and implement a better algorithm for time.

Thirdly, and finally for now, I'm going to design a new standard library which will be mostly incompatible with that of Io and will probably more resemble standard libraries distributed with many Smalltalk vendors implementations thereof.

Finally, the name... If anybody has ever seen a Moose (Alces alces), it's a very large member of the deer family (Cervidae) with long springy legs, a heavy body and quite awkward looking when in motion. It's the most awkward animal I could think of that is native to Canada.

More details will be forthcoming when they well... are. =]

A lot has happened in the last 20 days...

As you've no doubt noticed, I haven't been posting a lot in the last couple weeks, and there's a reason for that: Increased load at work, work on the book, and other time consumables. In any event, this post is pretty important, so I'll get on with it.

I've made a decision today, one that will help me offload some of the backlog on my free time, and allow me to focus more on some specific priorities. Namely, I'm no longer actively contributing to the Io project. The rationale behind this is simple, I find myself more and more steering away from the direction everyone else wishes to take Io, which is fine. So I'm going to focus more on this half-ass fork I've been nurturing for the last while--though it's not really a fork, more of a re-implementation.

That said, I've also decided it'd only be prudent to rethink the focus of my book. I'm no longer dedicating it to Io (though certainly a lot of the data it will contain will be applicable to Io too), instead I will be focusing it as the introductory material for my language.

As a side note, I won't be returning to the #io IRC channel, and won't be running Hæmus any longer. If someone from #io wishes to run it for #io, I'd be more than happy to send that person the up to date sources and accumulated data, subject to the conditions of the BSD License with an advertising clause.

And finally, as of this moment, this blog is no more dedicated towards Io, but instead, my language: Moose. I'll make a new post within the few days outlining my rationale behind the name, direction I wish to take the language, and when I think there's something worth making available, I'll post a repository where one might fetch my language.

Until then, later.

Fixed block arity

Well, a while ago on the mailing list I got into a heated debate with a few people over the idea of a fixed-arity on blocks, and I'm here to eat my hat. Recently I've come into a few cases where it just made sense to limit the number of arguments passed in, so I modified IoBlock to support this. By default, we set the arity of a block to -1 which indicates that you can pass in as many (or as few) arguments as you want (just like the current behaviour), but if you pass "setArity" with an argument greater than or equal to 0, when that block is activated, Io will make sure that the person who called it, supplied the right number of arguments or it will raise a non-fatal exception.

I've made a patch and pushed it out to my public repository, I'm asking for you folks to try it out, see what you think, and leave a comment pro, for, undecided, whatever... My darcs repository is here and if it times out or is slow, my apologies, having connection issues of late, just try again later.

Enjoy!

Rational Numbers

Well, I've written rational number support for Io, which I plan on making into an addon RSN! In any event, if you want an early sneak peak at the code, you can have a look here and let me know what you think.

There is one little caveat that you should be aware of if you intend to use this; and that simply put is this: Io uses floating point numbers as its numbers, and since floating point numbers are well, imprecise, you can get some interesting results if you were to say:

0.111111 asRational

and expect to get "1/9", but instead get "8.006391e+15/7.205759e+16". I don't know what else I can do to stop this from happening, but if anybody has any ideas, I'd be more than happy to look at them.

That said, things like this work fine:

0.25 asRational == Rational with(1, 4)

In any event, as always, enjoy!

Welcome waxbolt

This is more related to the blog itself than to Io, but I'd like to take a moment to welcome a contributing author to posting on this blog. His name is waxbolt and he'll be documenting various items that may closer pertain to beginning users than the more advanced audience I usually target.

Anyway, I look forward to reading some of his stuff.