for(i, 99, 1,
writeln(i, " of beer on the wall, ", i, " of beer,")
writeln("take one down, pass it around,")
writeln(bottle(i - 1), " of beer on the wall.")
)
Well yes. But only three of those arguments are evaluated (99, 1, and the
body of the loop). "i" is never evaluated, we just inspect the name supplied
by the user, and use it to set a slot which you can use in the body which
represents the element you're looping over. 99 and 1 have a cached result
set so they're nice and quick. The cost of a method/block to activate in Io
is roughly 4x to 20x greater than for a message to evaluate, which is why we
tend to use messages instead of blocks. (Just as a side note, I generally
avoid using the for loop and opt for Ranges myself, they just read better:
99 to(1) foreach(i, ...); but the same principal applies.)
jeremy-
can you elaborate on what messages are? where are the messages in this code
snipper - or are there? alternatively can you just point me to a good rtfm
link?
Sure. It's really simple actually. Every bit of Io code you see (excluding comments) are messages. Io is a message based language, there are no keywords, and infact, the only reason comments aren't messages is because I havn't completed my patch to Io's parser and lexer to transform #, // and /* */ into an actual message yet.
Considering the parse tree for the above can be a little more verbose than it needs to to demonstrate how Io is parsed, I'll draw out the parse tree as a list of lists (try not to think of it as a tree because it's not really). The code example is:
method(a, a * a) call(5); otherStuff
The above is transformed into several messages
--- method --- call
> a 5
> a - *
> a
>- otherStuff
(Apologies if your mail client made that look funny.)
The horizontal list (delimited by ---'s) can be seen as the "attached" tree. This tree represents messages attached to one another. Using a ruby example: foo.bar <-- "bar" is said to be "attached" to foo. The vertical tree stemming down from "method" and ending in |- represents the "next" message. Again using a ruby example: foo; bar <-- "bar" is said to be "foo"'s next message. The tree of messages to the right of the bar's dropping down from method is the list of arguments of a message and all the same attached/next rules apply within argument lists (they're afterall, just the start of new nested message trees).
A quick note on how "*" (and all other operators are parsed); You do not require explicit parenthesis to use them (much like Ruby); however, not all methods work this way. The parser sees an operator character and turns it into a proper method call. That is, the above code "a * a" is seen at parse time and transformed into the code: a *(a). You can write code like that if you want, but it's not generally done outside of the VM. That is the one real oddity.
In the above way, it's possible to easily conceptualize Io code in terms of how it's parsed. However, we also expose the parse tree in code and give you primitives for manipulating it, so Io code can be difficult to read based on this (I can already hear Haskell people plugging their ears and singing "lalalala, I can't hear you") just because it's near impossible to reason about an Io program without the entire program. You cannot be sure that a component in one object will be handled how it's parsed. That said, it's not really as bad as I make it out to be; most code can easily be reasoned about.
Sorry for the quick and loose description, I intend on dedicating lots of time in writing documentation which covers messages, how they're used, what you can do with them, etc., but Io currently has a chronic lack of in-depth documentation. We're still in a late beta stage at the moment, but the language is pretty much solidified (some work on the standard lib still to be done), but the goal is to have decent documentation readily available within the next year. So my apologies for the sparse information on the website.
···
On 06-10-05, at 11:10, ara.t.howard@noaa.gov wrote:
On Thu, 5 Oct 2006, Jeremy Tregunna wrote:
--
Jeremy Tregunna
jtregunna@blurgle.ca