Pitfalls - Revision history

spambot_Tumble: /* fnx is activatable but lecrox is unactivatable */ typo fixed

2009-06-13T17:20:27Z

‎fnx is activatable but lecrox is unactivatable: typo fixed

spambot_Tumble: /* The return value of around advice is used, but the return values of before and after advice is thrown away */

2009-04-17T09:33:02Z

‎The return value of around advice is used, but the return values of before and after advice is thrown away

spambot_Tumble: inconsistent use of return values from advice

2009-04-17T09:32:29Z

inconsistent use of return values from advice

spambot_Tumble: distinction between the x in fnx and the x in lecrox

2009-04-17T08:51:25Z

distinction between the x in fnx and the x in lecrox

spambot_Tumble: /* The [] operator is overloaded in List, Dict and Enumerable */

2009-04-15T02:21:47Z

‎The [] operator is overloaded in List, Dict and Enumerable

spambot_Tumble: added pitfall: The [] operator is overloaded in List, Dict and Enumerable

2009-04-15T02:21:15Z

added pitfall: The [] operator is overloaded in List, Dict and Enumerable

Cv at 20:24, 26 January 2009

2009-01-26T20:24:36Z

Cv at 20:23, 26 January 2009

2009-01-26T20:23:21Z

Cv at 20:22, 26 January 2009

2009-01-26T20:22:25Z

Olabini at 19:48, 26 January 2009

2009-01-26T19:48:49Z

@@ Line 157: / Line 157: @@
 Add an x to fn and you get the activatable version of fn.  (fn is unactivatable, with some exceptions.)
-Add an x to lecro and you get the '''un'''activatable version of lecto.  (lecro is activatable.)
+Add an x to lecro and you get the '''un'''activatable version of lecro.  (lecro is activatable.)
 == The return value of around advice is used, but the return values of before and after advice is thrown away ==

← Older revision		Revision as of 09:33, 17 April 2009
Line 161:		Line 161:
	== The return value of around advice is used, but the return values of before and after advice is thrown away ==		== The return value of around advice is used, but the return values of before and after advice is thrown away ==

−	From the guide: ''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.''	+	From the guide:
		+
		+	''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.''

← Older revision		Revision as of 09:32, 17 April 2009
Line 158:		Line 158:

	Add an x to lecro and you get the '''un'''activatable version of lecto. (lecro is activatable.)		Add an x to lecro and you get the '''un'''activatable version of lecto. (lecro is activatable.)
		+
		+	== The return value of around advice is used, but the return values of before and after advice is thrown away ==
		+
		+	From the guide: ''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.''

← Older revision		Revision as of 08:51, 17 April 2009
Line 152:		Line 152:

	to create a list in these contexts.		to create a list in these contexts.
		+
		+	== fnx is activatable but lecrox is unactivatable ==
		+
		+	Add an x to fn and you get the activatable version of fn. (fn is unactivatable, with some exceptions.)
		+
		+	Add an x to lecro and you get the '''un'''activatable version of lecto. (lecro is activatable.)

@@ Line 142: / Line 142: @@
 <source lang="ioke">
-list()
+list(...)
 </source>
@@ Line 148: / Line 148: @@
 <source lang="ioke">
-[]
+[...]
 </source>
 to create a list in these contexts.

← Older revision		Revision as of 02:21, 15 April 2009
Line 108:		Line 108:
	foo + bar evaluateOn(call ground, call ground))		foo + bar evaluateOn(call ground, call ground))
	</source>		</source>
		+
		+	== The [] operator is overloaded in List, Dict and Enumerable ==
		+
		+	In most places, the expression
		+
		+	<source lang="ioke">
		+	[...]
		+	</source>
		+
		+	will create a list: for example,
		+
		+	<source lang="ioke">
		+	[]
		+	</source>
		+
		+	will create a new, empty list.
		+
		+	However, in a method defined on a List, Dict or Enumerable, that code will raise a condition. So, for example:
		+
		+	<source lang="ioke">
		+	List test = method(r = [])
		+	</source>
		+
		+	raises the condition "didn't get enough arguments: 1 missing, to '[]' (Condition Error Invocation TooFewArguments)". This is because in most contexts the [] syntax is used for list creation but in the context of a List, Dict or Enumerable it's used for list lookup instead, allowing us to write things like
		+
		+	<source lang="ioke">
		+	r = [1, 2, 3] ; list creation
		+	if(r[1] == 2, ; list lookup
		+	"This is true" println)
		+	</source>
		+
		+	The solution is to use
		+
		+	<source lang="ioke">
		+	list()
		+	</source>
		+
		+	instead of
		+
		+	<source lang="ioke">
		+	[]
		+	</source>
		+
		+	to create a list in these contexts.

@@ Line 1: / Line 1: @@
-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.
+This page collect easy mistakes to make 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 ==
@@ Line 30: / Line 30: @@
 </source>
-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:
+When <code>foo</code> is called above, you will get either a <code>Condition Error Invocation TooManyArguments</code>, or you will get a <code>Condition Error NoSuchCell</code>. The solution is easy:
 <source lang="ioke">

@@ Line 37: / Line 37: @@
 </source>
-=== Missing comma in case, cond, if and unless expressions ===
+=== 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 <code>case</code>, <code>cond</code>, <code>if</code> and <code>unless</code> code:

@@ Line 3: / Line 3: @@
 == Mismatched commas ==
-One of the most insidious problems that can show up in Ioke programs happen 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.
+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 ===
@@ Line 17: / Line 17: @@
 Fixed version:
 <source lang="ioke">
 foo = method("foo is a method that does something really cool",
@@ Line 23: / Line 24: @@
 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:
 <source lang="ioke">
 foo = method("foo is a method that does something really cool" x,
@@ Line 29: / Line 31: @@
 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:
 <source lang="ioke">
 foo = method("foo is a method that does something really cool", x,
@@ Line 36: / Line 39: @@
 === Missing comma in case, cond, if and unless 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:
+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 <code>case</code>, <code>cond</code>, <code>if</code> and <code>unless</code> code:
 <source lang="ioke">
@@ Line 64: / Line 67: @@
 The above should be corrected as:
 <source lang="ioke">
 if(foox === 1..3,
@@ Line 87: / Line 91: @@
 </source>
-=== Added comma in dmacro specification ===
+=== Added comma in <code>dmacro</code> specification ===
-This last problem is the most insidious for the simple reason that it is the opposite of the other comma-related problems. Namely, when doing a dmacro, or one of the other destructuring syntax elements, the problem is generally that you add to many commas:
+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 <code>dmacro</code>, or one of the other destructuring syntax elements, the problem is generally that you add too many commas:
 <source lang="ioke">
@@ Line 97: / Line 101: @@
 </source>
-The above code is wrong. There shouldn't be a comma after the square brackets. The dmacro will fail in some spectacular way from this. But probably not when you expect it. If a dmacro fails for uncertain reasons, and debug-by-printing tell you strange things, the most common cause will be one comma to much. The above code should be:
+The above code is wrong: there shouldn't be a comma after the square brackets. The <code>dmacro</code> will fail in some spectacular way because of this, but probably not when you expect it. If a <code>dmacro</code> 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:
 <source lang="ioke">

← Older revision		Revision as of 19:48, 26 January 2009
Line 88:		Line 88:

	=== Added comma in dmacro specification ===		=== Added comma in dmacro specification ===
		+
		+	This last problem is the most insidious for the simple reason that it is the opposite of the other comma-related problems. Namely, when doing a dmacro, or one of the other destructuring syntax elements, the problem is generally that you add to many commas:
		+
		+	<source lang="ioke">
		+	x = dmacro(
		+	[>foo, bar],
		+	foo + bar evaluateOn(call ground, call ground))
		+	</source>
		+
		+	The above code is wrong. There shouldn't be a comma after the square brackets. The dmacro will fail in some spectacular way from this. But probably not when you expect it. If a dmacro fails for uncertain reasons, and debug-by-printing tell you strange things, the most common cause will be one comma to much. The above code should be:
		+
		+	<source lang="ioke">
		+	x = dmacro(
		+	[>foo, bar]
		+	foo + bar evaluateOn(call ground, call ground))
		+	</source>