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!

3 comments:
nice and clear syntax.
beautiful !!!
regards,
Tudor-Andrei Pamula
I hate to wait so long to possibly burst any bubbles, but a quick google search uncovered another language called Moose, for writing MUDs :/
Also, the syntax does look rather interesting. Some things could be polished a little maybe, others are perfect. My only "complaint" is the rather liberal use of [ .. ], though the rest does look quite good to me :D
Pls kepp on. Syntax looks better to me then that of Io and the footprint argument is very reasonable too.
There is a trend to more concurrency i see. eg erlang slowly gaining attention. functional concepts, mybe even a smalltal, revival comming. so your on the right path, I assume.
Post a Comment