Guide:Syntax - Revision history

Olabini: /* Syntax */

2009-12-22T16:27:28Z

‎Syntax

Olabini: /* Syntax */

2009-12-22T15:40:32Z

‎Syntax

spambot_Tumble: /* Operator shuffling */ spelling

2009-04-08T08:14:42Z

‎Operator shuffling: spelling

Olabini: /* Text */

2009-03-27T14:12:38Z

‎Text

spambot_Delitescere: /* Text */

2009-03-22T15:09:25Z

‎Text

spambot_Delitescere: /* Syntax */

2009-03-22T15:07:51Z

‎Syntax

Olabini: /* Regular expressions */

2009-03-10T09:33:55Z

‎Regular expressions

spambot_Mdobmeier: /* Execution model */

2009-02-08T10:59:32Z

‎Execution model

Olabini at 08:24, 26 January 2009

2009-01-26T08:24:07Z

Cv: /* Syntax */

2009-01-26T03:08:23Z

‎Syntax

@@ Line 160: / Line 160: @@
 * !
 * ?
 * ~
 * **
 * *
 * /
 * +
 * -
 * &lt;&lt;
 * &gt;&gt;
 * &lt;
 * &lt;=
-* &gt;=
+* &lt;=&gt;
 * &lt;&gt;
 * &lt;&gt;&gt;
 * ==
 * ===
 * =~
-* !~
+* ≠
 * &amp;
 * ^
@@ Line 189: / Line 198: @@
 * &amp;&amp;
 * ?&amp;
 * ||
 * !&gt;
 * &amp;&gt;
-* %&gt;
+* &amp;&gt;&gt;
-* #&gt;
+* **&gt;
-* @&gt;
+* **&gt;&gt;
 * *&gt;
-* ?&gt;
+* *&gt;&gt;
-* |&gt;
+* +&gt;
-* ^&gt;
+* +&gt;&gt;
-* ~&gt;
+* -&gt;
 * -&gt;&gt;
-* +&gt;&gt;
+* ..
-* !&gt;&gt;
+* ...
-* &amp;&gt;&gt;
+* /&gt;
 * /&gt;&gt;
-* *&gt;&gt;
+* &lt;-&gt;
 * ?&gt;&gt;
 * |&gt;&gt;
 * ||&gt;
 * ||&gt;&gt;
-* $&gt;
+* ~&gt;
-* $&gt;&gt;
+* ~&gt;&gt;
 * +=
 * -=
 * /=
-* %=
+* &lt;&lt;=
 * and
 * nand
-* &amp;=
+* nor
 * or
 * xor
 * |=
 * ||=
 * &lt;-
 * return

@@ Line 101: / Line 101: @@
 === Integers ===
-Ioke supports arbitrarily sized numbers. It also contains a numerical tower that can be more closely explored in the reference documentation. The numerical tower is based in Number. Number Real mimics Number. Number Rational mimics Number Real, and so does Number Decimal. Finally, Number Integer and Number Ratio both mimics Number Rational. The interesting parts of this tower is Number Integer, which corresponds to integers, Number Ratio, which is any ratio between two integers, and Number Decimal, which corresponds to decimal numbers. These are arbitrarily sized and exact. There are no floats or doubles in Ioke. There is also a potential place for Number Complex at the same layer as Number Real, although complex numbers are not currently implemented. There are also plans for implementing a unit system further down the line.
+Ioke supports arbitrarily sized numbers. It also contains a numerical tower that can be more closely explored in the reference documentation. The numerical tower is based in Number. Number Real mimics Number. Number Rational mimics Number Real, and so does Number Decimal. Finally, Number Integer and Number Ratio both mimics Number Rational. The interesting parts of this tower is Number Integer, which corresponds to integers, Number Ratio, which is any ratio between two integers, and Number Decimal, which corresponds to decimal numbers. These are arbitrarily sized and exact. There are no floats or doubles in Ioke. There is also a potential place for Number Complex at the same layer as Number Real, although complex numbers are not currently implemented. There are also plans for implementing a unit system further down the line. Number Infinity represents the singleton infinity object.
 Literal integers can be written using either decimal or hexadecimal notation. Hexadecimal notation begins with 0x or 0X and are then followed by one or more hexadecimal letters. They can be either upper or lower case. A decimal literal number is written using one or more decimal letters, but nothing else.

@@ Line 149: / Line 149: @@
 == Operator shuffling ==
-One exception to the way message handling works in Ioke is operators. All the so called operators in this section is possible to call directly in message passing position too -- but to make it possible to use them in a more natural way, the parsing step will handle them a bit differently, and then do a shuffling step that actually takes operator precedence into account. So all the common operators will generally work as you expect them too -- although I recommend adding parenthesis when something is possibly unclear.
+One exception to the way message handling works in Ioke is operators. All the so called operators in this section is possible to call directly in message passing position too -- but to make it possible to use them in a more natural way, the parsing step will handle them a bit differently, and then do a shuffling step that actually takes operator precedence into account. So all the common operators will generally work as you expect them to -- although I recommend adding parenthesis when something is possibly unclear.
 Ioke has a slightly larger amount of operators than most other languages. Most of these are currently unused, but they are certainly available for use for any purpose the programmer wants to use it for. Many adherents of other languages (Java, I'm looking at you) claim that operator overloading is evil. I don't believe that is true, seeing as how it works so well in Ruby, so Ioke instead allow you quite large freedom with regards to operators.

@@ Line 38: / Line 38: @@
 ; \b
-: Inserts the bell character, that is represented in ASCII by the decimal value 8.
+: Inserts the backspace character, that is represented in ASCII by the decimal value 8.
 ; \e
 : Inserts the character that is represented in ASCII by the decimal value 27. This value is used for sending escape values to the TTYs in some operating systems.

@@ Line 35: / Line 35: @@
 === Text ===
-A literal text in Ioke is what is generally called strings in most languages. As in most languages, text is written inside of double quotes. Any characters are valid inside of those double quotes. That includes newlines - so you can write a literal text that extends to several lines. There is no alternate syntax for text. As in most other languages, several escapes are valid inside of a text. Escapes are preceded by the backslash, and insert the character corresponding to the escape values. These escapes are:
+A literal text in Ioke is what is generally called strings in most languages. As in most languages, text is written inside of double quotes. Any characters are valid inside of those double quotes. That includes newlines - so you can write a literal text that extends to several lines. There is an alternate syntax for text when the value contains a lot of double quotes. As in most other languages, several escapes are valid inside of a text. Escapes are preceded by the backslash, and insert the character corresponding to the escape values. These escapes are:
 ; \b

@@ Line 21: / Line 21: @@
 There used to be a parsing element called operators, but these have now been included into identifiers. They are not parsed differently at all, but the operator shuffling step will handle them differently. Specifically, operators can be used in infix, including having different precedence rules. Assignment is a specific form of operator which gets its own kind of shuffling. These are both described below.
-An identifier in Ioke can be one of several things. Ioke takes the rules for Java identifiers, and adds some more to them. All Unicode letters and digits can be part of an identifier, except for the first entry. Underscores are allowed, just like in Java. Ioke also allows colons as an identifier. Exclamation mark and question mark is allowed anywhere in the identifier except for in the beginning. Identifiers can be broadly classified into identifiers and operators, where operators can be any combination of several sigils. There are also some special operators that have restructions. These are: Opening and close brackets are not allowed, except together with its counterpart, so [ is not a valid identifier, while [] is. So is {}. () is not valid either. Two or more dots is a valid identifier. A hash sign can be followed by any operator char, but isn't parsed as an identifier by itself. Slash is not an operator char, but can be used as it except in combinations that look like regular expressions. The operator chars are: +, -, *, %, &lt;, &gt;, !, ?, ~, &amp;, |, ^, $, =, @, ', ` and :. These can be combined together in any order, and any number, except for the caveats noted before. That means the available operator space is infinite, and very wide. Combinations of letters and operator characters are generally not allowed, except for the exceptions with :, ! and ?. This is to make it possible to have infix operations without spaces in some situations.
+An identifier in Ioke can be one of several things. Ioke takes the rules for Java identifiers, and adds some more to them. All Unicode letters and digits can be part of an identifier, except for the first entry. Underscores are allowed, just like in Java. Ioke also allows colons as an identifier. Exclamation mark and question mark is allowed anywhere in the identifier except for in the beginning. Identifiers can be broadly classified into identifiers and operators, where operators can be any combination of several sigils. There are also some special operators that have restrictions. These are: Opening and close brackets are not allowed, except together with its counterpart, so [ is not a valid identifier, while [] is. So is {}. () is not valid either. Two or more dots is a valid identifier. A hash sign can be followed by any operator char, but isn't parsed as an identifier by itself. Slash is not an operator char, but can be used as it except in combinations that look like regular expressions. The operator chars are: +, -, *, %, &lt;, &gt;, !, ?, ~, &amp;, |, ^, $, =, @, ', ` and :. These can be combined together in any order, and any number, except for the caveats noted before. That means the available operator space is infinite, and very wide. Combinations of letters and operator characters are generally not allowed, except for the exceptions with :, ! and ?. This is to make it possible to have infix operations without spaces in some situations.
 The two forms of brackets will get turned into a canonical form. Surrounding comma-separated message chains with square brackets is the same as calling the method [], giving it those message chains as argument. So [foo, bar, quux] is exactly the same as [](foo, bar, quux). The same is true for curly brackets.

@@ Line 95: / Line 95: @@
 #r[bla #{"foo"} bar]</source>
-The first example is an empty regular expression. The second is an expression matching the word &quot;foo&quot;. The third expression matches an &quot;f&quot; followed with one or more &quot;o&quot;. It also allows extended regular expression syntax, due to the x flag. The flags supported in Ioke are o, x, p, n, i, u, m and s. The meaning of these match the meaning of corresponding Ruby flags. Regular expressions allow most of the same escapes as Ioke text. Specifically, these escapes are supported: b, t, n, f, r, /, \ and newline. Unicode and octal escapes also work. The fourth example shows the insertion of a literal text inside of a regular expression.
+The first example is an empty regular expression. The second is an expression matching the word &quot;foo&quot;. The third expression matches an &quot;f&quot; followed with one or more &quot;o&quot;. It also allows extended regular expression syntax, due to the x flag. The flags supported in Ioke are x, i, u, m and s. The meaning of these match the meaning of corresponding Ruby flags. Regular expressions allow most of the same escapes as Ioke text. Specifically, these escapes are supported: b, t, n, f, r, /, \ and newline. Unicode and octal escapes also work. The fourth example shows the insertion of a literal text inside of a regular expression.
 Ioke regular expressions will be transformed into a call to internal:createRegexp. This message expects two Java strings, one with the actual pattern, and one with the flags.

← Older revision		Revision as of 10:59, 8 February 2009
Line 315:		Line 315:
	;; will be translated to		;; will be translated to
	another time doit(abc foo quux)</source>		another time doit(abc foo quux)</source>
−	~~=== Execution model ===~~
−
−	The way a Ioke program works is very simple. Everything executes based on two things: the the context, or the ground, and the receiver. The first message sent in each message chain will have the ground as receiver. The default ground in Ioke source files is an object called <code>Ground</code>. This object is in the mimic chain for most regular objects created in Ioke, which means that things defined at the top level will generally be available to most objects. Inside of methods and blocks, the ground will be different. Exactly in what way is defined by the type of code executing.
−
−	Every message in a chain will be sent to the receiver of that message. That receiver is the result of the last message, or the current ground if there was no previous message, or if that previous message was a terminator. So Ioke code like <code>foo bar(flux bar) quux</code> involves 5 different messages:
−
−	~~# The message <code>foo</code> is sent to <code>Ground</code>, which is the current ground and also the default receiver.~~
−	~~# The message <code>bar</code> is sent to the result of the <code>foo</code> message. The value returned will be activated.~~
−	~~# The cell <code>bar</code> contains a method in this case, and that method expects one argument, so that forces evaluation of the arguments.~~
−	~~# The message <code>flux</code> is sent to <code>Ground</code>, since it's the ground and there is no prior message inside of an argument list.~~
−	~~# The message <code>bar</code> is sent to the result of the <code>flux</code> message.~~
−	~~# The result of the <code>bar</code> message is used as the argument value given to the outside <code>bar</code> method.~~
−	~~# The message <code>quux</code> is sent to the result of the initial <code>bar</code> message.~~
−	~~# The result of the quux message is thrown away, unless this code is part of a larger piece of code.~~
−
−	~~This description generally describes what happens in the case of this code. The more general control flow is this:~~
−
−	~~# A message is encountered~~
−	~~# If the message is a symbol message, the corresponding symbol will be returned.~~
−	~~# Otherwise the name of the message will be looked up in the receiver, or in the receivers mimics.~~
−	~~# If the name is found and is not activatable, the value of that name (the cell) is returned.~~
−	~~# If the name is found and is activatable, it will be activated, with the current ground, receiver and message sent to the activatable object.~~
−	~~# If the name is not found, a second search is done for the name "pass". If a pass is found, use that instead of the name of the original message, and go back to 4.~~
−	~~# If a pass is not found, signal a [http://ioke.org/dok/kinds/Condition/Error/NoSuchCell.html <code>Condition Error NoSuchCell</code>] condition.~~
−
−	Exactly what happens when an object is activated depends on what kind of code gets activated. It's really up to the method, block or macro to handle evaluation of arguments in any way it likes - including not evaluating them. For a description of the default models available, see the chapter on [[Guide:Code\|code]].

@@ Line 70: / Line 70: @@
 Some examples:
-<pre>&quot;foo&quot;
+<source lang="ioke">"foo"
-&quot;flax \
+"flax \
-mux&quot;
+mux"
-&quot;one two #{three} \b four&quot;
+"one two #{three} \b four"
-#[you don't really  &quot;#{1+2+3}&quot; believe that?]</pre>
+#[you don't really  "#{1+2+3}" believe that?]</source>
 === Regular expressions ===
@@ Line 83: / Line 83: @@
 Ioke has very capable regular expressions. Exactly what you can do with them can be found further down in this guide. The literal syntax allows regular expressions to be embedded in code directly. The syntax for this starts with a #/ and ends with another /. The last slash can optionally be followed by some flags that change the behavior of the expression. Regular expressions can also use an alternative syntax that starts with #r[ and ends with ]. Just as with Text, regular expressions can contain interpolation. This interpolation will be transformed into regular expressions and then combined with the outer regular expression. A few examples might be in order here:
-<pre>#//
+<source lang="ioke">#//
 #r[]
@@ Line 92: / Line 92: @@
 #r[fo+]x
-#/bla #{&quot;foo&quot;} bar/
+#/bla #{"foo"} bar/
-#r[bla #{&quot;foo&quot;} bar]</pre>
+#r[bla #{"foo"} bar]</source>
 The first example is an empty regular expression. The second is an expression matching the word &quot;foo&quot;. The third expression matches an &quot;f&quot; followed with one or more &quot;o&quot;. It also allows extended regular expression syntax, due to the x flag. The flags supported in Ioke are o, x, p, n, i, u, m and s. The meaning of these match the meaning of corresponding Ruby flags. Regular expressions allow most of the same escapes as Ioke text. Specifically, these escapes are supported: b, t, n, f, r, /, \ and newline. Unicode and octal escapes also work. The fourth example shows the insertion of a literal text inside of a regular expression.
@@ Line 111: / Line 111: @@
 Some examples:
-<pre>1234444444444444444444444444444444444444235234534534
+<source lang="ioke">1234444444444444444444444444444444444444235234534534
-xFFFFF</pre>
+xFFFFF</source>
 === Decimals ===
@@ Line 125: / Line 125: @@
 Some examples:
-<pre>0.0
+<source lang="ioke">0.0
 E6
@@ Line 131: / Line 131: @@
 E-32
-.4445e10</pre>
+.4445e10</source>
 === Symbols ===
@@ Line 139: / Line 139: @@
 Some examples:
-<pre>:foo
+<source lang="ioke">:foo
 :flaxBarFoo
-:&quot;&quot;
+:""
-:&quot;mux mex mox \n ::::::::&quot;</pre>
+:"mux mex mox \n ::::::::"</source>
 == Operator shuffling ==
@@ Line 263: / Line 263: @@
 A few examples might make the translation easier to perceive. The first item is the readable form, while the second form is the canonical form:
-<pre>foo = 1 + 2
+<source lang="ioke">foo = 1 + 2
 =(foo, 1 +(2))
-Ground foo *= &quot;text&quot;
+Ground foo *= "text"
-Ground *=(foo, &quot;text&quot;)
+Ground *=(foo, "text")
 bar foo(123) = 42
@@ Line 273: / Line 273: @@
 flux++
-++(flux)</pre>
+++(flux)</source>
 These examples show some more advanced details -- specifically the fact that assignment operators generally work on &quot;places&quot;, not on names or cells. This will be more explored in the chapter on [[Guide:Assignment|assignment]]. The important thing to notice from the above examples is that for most assignments two things will be rearranged. For the unary operators only one thing will be moved.
@@ Line 306: / Line 306: @@
 As with both the binary and trinary operators, you can find and update information about inverted operators in the cell 'Message OperatorTable invertedOperators'. To make this a little less abstract, let us look at two simple examples and what they translate into:
-<pre>&quot;foo&quot; :: [1, 2, 3, 4] map(asText)
+<source lang="ioke">"foo" :: [1, 2, 3, 4] map(asText)
 ;; will be translated to
-[1, 2, 3, 4] map(asText) ::(&quot;foo&quot;)
+[1, 2, 3, 4] map(asText) ::("foo")
 ;; provided we have an inverted
@@ Line 314: / Line 314: @@
 abc foo quux doit another time
 ;; will be translated to
-another time doit(abc foo quux)</pre>
+another time doit(abc foo quux)</source>
 === Execution model ===

@@ Line 5: / Line 5: @@
 An informal BNF description of Ioke looks like this:
-<pre>    program       ::=  messageChain?
+<pre>program       ::=  messageChain?
-    messageChain  ::=  expression+
+messageChain  ::=  expression+
-    expression    ::=  message | brackets | literal | terminator
+expression    ::=  message | brackets | literal | terminator
-    literal       ::=  Text | Regexp | Number | Decimal | Unit
+literal       ::=  Text | Regexp | Number | Decimal | Unit
-    message       ::=  Identifier ( &quot;(&quot; commated? &quot;)&quot; )?
+message       ::=  Identifier ( &quot;(&quot; commated? &quot;)&quot; )?
-    commated      ::=  messageChain ( &quot;,&quot; messageChain )*
+commated      ::=  messageChain ( &quot;,&quot; messageChain )*
-    brackets      ::=  ( &quot;[&quot; commated? &quot;]&quot; ) | ( &quot;{&quot; commated? &quot;}&quot; )
+brackets      ::=  ( &quot;[&quot; commated? &quot;]&quot; ) | ( &quot;{&quot; commated? &quot;}&quot; )
-    terminator    ::=  &quot;.&quot; | &quot;\n&quot;
+terminator    ::=  &quot;.&quot; | &quot;\n&quot;
-    comment       ::=  &quot;;&quot; .* &quot;\n&quot;</pre>
+comment       ::=  &quot;;&quot; .* &quot;\n&quot;</pre>
-What isn't visible here is that all whitespace -- except for newlines -- will work only as separators of messages, and is otherwise ignored. That means that message sending does not use the dot, as in most other languages. A phrase such as &quot;foo().bar(quux(42)).baaz()&quot; would be expressed as &quot;foo() bar(quux(42)) baaz()&quot;, or more succinctly &quot;foo bar(quux(42)) baaz&quot; in Ioke.
 All the types of literals are actually turned into a message to create that literal, so the canonical form of the message chain contains no literals, just a message to create that literal. Any message can have zero or more arguments given to it. Arguments are separated with comma. If there are no arguments to a message, the parenthesis can be left off, but they need to be there if there are arguments. Mostly any combination of characters can be used as an Identifier, with some exceptions.