archive-org.com » ORG » I » IOKE.ORG

Total: 746

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Guide - IokeWiki
    Assignment Guide Control flow Guide Control flow Guide Code Guide Introspection and Reflection Guide Aspects Guide Hooks Guide Importing Guide Core kinds Guide Java integration Guide Libraries Guide What is missing Guide Future plans Current revision Retrieved from http ioke org internal wiki index php Guide Views Page Discussion View source History Personal tools 192 168 0 2 Talk for this IP Log in News About Ioke Guide Download Project

    Original URL path: https://ioke.org/wiki/index.php?title=Guide&diff=362&oldid=63 (2016-02-13)
    Open archived version from archive


  • Guide - IokeWiki
    is most important It is a mimic of Call and Call defines several important methods for manipulating the call environment These are arguments This method returns a list containing the unevaluated arguments given to this message Any kind of manipulation can be done with these arguments ground Returns the ground in which the call was initiated This is necessary to evaluate arguments in their own environment message The currently executing message This is the same as the quot currentMessage quot cell in the macro activation context evaluatedArguments Returns a list containing all arguments evaluated according to the regular rules but not handling splatting or keywords resendToMethod Allows a specific message to be resent to another method without manually copying lots of information These methods are a bit hard to understand so I ll take some examples from the implementation of Ioke and show how macros are used here pre Mixins Enumerable map macro quot takes one or two arguments if one argument is given it will be evaluated as a message chain on each element in the enumerable and then the result will be collected in a new List if two arguments are given the first one should be an unevaluated argument name which will be bound inside the scope of executing the second piece of code it s important to notice that the one argument form will establish no context while the two argument form establishes a new lexical closure quot len call arguments length result list if len 1 code call arguments first self each n result lt lt code evaluateOn call ground cell n code LexicalBlock createFrom call arguments call ground self each n result lt lt code call cell n result pre 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 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 It is a bit tricky to figure out how macros work I recommend looking at the implementations of some of the core Ioke methods macros since these use much of the functionality Blocks A lexical block allows the execution of a piece of code in the lexical context of some other code instead of in a dynamic object scope A lexical block does not have a receiver Instead it just establishes a new lexical context and executes the code in that The exact effect that has on assignments has been described earlier 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 can be invoked using the quot call quot method A block can also be activated just like a method if it is activatable The default is to use quot fn quot to create inactive blocks though since blocks are generally used to pass pieces of code around pre x fn z z println y fnx z z println x call 42 y 42 pre 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 A macro works exactly like a method in that it always has a receiver and that receiver is available inside the macro as self and In some circumstances it can be really useful to have a macro that behaves like a lexical block instead being lexical so it can use cells defined outside of the definition of the macro These macros won t have access to self or since they don t have a receiver in that way Where such a macro is called is only based on namespacing Ioke supports these kind of macros They are all mimics of the kind LexicalMacro and they are created using the method lecro A LexicalMacro is activatable by default but a non activatable lecro can be created using lecrox The lecro method takes the same arguments as macro and the only real difference is the way it handles outside cells and the receiver value A lecro also has a cell called outerScope that can be used if you need to explicitly access something in the outer name space such as call Syntax Ioke supports loads of stuff with the standard macro but sometimes these macros are a bit too low level for commonly used operations Syntax is one of those cases you can achieve with macros but you don t really want too Many features in Ioke S is implemented using syntax You can define syntax using the syntax method This returns a mimic of DefaultSyntax You can use the same kind of cells in a syntax as you can in a macro What is different with syntax is that syntax can only return one of two things The first is nil and the second is a message chain A syntax will only be executed once at every point in the message chains because after a syntax executes the first time it will replace itself with thte result of that evaluation If that evaluation returns nil syntax will just remove itself from the message chain You can use this for many things but one of the more useful things you can do is translate a high level declarative definition of something into a low level executable version That is exactly how for comprehensions are implemented The syntactic macros are fairly advanced and takes some time to grok They are incredibly useful though and they are used all over the standard library to achieve all manner of interesting things Take a look there and things should hopefully become clearer It s also a must to read the section on message chain manipulation and quoting later on to make syntax macros readable Destructuring 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 pre foo macro len call arguments length case len 1 code call arguments 0 do something with the code 2 arg1 call argAt 0 code call arguments 1 do something with the code and arg 3 arg1 call argAt 0 code call arguments 1 arg2 call argAt 2 do something with the code and args pre As you can see it s really a lot of code to see what happens here and it is very imperative in style But if I instead use dmacro which is the destructuring version of macro it looks like this pre foo dmacro code do something with the code gt arg1 code do something with the code and arg gt arg1 code gt arg2 do something with the code and args pre dmacro will automatically check the length and extract the different arguments The right arrow before the names of arg1 and arg2 marks that these should be evaluated And what is more dmacro will generate code that also generates a good condition if no argument matching works out If you give zero arguments to the first version it will fail silently The dmacro will complain immediately The dmacro destructuring syntax actually supports several more ways of ripping arguments apart You can find this information in the doks for dmacro Also there are equivalent versions of dmacro for lecro lecrox and syntax called dlecro dlecrox and dsyntax They do the same thing except they act like lecros or syntax instead 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 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 quot 1 2 3 map 2 quot In this case the call to quot quot with the argument 2 will be a message chain fragment that will be put together with a new receiver before execution To handle syntax correctly but also to generally handle manipulation of message chains it is important to know about the available methods to do this I have added quite a lot of nice stuff that makes it easy to work with message chains First messages are actually Enumerable so you can use any Enumerable methods on them The enumeration always starts at the receiver It will not proceed into arguments just following the next pointer To create a new message or message chain there are several helpful methods and operators The first method is called message and takes an evaluated name and returns a new message with that name Message from takes one argument that will not be evaluated and returns a message chain corresponding to that argument Message fromText parses text and returns the message chain for it Message wrap takes an evaluated argument and returns a message that will always return that value As will be mentioned later Message has next and prev methods that you can use to set the next and previous pointers Message also has appendArgument and prependArgument that allow you to add new arguments to the message arguments The most used versions for creating message chains are short cuts for the above Let us begin with creation Instead of Message from you can use That is a single quote mark The message after that will be unevaluated and returned as a message chain If you use a a backtick that is equivalent to Message wrap And then we have that is two single quotes after each other This message is generally called metaquote or quasiquote It works the same as except that it will find any place where is used and insert the value of evaluating the message after the and insert that into the current message chain Finally will replace a with a literal message You can add new arguments to a message by using the lt lt operator This operator returns the receiver If you want to chain together a message chain using next and prev is pretty tedious You can instead use the gt operator This will chain together the left hand side and the right hand side messages and return the right hand side message I think it is time for some examples pre create a new message with name foo x foo add two arguments to the foo message arg bar quux x lt lt arg lt lt baz what we have done so far could be done with x foo bar quux baz y blurg chain together x and y x gt y the above is equivalent to if y prev y prev next nil x next y y prev x val 42 insert the message chain in x foo bar val x the above will return the same as foo bar 42 foo bar quux baz pre 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 Introspection and reflection Ioke supports quite fancy introspection and reflection capabilities In Ioke reflection includes the ability to change data dynamically as well as introspect on it Since the message based structure of a program is available at runtime most things can be changed dynamically The internal structure of a program is also very easy to inspect All objects in Ioke have some core methods that are used to look at them Some come from Base and some come from DefaultBehavior The rest of the reflection and metaprogramming capabilities belong to the Message kind kind Should be a text that gives the full name of the kind this object is closest mimic to Except for nil true and false this will return a text that starts with a capital letter pre Foo Origin mimic Foo mimic kind println Foo Bar Origin mimic Foo Bar mimic kind println pre This code will first print quot Foo quot and then print quot Foo Bar quot since an object assigned to a cell with a capital initial letter will get a new kind value kind Takes one text argument and returns true if the object has that kind anywhere in its mimic chain pre Foo Origin mimic foo Foo mimic foo kind quot foo quot false foo kind quot Foo quot true foo kind quot Text quot false foo kind quot Origin quot true foo kind quot Ground quot true foo kind quot DefaultBehavior quot true foo kind quot Base quot true pre As you can see in this example quot kind quot can return true for several different texts notice When looking at objects there are two ways to get information about them notice and inspect If you want a brief description of an object where it s important that the description doesn t take up much space notice should be used If an exhaustive description is needed inspect should be used instead For some objects these both return the same thing but for Origin mimics the difference is large pre Foo Origin mimic Foo x quot blarg quot Foo y 42 Foo notice Foo 0x7CBDE6 pre The default notice for Origin mimics will combine the kind and the unique hex id for the object and create a text of that The quot notice quot method should be overridden to provide better information in most cases inspect In contrast to notice inspect is used to get exhaustive information If a composite object is asked for its inspect a quite large dump of information will often be shown For a new object the output will be smaller but usually still larger than the notice for it pre Foo Origin mimic Foo x quot blarg quot Foo y 42 Foo inspect println pre This will print pre Foo 0x7CBDE6 kind quot Foo quot x quot blarg quot y 42 pre If another representation makes more sense for inspection quot inspect quot should definitely be overridden by custom objects uniqueHexId This method is used to return a text that contains a unique hex identity for an object This text is guaranteed to be unique within a virtual machine for any object and is the mechanism that quot inspect quot and quot notice quot uses cellSummary Calling quot inspect quot on any Origin mimic will dispatch to quot cellSummary quot which displays all the cell information about a specific object cell The quot cell quot method can be used for two different things The first one is to get access to a value without activating it and the second is to get access to a cell based on a name that you don t know at the time you re writing the program The quot cell quot method takes one argument that is the name of the cell to fetch The fetching works the same as regular cell lookup except that activation doesn t happen This means that a condition will still be signalled if you try to get something that doesn t exist pre x 42 cell x 42 x method cell x the method object name foo cell name the value of foo pre cell Just as with quot cell quot quot cell quot can be used to set cells that you don t know the name of at the time of writing the program As discussed in the chapter on assignment cell can also be used to set cells that can t be set in the regular way due to naming strangeness cell If you re not sure if a cell exists using quot cell quot is the way to find out Give it a name and it returns true or false depending on if that cell exists cellNames If you want to get the names of all the cells an object contains you can get that with cellNames By default cellNames will only return the names of cells that belong to the receiver but if an argument of true is sent to the call the resulting list will contain the names of all cells of all mimics too pre x Origin mimic x f 42 x cellNames return f x cellNames true return a long list including f pre cells Just like cellNames return the names of all the cells the quot cells quot method will return a Dict of all the cells with their values And just like cellNames cells take an optional boolean argument on whether to include the cells of mimics too pre x Origin mimic x f 42 x cells return f 42 x cells true return a large dict including f 42 pre mimics Returns a list of all direct mimics of the receiver mimics Takes one object as argument and returns true or false depending on if the argument is anywhere in the receiving objects mimic chain message Takes one symbol argument and creates a new Message mimic with that argument as its name Message code Returns a text that describes the code this message chain represents It will hide some of the internal shuffling but operators will be displayed using canonical form Message formattedCode Returns a text that is formatted and indented in a canonical way This method is used to generate the documentation code for DokGen among other things Message evalArgAt Takes the index of the argument to evaluate and the ground to evaluate it on returns the result of evaluating the argument Message fromText Takes one text argument that should contain Ioke code and returns the parsed message chain from that code without evaluating it Message doText Takes one text argument that should contain Ioke code and returns the result of evaluating that code in the current context Message filename Returns the filename where the receiving message was defined Message line Returns the line number where the receiving message was defined Message position Returns the position in the line where the receiving message was defined Message name Returns the name of the message The name of the message is what you generally talk about when saying you send a message It can also be called the selector in other languages Message name Update the message with a new name From this point on the message will only have that name so doing this on a message that is part of an existing message chain will change the behavior of that code pre msg Message fromText quot 2 1 quot msg next name quot quot msg code quot 2 1 quot pre Message prev Returns the prev pointer of this message or nil if no prev pointer exists Message prev Sets the prev pointer of a message The new value should be either nil or another message Message next Returns the next pointer of this message or nil if no next pointer exists Message next Sets the next pointer of a message The new value should be either nil or another message Message sendTo Sends a message to an object It s important to realize that sendTo will not evaluate the whole message chain it will only send one message with arguments to an object Message keyword Returns true if this message is a keyword message and false otherwise There are many more methods that can be used to do interesting introspection and reflection in Ioke The reference documentation includes them all Most of the interesting stuff can be found on the Message kind send In many cases you want to activate something activatable in a cell with a specific receiver You can do this using send You can send messages to most objects Send takes one argument that should evaluate to the name of the message to send and then sends along all other arguments given to send to the new message These arguments will remain unevaluated and will be evaluated at the leisure of the final method activated Aspects In many circumstances you might want to do several different things in a specific method That generally goes against good software engineering that says every piece of code should only have one responsibility Aspect oriented programming tackles this by allowing you to slice code along a different dimension compared to the regular object oriented paradigm Ioke has a small version of this that allow you to add advice to cells This advice can be before after or around All of them will get access to the arguments given in the original message but after advice also gets access to the value returned from the main cell Finally around advice also gets the responsibility to invoke the original cell so an around advice could choose to not invoke it at all or it could invoke it with different arguments or maybe invoke it several times Ioke currently only allows you to add or remove advice To be able to remove advice you need to name it when adding it Unnamed advice can not be removed Advice can be wrapped It will be applied in an outside in approach where the most recently added advice will execute first The return value of before and after advice doesn t matter but the return value of around advice will be interpreted as the new return value of the message send To manipulate advice in Ioke you need to describe what to manipulate This description will return a Pointcut that can then be used to inject advice at that point Pointcuts can be defined in several ways The easiest is to define it in terms of a cell name Using this approach is the only way to define advice for non existent cells To create a Pointcut call before after or around on the receiver where the Pointcut should belong The arguments specify what should be matched by the pointcut You can see some examples of pointcuts here pre matches cells foo and bar Text before foo bar X Origin mimic will not match anything X around matching anyFromSelf X foo 123 will now match foo X around matching anyFromSelf any cell name matching the regexp X after matching foo matches any at all except foo X before matching any except foo matches any at all except anything that matches foo X before matching any except foo use a block for matching X around matching fn x x blurg use a list to provide alternatives X before matching foo bar pre As you can see from these examples the pointcuts can be fairly advanced and specific in what they match The option to send in a block makes it possible to check any property while matching OK once you have a Pointcut there are three different methods you can call These are lt lt add and remove The first one adds an unnamed advice the second adds a named advice and the third one removes a named advice Advice is any object that can be activated or called so a method a block a macro or a syntax is fine It s time to see what it looks like to add advice Before advice is the easiest kind The important thing to remember is that the code will get the same arguments as the original call which means it will also signal an error if the arguments doesn t match pre X before foo lt lt method x quot got x quot println X before matching anyFromSelf lt lt macro quot called call message name quot println pre This code doesn t do anything strange at all Next up we have after advice The only difference here is that after advice automatically gets a cell that is set to adviceResult that can used inside the method pre X after foo lt lt method args quot foo resulted in aspectResult quot println pre Remember that the result value of before and after advice doesn t count It is thrown away But these methods can still affect things by side effects They can also be used for validation A condition signalled inside of an advice would have the same effect as if done in the method itself namely interrupting the flow of control The final advice is around advice These are different in two ways First they get access to a cell called aspectCall which can be used to invoke the real cell and the next chain of advice of course The second difference is that the result of the around advice will be the return value from the cell So you can imagine the around advice executing instead of the original code If you forget to invoke it the original cell won t be invoked at all pre X around non existant lt lt method 42 X around foo lt lt macro arg1 arg2 quot before quot println res aspectResult arg2 arg1 quot got res quot println 42 pre The first piece of code show that you can actually use an around advice around something that doesn t exist But if you do call aspectCall inside of it that will generate a NoSuchCell condition of course In the second example we first log some information then invoke the original code with switched argument order saves away the result prints the result and finally returns 42 There you can see most of the things that can be done inside of an around macro The aspect system in Ioke is implemented in Ioke itself and is fairly small at the moment The guiding principle behind it is that it shouldn t have an impact on code that doesn t use it It is a highly useful feature that makes it possible to decompose code substantially As an example of a common place for aspect usage is initialization This is defined as an around advice that looks like this pre Origin around mimic lt lt method rest krest newMimic aspectCall if newMimic cell initialize newMimic initialize rest krest newMimic pre Note first that the around advice takes any kind of arguments but doesn t send them along to mimic Instead it checks if there is an initialize cell and in that case invokes it with the arguments given to the mimic call It finally returns the original result Importing To import new code into Ioke the method quot use quot should be used The terminology is that you give quot use quot a name of a module to include and if that module has already been included it will not be evaluated again If it has not been included quot use quot will try to find the module using several different heuristics It will add an quot ik quot to the name and try to look up a file of that name but it will also try to look it up without a quot ik quot if a full file name has been given Several different places will be searched and the exact order and what will be searched can be found by calling the quot System loadPath quot method This will return a list of all the places to search for modules This list can be modified to add more directories to the load path If a module of the specified name can t be found a condition will be signalled Core kinds Ioke obviously contains lots of different data types but there are some that are much more important than others In this chapter I ll take a look at these and talk about how to work with them correctly Conditions One of the major parts of Ioke is the condition system Unlike most other programming languages Ioke doesn t have exceptions Instead it has conditions where errors are a specific kind of condition The condition system comprises several different things Specifically the condition system uses the kinds Condition Restart Handler and Rescue Restarts are mostly orthogonal to the rest of the system The way the condition system works is this When something happens a program can elect to signal a condition This can be done using quot signal quot quot warn quot or quot error quot Both quot warn quot and quot error quot uses quot signal quot under the covers but do some other things as well A condition will always mimic Condition Each of these three methods can be called in three different ways First you can call them with a text argument In that case the signalled condition will be the default for that type The default for quot signal quot is Condition Default The default for quot warn quot is Condition Warning Default and the default for quot error quot is Condition Error Default A new mimic of the default condition will be created and a cell called text will be set to the text argument The second variation is to give an instance of an existing condition to one of the methods In that case that condition will be signalled unmodified Finally the third version gives a condition mimic and one or more keyword arguments with data to set on that condition In that case a mimic of the condition will be created and then cells with data set based on the arguments If a signal is not handled nothing happens If a warning is not handled a message will be printed with the text of that warning If an error is not handled the debugger will be invoked if a debugger is available Otherwise the program will be terminated A Rescue allows conditions to unwind the stack to the place where the rescue is established Combining rescues and conditions looks a lot like regular exception handling in other programming languages A Handler on the other hand will run code in the dynamic context of the place where the condition was signalled A handler can invoke restarts to handle an error state at the place it happened and as such doesn t have to actually unwind the stack anywhere Any number of handlers can run the last handler to run will be either the last handler the handler that activates a restart or the last handler before a valid rescue for that condition A restart is a way to allow ways of getting back to a valid state Take the example of referring to a cell that doesn t exist Before signalling a condition Ioke will set up restarts so you can provide a value to use in the case a cell doesn t exist This restart will use that new value and continue execution at the point where it would otherwise have failed A restart can have a name If it doesn t have a name it can only be used interactively You can use findRestart to get hold of the closest restart with a given name You can invoke a given restart with invokeRestart which takes either the name of a restart or a restart mimic Finally you can get all available restarts using availableRestarts Both handlers rescues and restarts are established inside a call to the bind macro All arguments to this macro need to be either handlers rescues or restarts except for the last argument which should be the code to execute You create a new handler by calling the method quot handle quot You create a new rescue by calling the method quot rescue quot You create a new restart by calling the method quot restart quot These all take funky arguments so refer to the reference to better understand how they work This small example doesn t necessarily show the power of conditions but it can give an idea about how it works pre to handle any problem bind rescue fn c nil do nothing in the rescue error quot This is bad quot to print all conditions happening but not do anything bind handle fn c c println signal quot something quot signal quot something more quot warn quot A warning quot rescue either of two conditions C1 Condition Error mimic C2 Condition Error mimic bind rescue C1 C2 fn c quot got an error c quot println error C1 invoke a restart when no such cell is signaled bind handle Condition Error NoSuchCell fn c invokeRestart useValue 42 blarg println will print 42 establish a restart bind restart something fn args args println invokeRestart something 1 2 3 pre The code above shows several different things you can do with the condition system It is a very powerful system so I recommend trying to understand it It lies at the core of many things in Ioke and some parts will not make sense without a deep understanding of conditions For more information on what such a system is capable of look for documentation about the Common Lisp condition system which has been a heavy influence on Ioke Also the debugger in IIk uses the condition system to implement its functionality There are

    Original URL path: https://ioke.org/wiki/index.php?title=Guide&diff=63&oldid=62 (2016-02-13)
    Open archived version from archive

  • Guide - IokeWiki
    the method that is used for matching The expression takes one value then one or more conditionals followed by actions and then an optional default part Once something matches no more conditionals will be executed The conditional part should not be a complete conditional statement Instead it should return something that implements a fitting So a small example follows A thing that you very often want to do is to check one value against several different conditions The case expression allows this to be done succinctly The core to the case expression is the method that is used for matching The expression takes one value then one or more conditionals followed by actions and then an optional default part Once something matches no more conditionals will be executed The conditional part should not be a complete conditional statement Instead it should return something that implements a fitting So a small example follows otherwise otherwise Returns a matcher that always returns true This is useful to make the default argument read better Returns a matcher that always returns true This is useful to make the default argument read better Iteration Iteration Ioke supports most of the expected control flow operations for iteration The one thing that is missing is the for loop Since the for loop encourages low level stepping and canbe replaced by other kinds of operations I don t see any reason in having it in Ioke In fact the for statement in Ruby is generally considered bad form too And if someone really wants a for loop it s really easy to implement For now I m reserving the name if I would like to add comprehensions at some point Ioke supports most of the expected control flow operations for iteration The one thing that is missing is the for loop Since the for loop encourages low level stepping and canbe replaced by other kinds of operations I don t see any reason in having it in Ioke In fact the for statement in Ruby is generally considered bad form too And if someone really wants a for loop it s really easy to implement For now I m reserving the name if I would like to add comprehensions at some point loop loop For creating infinte loops the quot loop quot method is the thing It will just take a piece of code and execute it over and over again until some non local flow control rips the execution up Using it is as simple as calling it For creating infinte loops the quot loop quot method is the thing It will just take a piece of code and execute it over and over again until some non local flow control rips the execution up Using it is as simple as calling it The first example will loop forever printing hello over and over again The second example will increment a variable until it s larger then 10 and then it will break out of the loop

    Original URL path: https://ioke.org/wiki/index.php?title=Guide&diff=62&oldid=60 (2016-02-13)
    Open archived version from archive

  • Guide - IokeWiki
    foo 42 quot That also means that assignment is just a regular method call and can be overridden or removed just like any other method That is exactly how both lexical context and local method context make it possible to have different logic here This is true for all assignment operators All assignment operators take as their first argument the place to assign to This place will be unevaluated Only the second argument to an assignment will be evaluated In most cases a place is the same thing as a cell name but it doesn t have to be Let s look at the case of assigning a cell with a strange name Say we want to assign the cell with the no name We can do it like this pre cell quot quot 42 pre What happens here is a bit subtle Since the left hand side of the assignment takes arguments the quot quot method figures out that the assignment is not to a simple cell name but to a place The parsing step will change quot cell quot quot 42 quot into quot cell quot quot 42 quot Notice here that the argument comes along into the specification of the place When this happens the assignment operator will not try to create or assign a cell instead it will in this case call the method cell So quot cell quot quot 42 quot will ultimately end up being the same as quot cell quot quot 42 quot This way of transforming the name will work the same for all cases so you can have as many arguments as you want to the place on the left hand side The equals sign will be added to the method name and a message will be sent to that instead This makes assignment of places highly flexible and the only thing you need to do is implement methods with the right names This feature is used extensively in Lists and Dicts to make it easy to assign to specific indexes So say we have a list called x Then this code quot x 13 42 quot will be transformed into quot x 13 42 quot which will in turn be transformed into quot x 13 42 quot Ioke lists also has an at method so you can do quot x at 13 42 quot which will call at of course The second transformation that might happen is that if you try to assign a cell that has an assigner you will call that assigner instead of actually assigning a cell So for example if you do quot foo documentation 42 quot this will not actually create or assign the cell quot documentation quot Instead it will find that Base has a cell called quot documentation quot and instead send that message So the prior code would actually be equivalent to quot foo documentation 42 quot All of these assignment processes together make it really easy to take control over assignment

    Original URL path: https://ioke.org/wiki/index.php?title=Guide&diff=60&oldid=58 (2016-02-13)
    Open archived version from archive

  • Guide - IokeWiki
    place named to that value Refer to http SERVERNAME assignment Assignment for more information about it Compares this object against the argument Returns true if they are the same otherwise false cell Takes one argument that should be the name of a cell that exists and returns the value of the cell unactivated cell Sets a cell to a specific value Used to set cells that can t be set using the regular assignment model Refer to http SERVERNAME assignment Assignment for more information about it cell Takes one argument that should be the name of a cell to check if it exists in this objects mimic chain cellNames Returns a List containing the names of all cells this object contains cells Returns a Dict with all cells this object contains The key is the name and the value is the cell value cellOwner Returns the closest mimic that has a cell with the name given as argument to the message A condition will be signalled if you try to find the owner of a cell that doesn t exist in this mimic tree This method will only return the closest cell owner for the named cell It will not use quot pass quot so it s the responsibility of pass implementers to make it return a correct result for those names cellOwner Takes the name of a cell and returns true if the receiver of the message defines a cell by that name otherwise false Note that there can be more than one cell owner in a message chain This just returns true if the current receiver is the closest one removeCell Removes the named cell from the current object This means that if the current cell shadowed cells in mimics those can be called again It only removes a cell if the receiver is the owner of that cell Otherwise it is an error to call this method undefineCell Makes it impossible to find a cell from the receiver In all ways it looks like this cell doesn t exist in the mimic chain at all even if mimics define several implementations of it The use of undefining can make an object conceptually totally clean from cells although it might be hard to use the objec after that An interesting side effect of the way these methods work is that removeCell can be used to remove the undefine So if you call removeCell with a cell name and a receiver that has been called with undefine earlier that undefine status will be removed and access to mimic versions of the cell will be possible again Look at the specs for a better understanding documentation Returns the documentation text for this object or nil if no documentation exists for it documentation Sets the documentation text for this object mimic Returns a newly created object that has the receiver as mimic This is the magic way of creation new objects in Ioke It is also the ONLY way to do

    Original URL path: https://ioke.org/wiki/index.php?title=Guide&diff=58&oldid=56 (2016-02-13)
    Open archived version from archive

  • Guide - IokeWiki
    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 quot foo bar flux bar quux quot involves 5 different messages The message quot foo quot is sent to Ground which is the current ground and also the default receiver The message quot bar quot is sent to the result of the quot foo quot message The value returned will be activated The cell quot bar quot contains a method in this case and that method expects one argument so that forces evaluation of the arguments The message quot flux quot is sent to Ground since it s the ground and there is no prior message inside of an argument list The message quot bar quot is sent to the result of the quot flux quot message The result of the quot bar quot message is used as the argument value given to the outside quot bar quot method The message quot quux quot is sent to the result of the initial quot bar quot 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

    Original URL path: https://ioke.org/wiki/index.php?title=Guide&diff=56&oldid=54 (2016-02-13)
    Open archived version from archive

  • Guide - IokeWiki
    codepoint corresponding to the hexadecimal value of the four characters following the quot u quot All four hexadecimal characters need to be specified 7 12 316 Inserts the Unicode codepoint corresponding to the octal value of the one two or three octal characters The maximum value allowed is 377 and the minimum is obviously 0 Ioke also supports an alternative text syntax that can be used when the text in question contains many scare quotes The alternative syntax starts with and ends with A right bracket will have to be escaped but scare quotes doesn t have to be The parsing of text will generate a message with name quot internal createText quot This message will get one argument that is the raw Java String corresponding to the text Ioke allows automatic interpolation of arbitrary values in the same manner as Ruby It uses the same syntax for this which is the syntax inside a text These can be nested in any way The elements will be parsed and sent as arguments to the message with name quot internal concatenateText quot So an Ioke text such as quot foo bar flux will 1 2 quot will generate the message internal concatenateText quot foo bar quot flux quot will quot 1 2 quot quot As you can see there is a small amount of waste in the way this is generated but the simple model makes it easy to understand It s not guaranteed that this will remain the same although the message will definitely remain Some examples pre quot foo quot quot flax mux quot quot one two three b four quot you don t really quot 1 2 3 quot believe that pre Regular expressions 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 r foo r foo fo x r fo x bla quot foo quot bar r bla quot foo quot bar pre 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 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 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 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 There is no literal to create ratios these can only be created by division of integers Negative numbers have no literal syntax but preceding a number with a minus sign will call the message on the number and generate the negative value A literal integer will be transformed into a call to internal createNumber which takes one native Java String from which to create the number Some examples pre 1234444444444444444444444444444444444444235234534534 0 0xFFFFF pre Decimals Literal decimal values can be written either using exponential notation or using a decimal dot A decimal dot notation can be combined with exponential notation Exponential notation starts with a number or a decimal number followed by lower or upper case E followed by an optional sign and then followed by one or more decimal letters A literal decimal will be transformed into a call to internal createDecimal which takes one native Java String from which to create the decimal Some examples pre 0 0 1E6 1E 32 23 4445e10 pre Symbols Symbols aren t exactly syntax but they aren t exactly messages either Or rather they are messages that will evaluate to the symbol that represent themselves Symbol is a kind in Ioke There are two kinds of symbols the first one is simple symbols that can be parsed as is The second is symbols that can t be parsed as is Symbols are preceded by a colon and then directly followed by the symbol text If it can t be parsed correctly the value should be surrounded by

    Original URL path: https://ioke.org/wiki/index.php?title=Guide&diff=54&oldid=52 (2016-02-13)
    Open archived version from archive

  • Guide - IokeWiki
    address Instead Ioke is a remodeling of the core concepts and ideas embodied in other programming languages Are still Lisp and Smalltalk the most powerful languages around or are there ways of providing more expressiveness without sacrificing understandability Is there a way to combine all the lessons learned from languages like Ruby and Python and patch them back into a Lisp and Smalltalk core Is it possible to do this while taking some of the benefits of Io Can a language be both small regular homoiconic reflective and easy to understand I hope that Ioke is just that Simplicity doesn t mean lack of power Small simple orthogonal functionality can be more powerful than larger complicated abstractions that doesn t fit together Io explicitly states that the goal of the language is to refocus attention on expressiveness and with Ioke I want to take that philosophy one step further It s important to realize that an experiment like this doesn t necessarily have to mean the language can t be used for real projects By wedding Ioke to the Java Virtual Machine I make it easy to get access to good libraries and existing implementations on most platforms In that way Ioke can be used to create real systems even though the ecosystem will initially be very small And I think that this is necessary How can you know if a language really is worthwhile or not if you can t use it as a general purpose programming language The Java platform makes this possible Getting started Ioke is very easy to get started with The first step is to download a package Which one you choose depends on what platform you re on and whether you want to build Ioke yourself or just start using it This guide will only cover using a prebuilt version Go to the download page at http ioke org download html http ioke org download html and download one of the distributions At the time of writing the full version of Ioke is Ioke S ikj 0 2 0 Choose the latest download in the 0 2 series for this document to apply In later revisions of the document any major change will be noted inline Once you have downloaded the distribution you need to unpack it somewhere and finally add the bin directory to your PATH environment variable There is also a jar download that can be run directly If you choose this option you don t get the benefits of having a home for Ioke which in some cases be inconvenient Ioke can be run directly from the jar file though Running scripts To run an Ioke script you can generally just use the ioke command pre ioke helloWorld ik Hello world pre You can also execute snippets of code on the command line using the e argument to the ioke command You can have several of these one the same line too pre ioke e quot Hello world quot println e

    Original URL path: https://ioke.org/wiki/index.php?title=Guide&diff=52&oldid=51 (2016-02-13)
    Open archived version from archive



  •