Pitfalls

This page collect easy mistakes to do while developing Ioke code. Anything that causes unobvious failures should be listed here. Note that things on this page are not bugs - just things that might be a bit counterintuitive at first glance.

Mismatched commas

One of the most insidious problems that can show up in Ioke programs happens when you forget to add a comma at the right place - or add a comma in a place where there shouldn't be one. Remember, commas separate arguments. Nothing else. Here are some of the most common situations where a mismatched comma will cause the program to work incorrectly - but it will generally still run.

Missing comma after documentation text

When defining a method, macro or syntax with a documentation text, it is very important to remember to add a comma after the text. In most cases the only thing that happens when you forget it is that the object will not get any documentation. But if you continue the expression on the same line you will probably get a signaled condition of some kind.

An example of faulty code:

foo = method("foo is a method that does something really cool"
  42*42)

Fixed version:

foo = method("foo is a method that does something really cool",
  42*42)

The most problematic case is when you have arguments. In that case the omission of the comma will lead to incorrect code that will fail at some point:

foo = method("foo is a method that does something really cool" x,
  42*x)

When foo is called above, you will get either a Condition Error Invocation TooManyArguments, or you will get a Condition Error NoSuchCell. The solution is easy:

foo = method("foo is a method that does something really cool", x,
  42*x)

Missing comma in conditional expressions

In a case expression, all the different parts of it have to be separated by commas. It is common to use indentation to show which parts belong together, but that is not enough for the Ioke parser to figure things out. A few typical examples where this happens in case, cond, if and unless code:

if(foox === 1..3,
  x = 13
  x = :fail)

unless(foxy(42)
  "hello world!" println)

case([p1 value, p2 value],
  [:paper, :rock] win(p1),
  [:rock, :scissors] win(p1),
  [:scissors, :paper] win(p1),
  [:rock, :paper] win(p2),
  [:paper, :scissors] win(p2),
  [:scissors, :rock] win(p2),
  else draw)
    
cond(
  x>10, :foo
  x<5, :bar
  x==7, :fluxie)

Of course, in these examples it is easy to see where the missing commas should go - but in a real program it gets a bit more messy. It has happened several times during the Ioke development process that a bug like this has persisted for a while.

The above should be corrected as:

if(foox === 1..3,
  x = 13,
  x = :fail)

unless(foxy(42),
  "hello world!" println)

case([p1 value, p2 value],
  [:paper, :rock], win(p1),
  [:rock, :scissors], win(p1),
  [:scissors, :paper], win(p1),
  [:rock, :paper], win(p2),
  [:paper, :scissors], win(p2),
  [:scissors, :rock], win(p2),
  else, draw)
    
cond(
  x>10, :foo,
  x<5, :bar,
  x==7, :fluxie)

Added comma in dmacro specification

This problem is the most insidious for the simple reason that it is the opposite of the other comma-related problems. Namely, when writing a dmacro, or one of the other destructuring syntax elements, the problem is generally that you add too many commas:

x = dmacro(
 [>foo, bar],
 foo + bar evaluateOn(call ground, call ground))

The above code is wrong: there shouldn't be a comma after the square brackets. The dmacro will fail in some spectacular way because of this, but probably not when you expect it. If a dmacro fails for uncertain reasons, and debug-by-printing tells you strange things, the most common cause will be one comma too much. The above code should be:

x = dmacro(
 [>foo, bar]
 foo + bar evaluateOn(call ground, call ground))