On 06-10-05, at 11:10, [email protected] wrote:
body of the loop). “i” is never evaluated, we just inspect the
generally
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.