Guide:Code - Revision history

Admin: /* Blocks */

2012-10-05T14:39:47Z

‎Blocks

Admin: Reverted edits by Icotime (Talk) to last version by Olabini

2010-11-24T14:41:40Z

Reverted edits by Icotime (Talk) to last version by Olabini

Show changes

spambot_Icotime at 09:41, 24 November 2010

2010-11-24T09:41:35Z

Show changes

Olabini: /* Code */

2009-12-22T18:54:08Z

‎Code

spambot_Tumble: /* Message chains */

2009-04-17T09:02:09Z

‎Message chains

spambot_Tumble: /* Message chains */

2009-04-17T09:01:47Z

‎Message chains

spambot_Tumble: /* Destructuring */

2009-04-17T08:59:50Z

‎Destructuring

spambot_Tumble: /* Macros */

2009-04-13T02:13:22Z

‎Macros

spambot_Tumble: /* Macros */

2009-04-13T02:08:17Z

‎Macros

spambot_Tumble: /* Macros */

2009-04-13T02:07:14Z

‎Macros

@@ Line 160: / Line 160: @@
 A lexical block can be created using either the &quot;fn&quot; or the &quot;fnx&quot; methods of DefaultBehavior. The main difference between the two is that a block created with &quot;fnx&quot; will be activatable, while something created with &quot;fn&quot; will not. Lexical blocks handle arguments exactly the same way as methods, so a lexical block can take optional arguments, keyword arguments, rest arguments and so on. Both &quot;fn&quot; and &quot;fnx&quot; also take optional documentation text.
-A block created with the &quot;fn&quot; method can be invoked using the &quot;call&quot; method of the kind [http://ioke.org/dok/kinds/LexicalBlock.html <code>LexicalBlock</code>].
+A block created with the &quot;fn&quot; method can be invoked using the &quot;call&quot; method of the kind [http://ioke.org/dok/release/kinds/LexicalBlock.html <code>LexicalBlock</code>].
 <source lang="ioke">

@@ Line 3: / Line 3: @@
 Many of the things you do in Ioke will directly manipulate code. Since the messages that make up code is really easy to get hold of, this manipulation comes easy too. Ioke takes the Lisp philosophy of &quot;code is data&quot; to heart. The basic unit of a piece of code is a Message. A Message has a name, a next and prev pointer, and any number of arguments. When you manipulate a message, the argument list will contain messages too - and if the next or prev pointers are not nil, they will point to other messages. It serves well to remember that except for the message itself, all code will be evaluated in the context of a receiver and a ground. The ground is necessary because arguments to be evaluated need to be run in some specific context, even though the current receiver is not the same as the ground.
-The current types of code can be divided into three different categories. These are methods, macros and blocks. Native methods are all of the kind JavaMethod, but can have any kind of semantics - including semantics that look like macros. Most native methods do have the same semantics as regular methods, however.
+The current types of code can be divided into three different categories. These are methods, macros and blocks. Native methods are all of the kind NativeMethod, but can have any kind of semantics - including semantics that look like macros. Most native methods do have the same semantics as regular methods, however.
 == Methods ==
@@ Line 183: / Line 183: @@
 A lexical block is a regular kind of object that can be assigned to any cell, just like other objects. Lexical blocks mimic LexicalBlock, and blocks don't have names. In contrast to methods and macros, no extra cells will be added to the activation context for a lexical block.
 == Lecros ==
@@ Line 285: / Line 298: @@
 '(foo bar(42) foo(bar quux, baz))</source>
 To understand these operators, you need to have a clear understanding of how the internals of message chains work. Once that clicks, these should be fairly straight forward to understand.

@@ Line 240: / Line 240: @@
 == Message chains ==
-In many cases a macro will take code that is not wrapped up inside of a method, macro or block. These pieces of code are called message chains, since their representation will be to a raw Message mimic. The chains are quite flexible, since they can be taken apart, modified and put together again. They can also be unevaluated and used as data definitions of some kind. That's how the argument handling to methods are implemented, for example. Since the call to &quot;method&quot; can be seen as a regular call to a macro, the argument descriptions are actually just unevaluated message chains that are picked apart to tease out the argument names. The same technique is applicable in any macro usage.
+In many cases a macro will take code that is not wrapped up inside of a method, macro or block. These pieces of code are called message chains, since their representation will be a raw Message mimic. The chains are quite flexible, since they can be taken apart, modified and put together again. They can also be unevaluated and used as data definitions of some kind. That's how the argument handling to methods are implemented, for example. Since the call to &quot;method&quot; can be seen as a regular call to a macro, the argument descriptions are actually just unevaluated message chains that are picked apart to tease out the argument names. The same technique is applicable in any macro usage.
 The term message chain fragment is also used to specifically mean a message chain that is meant to be put together with something and evaluated. Picture a daisy chain that gets added at the end of another chain and then executed. That's what happens if you execute something like <code>[1, 2, 3] map(*2)</code>. In this case the call to <code>*</code> with the argument 2 will be a message chain fragment that will be put together with a new receiver before execution.

@@ Line 240: / Line 240: @@
 == Message chains ==
-In many cases a macro will take code that is not wrapped up inside of a method, macro or block. These pieces of code is called message chains, since their representation will be to a raw Message mimic. The chains are quite flexible, since they can be taken apart, modified and put together again. They can also be unevaluated and used as data definitions of some kind. That's how the argument handling to methods are implemented, for example. Since the call to &quot;method&quot; can be seen as a regular call to a macro, the argument descriptions are actually just unevaluated message chains that are picked apart to tease out the argument names. The same technique is applicable in any macro usage.
+In many cases a macro will take code that is not wrapped up inside of a method, macro or block. These pieces of code are called message chains, since their representation will be to a raw Message mimic. The chains are quite flexible, since they can be taken apart, modified and put together again. They can also be unevaluated and used as data definitions of some kind. That's how the argument handling to methods are implemented, for example. Since the call to &quot;method&quot; can be seen as a regular call to a macro, the argument descriptions are actually just unevaluated message chains that are picked apart to tease out the argument names. The same technique is applicable in any macro usage.
 The term message chain fragment is also used to specifically mean a message chain that is meant to be put together with something and evaluated. Picture a daisy chain that gets added at the end of another chain and then executed. That's what happens if you execute something like <code>[1, 2, 3] map(*2)</code>. In this case the call to <code>*</code> with the argument 2 will be a message chain fragment that will be put together with a new receiver before execution.

@@ Line 204: / Line 204: @@
 A common problem with macros is that you want to take several different combinations of arguments, and do different things depending on how many you get. Say you might want to take one code argument, but also two optional arguments that should be evaluated. All of that code turns out to be highly repetetive, so Ioke contains a collection of syntax macros that make it easier to write these things. These are collectively called destructuring syntax.
-Let us say we have a macro that either [code], [evaluatedArgument, code], or [evaluatedArgument, code, evaluatedArgument]. The stuff that should happen is totally different for each of these cases. With a regular macro the code would look something like this:
+Let us say we have a macro that can be called with any of three types of argument list: [code], [evaluatedArgument, code], or [evaluatedArgument, code, evaluatedArgument]. The stuff that should happen is totally different for each of these cases. With a regular macro the code would look something like this:
 <source lang="ioke">foo = macro(

@@ Line 148: / Line 148: @@
 The code above implements map, one of the methods from Enumerable. The map method allows one collection to be mapped in a predefined way into something else. It can take either one or two arguments. If one argument is given, that is a message chain to apply, and then collect the results. If two arguments are given, the first is the argument name to use, and the second is the code to execute for each entry.
-The first step is to figure out how many arguments have been given. This is done by checking the length of the &quot;call arguments&quot; cell. If we have a length of one, we know that the first argument is a piece of code to apply, so we assign that argument to a cell called &quot;code&quot;. Now, &quot;code&quot; will be a mimic of Message, and Message has a method called &quot;evaluateOn&quot;, that can be used to fully evaluate a message chain. And that's exacty what we do for each element in the collection we are in. The result of evaluateOn is added to the result list. We use &quot;call ground&quot; to get the correct ground for the code to be evaluated in.
+The first step is to figure out how many arguments have been given. This is done by checking the length of the &quot;call arguments&quot; cell. If we have a length of one, we know that the first argument is a piece of code to apply, so we assign that argument to a cell called &quot;code&quot;. Now, &quot;code&quot; will be a mimic of Message, and Message has a method called &quot;evaluateOn&quot;, that can be used to fully evaluate a message chain. And that's exactly what we do for each element in the collection we are in. The result of evaluateOn is added to the result list. We use &quot;call ground&quot; to get the correct ground for the code to be evaluated in.
 If we get two arguments, it's possible to take a shortcut and generate a lexical block from those arguments, and then use that. So we call &quot;LexicalBlock createFrom&quot; and send in the arguments and the ground, and then call that piece of code once for each element in the collection.

@@ Line 110: / Line 110: @@
 The main difference between a macro and a method in Ioke is that the arguments to a macro are not evaluated before they are sent to the macro. That means you have to use macros to send raw message chains in an invocation. In most languages, this kind of feature is generally called call-by-name. When a macro gets called, it will get access to a cell called &quot;call&quot; which is a mimic of the kind Call. This gives access to information about the call and makes it possible to evaluate the code sent as arguments, check how many arguments are supplied, and so on.
-A macro is created using the &quot;macro&quot; cell on DefaultBehavior. This will return a mimic of DefaultMacro. Since macros can't define arguments, it's a bit easier to describe than methods, but the things that can be done with macros is also a bit more interesting than what can be achieved with methods. One important thing to keep in mind is that most macros can not receive splatted arguments. In most cases keyword arguments aren't available either - but they could be faked if needed. Macros should generally be used to implement control structures and things that need to manipulate code in different ways.
+A macro is created using the &quot;macro&quot; cell on DefaultBehavior. This will return a mimic of DefaultMacro. Since macros can't define arguments, it's a bit easier to describe than methods, but the things that can be done with macros are also a bit more interesting than what can be achieved with methods. One important thing to keep in mind is that most macros can not receive splatted arguments. In most cases keyword arguments aren't available either - but they could be faked if needed. Macros should generally be used to implement control structures and things that need to manipulate code in different ways.
 Just like a method, a macro gets evaluated on a specific receiver. It also gets the same kind of method activation context, but the contents of it is a bit different. Specifically, the context for a macro contains cells named &quot;self&quot;, &quot;@&quot;, &quot;currentMessage&quot;, &quot;surroundingContext&quot; and &quot;call&quot;. It's the &quot;call&quot; cell that is most important. It is a mimic of Call, and Call defines several important methods for manipulating the call environment. These are:

@@ Line 108: / Line 108: @@
 == Macros ==
-The main difference between a macro and a method in Ioke is that the arguments to a macro is not evaluated before they are sent to the macro. That means you have to use macros to send raw message chains in an invocation. In most languages, this kind of feature is generally called call-by-name. When a macro gets called, it will get access to a cell called &quot;call&quot; which is a mimic of the kind Call. This gives access to information about the call and makes it possible to evaluate the code sent as arguments, check how many arguments are supplied, and so on.
+The main difference between a macro and a method in Ioke is that the arguments to a macro are not evaluated before they are sent to the macro. That means you have to use macros to send raw message chains in an invocation. In most languages, this kind of feature is generally called call-by-name. When a macro gets called, it will get access to a cell called &quot;call&quot; which is a mimic of the kind Call. This gives access to information about the call and makes it possible to evaluate the code sent as arguments, check how many arguments are supplied, and so on.
 A macro is created using the &quot;macro&quot; cell on DefaultBehavior. This will return a mimic of DefaultMacro. Since macros can't define arguments, it's a bit easier to describe than methods, but the things that can be done with macros is also a bit more interesting than what can be achieved with methods. One important thing to keep in mind is that most macros can not receive splatted arguments. In most cases keyword arguments aren't available either - but they could be faked if needed. Macros should generally be used to implement control structures and things that need to manipulate code in different ways.