Auto-Increment Proposal - Revision history

Peter gummer: /* An Auto-Increment/Decrement Mechanism for Eiffel Integers */

2007-03-12T06:19:12Z

‎An Auto-Increment/Decrement Mechanism for Eiffel Integers

Peter gummer: /* An Auto-Increment/Decrement Mechanism for Eiffel Integers */

2007-03-12T05:57:44Z

‎An Auto-Increment/Decrement Mechanism for Eiffel Integers

Rosmond: /* An Auto-Increment/Decrement Mechanism for Eiffel Integers */

2007-03-09T13:23:07Z

‎An Auto-Increment/Decrement Mechanism for Eiffel Integers

Rosmond: /* Enhancing the Loop Construct */

2007-03-09T13:21:33Z

‎Enhancing the Loop Construct

Rosmond: /* Enhancing the Loop Construct */

2007-03-09T13:19:59Z

‎Enhancing the Loop Construct

Rosmond: /* Enhancing the Loop Construct */

2007-03-09T13:19:11Z

‎Enhancing the Loop Construct

Rosmond: /* An Auto-Increment/Decrement Mechanism for Eiffel Integers */

2007-03-09T13:09:32Z

‎An Auto-Increment/Decrement Mechanism for Eiffel Integers

Manus at 19:19, 8 March 2007

2007-03-08T19:19:10Z

Manus: /* An Auto-Increment/Decrement Mechanism for Eiffel Integers */

2007-03-08T19:18:36Z

‎An Auto-Increment/Decrement Mechanism for Eiffel Integers

Manus: Initial

2007-03-08T18:20:40Z

Initial

New page

[[Category:ECMA]]
Author: Roger F. Osmond
=An Auto-Increment/Decrement Mechanism for Eiffel Integers=

In my never-ending quest to remove barriers standing in the way of Eiffel adopting by the masses, I was having a think on the oh-so-popular auto-increment and auto-decrement features of C and its kin (e.g. i++, i--).
You have to admit that it's a tidy notation, albeit the epitome of side-effect worship. Still there is merit in looking at the "Why" that makes it so popular.
As I see it, the most common usage, and where Eiffel gets dinged most often, is when an integer is being used as a loop counter or index. Eiffel has but one loop construct, and it is good. C has a dog-pile of them, but folks do seem to like them. Why?
I think Eiffel can and should live with a single loop. It really is a good thing, but you have to admit it's a pain in various extremities to keep doing the old "i := i + 1". Sure, we can user iterators, but that's just a confusing mess for newbies, and it really doesn't address the fundamental objection from non-Eiffelists.
They simply want a simpler way to increment that stupid little local integer entity.
So why not give them what they (and I dare say quite a few of "us") want?
Let' break it down first.
The construct in question is the ubiquitous "i++" (and its twin, i--). It has two personalities. First, it quickly and easily increments (decrements) an entity. Fair enough. It _can_ also be referenced as a value. This is of course a mortal sin in the Church of Eiffel (as it should be).
To be fair, the first personality is pretty handy, and altogether defensible, even by Eiffel standards. The second personality is of course its mister Hyde.
I bet if we could give them the first part, then missing the second part wouldn't be such a big deal.
Let's have a whack at it.
If we were, (get ready; you might think I'm on drugs or something, to look at INTEGER as more like a data structure than we have in the past (or at least something more object-like), then an interesting option presents.
What if we were to define a feature in INTEGER_REF (and its various flavors) called "forth" (and its sister, called "back")? Then, we could do something like "i.forth" instead of i := i + 1; The especially numerate among you might have noticed that there are no keystrokes saved, but bear with me. Still, we get two procedures that increment and decrement an INTEGER, complete with postconditions. (the same mechanism would work nicely for CHARACTERs, where forth would increase the code by one) If we then leverage the alias mechanism, we can substitute a punctuation of sorts for the forth and back calls. This would be just like the "+" alias for "append", and I hope would not offend anyone.
There is a wrinkle. Eiffel presently does not support a postfix alias. Postfix is the obvious choice here. It also, at least as far as I know, doesn't support unary aliasing. I understand from personal experience that unary operators are a pain, but they're a reality. A double-dip operator, like the famous "++" I think would help in the ambiguity department.
With these relatively minor changes, we would have removed another point of discomfort for potential converts, and without compromising any Eiffel principles. In fact, this interpretation of "++" would be an excellent example to other language folks of how to do it. The Eiffel version would not have a value like the C version, and therefore would be side-effect free. Sure, the C version was designed to have a side effect and many C practitioners depend on that behavior in the for loop controls. Eiffel doesn't have a for loop. It also doesn't have a while loop. It all seems quite self-consistent to me.

==Enhancing the Loop Construct==

While we're on the topic, let's have a look at the loop construct itself. Eiffel has one form and as I said before, that's a good thing. There are sub-forms however. For example, loop assertions are optional. Including or omitting these results in different forms. If we were to introduce another optional component to the loop - an iterator expression, I think the loop would be better specified and easier to understand. Here is an example (note the use of the forth feature of INTEGER)

from i := 1
until i > 5
by i.forth
loop
{loop body}
end

The 'by' keyword introduces the iterator expression. In this case, it's a simple procedure call to i.forth. It can as easily be any procedure expression, even an agent. I think this latter case opens up the possibility of creating a much more usable iterator class by the way.
Because the iterator expression is optional, there is no issue of backward compatibility. All existing (and future) loops without the iterator expression would be just fine.
An alternate form would have the iterator expression at the bottom of the loop.

from i := 1
until i > 5
loop
{loop body}
by i.forth
end

While this more closely resembles the way code is written by hand, to my thinking it has much less value because it splits the loop specification into 2 sections, possibly widely separated. I much prefer the spec being all together at the top. It just reads better as a spec, and I think it would encourage forethought - resulting in more reliable loops. Leaving the iterator to the end is just asking for incomplete thinking.

How does all this impact loop-level assertions? I think there is potential to have a very positive impact. At present, loop assertions are a mystery to most. I use them, but not all the time (shame on me). Newbies simply freak out, especially when confronted with the rules for loop variants.
By including the iterator expression in the loop spec, it should be possible to generate loop variants automatically. Loop invariants remain as before.
This could help quite a bit. We could have another switch in the system configuration to enable automatic loop variant assertions. They would exist only for those loops with a complete specification - i.e. with an iterator expression.
Those folks who use loops and indices the most I think would welcome this feature and the forth/++ extension to integer.

@@ Line 27: / Line 27: @@
 What if we were to define a feature in INTEGER_REF (and its various flavors) called "forth" (and its sister, called "back")?  Then, we could do something like "i.forth" instead of i := i + 1; The especially numerate among you might have noticed that there are no keystrokes saved, but bear with me.  Still, we get two procedures that increment and decrement an INTEGER, complete with postconditions. (the same mechanism would work nicely for CHARACTERs, where forth would increase the code by one) If we then leverage the alias mechanism, we can substitute a punctuation of sorts for the forth and back calls.  This would be just like the "+" alias for "append", and I hope would not offend anyone.
-''(This idea of a "+" alias for "append" will offend someone very important, I'm afraid: the Eiffel compiler. The '''Alias Validity Rule''' in the ECMA specification states that aliases are only allowed on queries. -- Peter Gummer.)''
+''(This idea of a "+" alias for "forth" will offend someone very important, I'm afraid: the Eiffel compiler. The '''Alias Validity Rule''' in the ECMA specification states that aliases are only allowed on queries. -- Peter Gummer.)''
 There is a wrinkle.  Eiffel presently does not support a postfix alias.  Postfix is the obvious choice here.  It also, at least as far as I know, doesn't support unary aliasing.  I understand from personal experience that unary operators are a pain, but they're a reality.  A double-dip operator, like the famous "++" I think would help in the ambiguity department.  It has been suggested that perhaps using the prefix form would be a reasonable alternative.  If the postfix form presents too much  of a challenge, then the prefix form should be adequate.

← Older revision		Revision as of 05:57, 12 March 2007
Line 26:		Line 26:

	What if we were to define a feature in INTEGER_REF (and its various flavors) called "forth" (and its sister, called "back")? Then, we could do something like "i.forth" instead of i := i + 1; The especially numerate among you might have noticed that there are no keystrokes saved, but bear with me. Still, we get two procedures that increment and decrement an INTEGER, complete with postconditions. (the same mechanism would work nicely for CHARACTERs, where forth would increase the code by one) If we then leverage the alias mechanism, we can substitute a punctuation of sorts for the forth and back calls. This would be just like the "+" alias for "append", and I hope would not offend anyone.		What if we were to define a feature in INTEGER_REF (and its various flavors) called "forth" (and its sister, called "back")? Then, we could do something like "i.forth" instead of i := i + 1; The especially numerate among you might have noticed that there are no keystrokes saved, but bear with me. Still, we get two procedures that increment and decrement an INTEGER, complete with postconditions. (the same mechanism would work nicely for CHARACTERs, where forth would increase the code by one) If we then leverage the alias mechanism, we can substitute a punctuation of sorts for the forth and back calls. This would be just like the "+" alias for "append", and I hope would not offend anyone.
		+
		+	''(This idea of a "+" alias for "append" will offend someone very important, I'm afraid: the Eiffel compiler. The '''Alias Validity Rule''' in the ECMA specification states that aliases are only allowed on queries. -- Peter Gummer.)''

	There is a wrinkle. Eiffel presently does not support a postfix alias. Postfix is the obvious choice here. It also, at least as far as I know, doesn't support unary aliasing. I understand from personal experience that unary operators are a pain, but they're a reality. A double-dip operator, like the famous "++" I think would help in the ambiguity department. It has been suggested that perhaps using the prefix form would be a reasonable alternative. If the postfix form presents too much of a challenge, then the prefix form should be adequate.		There is a wrinkle. Eiffel presently does not support a postfix alias. Postfix is the obvious choice here. It also, at least as far as I know, doesn't support unary aliasing. I understand from personal experience that unary operators are a pain, but they're a reality. A double-dip operator, like the famous "++" I think would help in the ambiguity department. It has been suggested that perhaps using the prefix form would be a reasonable alternative. If the postfix form presents too much of a challenge, then the prefix form should be adequate.

@@ Line 62: / Line 62: @@
 While this more closely resembles the way code is written by hand, to my thinking it has much less value because it splits the loop specification into 2 sections, possibly widely separated.  I much prefer the spec being all together at the top.  It just reads better as a spec, and I think it would encourage forethought - resulting in more reliable loops.  Leaving the iterator to the end is just asking for incomplete thinking.
-Another option might be to drop the "by" keyword altogether.  The presence of a legitmate statement itself might be adequate.  The construct then would look like this.
+Another option might be to drop the "by" keyword altogether.  The presence of a legitimate statement itself might be adequate.  The construct then would look like this.
 <eiffel>

@@ Line 15: / Line 15: @@
 Let' break it down first.
-The construct in question is the ubiquitous "i++" (and its twin, i--).  It has two personalities.  First, it quickly and easily increments (decrements) an entity.  Fair enough.  It _can_ also be referenced as a value.  This is of course a mortal sin in the Church of Eiffel (as it should be).
+The construct in question is the ubiquitous "i++" (and its sister, i--).  It has two personalities.  First, it quickly and easily increments (decrements) an entity.  Fair enough.  It _can_ also be referenced as a value.  This is of course a mortal sin in the Church of Eiffel (as it should be).
 To be fair, the first personality is pretty handy, and altogether defensible, even by Eiffel standards.  The second personality is of course its mister Hyde.

@@ Line 38: / Line 38: @@
 <eiffel>
-  from i := 1
+from i := 1
-  until i > 5
+until i > 5
-  by i.forth
+by i.forth
-  loop
+loop
      {loop body}
-  end
+end
 </eiffel>
@@ Line 52: / Line 52: @@
 <eiffel>
-  from i := 1
+from i := 1
-  until i > 5
+until i > 5
-  loop
+loop
      {loop body}
-  by i.forth
+by i.forth
-  end
+end
 </eiffel>
@@ Line 65: / Line 65: @@
 <eiffel>
-  from i := 1;
+from i := 1;
-  until i > 5
+until i > 5
-  i++;
+i++;
-  loop
+loop
      (loop body)
-  end;
+end;
 </eiffel>

@@ Line 46: / Line 46: @@
 </eiffel>
-The 'by' keyword introduces the iterator expression.  In this case, it's a simple procedure call to i.forth.  It can as easily be any procedure expression, even an agent.  I think this latter case opens up the possibility of creating a much more usable iterator class by the way.
+The 'by' keyword introduces the iterator statement.  In this case, it's a simple procedure call to i.forth.  It can as easily be any statement, even an agent.  I think this latter case opens up the possibility of creating a much more usable iterator class by the way.
-Because the iterator expression is optional, there is no issue of backward compatibility.  All existing (and future) loops without the iterator expression would be just fine.
+Because the iterator statement is optional, there is no issue of backward compatibility.  All existing (and future) loops without the iterator statement would be just fine.
-An alternate form would have the iterator expression at the bottom of the loop.
+An alternate form would have the iterator statement at the bottom of the loop.
 <eiffel>
@@ Line 62: / Line 62: @@
 While this more closely resembles the way code is written by hand, to my thinking it has much less value because it splits the loop specification into 2 sections, possibly widely separated.  I much prefer the spec being all together at the top.  It just reads better as a spec, and I think it would encourage forethought - resulting in more reliable loops.  Leaving the iterator to the end is just asking for incomplete thinking.
 How does all this impact loop-level assertions?  I think there is potential to have a very positive impact.  At present, loop assertions are a mystery to most.  I use them, but not all the time (shame on me).
 Newbies simply freak out, especially when confronted with the rules for loop variants.
-By including the iterator expression in the loop spec, it should be possible to generate loop variants automatically.
+By including the iterator statement in the loop spec, it should be possible to generate loop variants automatically.
 Loop invariants remain as before.

@@ Line 3: / Line 3: @@
 ==An Auto-Increment/Decrement Mechanism for Eiffel Integers==
-In my never-ending quest to remove barriers standing in the way of Eiffel adopting by the masses, I was having a think on the oh-so-popular auto-increment and auto-decrement features of C and its kin (e.g. i++, i--).
+In my never-ending quest to remove barriers standing in the way of Eiffel adoption by the masses, I was having a think on the oh-so-popular auto-increment and auto-decrement features of C and its kin (e.g. i++, i--).
 You have to admit that it's a tidy notation, albeit the epitome of side-effect worship.  Still there is merit in looking at the "Why" that makes it so popular.
@@ Line 23: / Line 23: @@
 Let's have a whack at it.
-If we were, (get ready; you might think I'm on drugs or something, to look at INTEGER as more like a data structure than we have in the past (or at least something more object-like), then an interesting option presents.
+If we were (get ready; you might think I'm on drugs or something) to look at INTEGER as more like a data structure than we have in the past (or at least something more object-like), then an interesting option presents.
 What if we were to define a feature in INTEGER_REF (and its various flavors) called "forth" (and its sister, called "back")?  Then, we could do something like "i.forth" instead of i := i + 1; The especially numerate among you might have noticed that there are no keystrokes saved, but bear with me.  Still, we get two procedures that increment and decrement an INTEGER, complete with postconditions. (the same mechanism would work nicely for CHARACTERs, where forth would increase the code by one) If we then leverage the alias mechanism, we can substitute a punctuation of sorts for the forth and back calls.  This would be just like the "+" alias for "append", and I hope would not offend anyone.
-There is a wrinkle.  Eiffel presently does not support a postfix alias.  Postfix is the obvious choice here.  It also, at least as far as I know, doesn't support unary aliasing.  I understand from personal experience that unary operators are a pain, but they're a reality.  A double-dip operator, like the famous "++" I think would help in the ambiguity department.
+There is a wrinkle.  Eiffel presently does not support a postfix alias.  Postfix is the obvious choice here.  It also, at least as far as I know, doesn't support unary aliasing.  I understand from personal experience that unary operators are a pain, but they're a reality.  A double-dip operator, like the famous "++" I think would help in the ambiguity department.  It has been suggested that perhaps using the prefix form would be a reasonable alternative.  If the postfix form presents too much  of a challenge, then the prefix form should be adequate.
-With these relatively minor changes, we would have removed another point of discomfort for potential converts, and without compromising any Eiffel principles.  In fact, this interpretation of "++" would be an excellent example to other language folks of how to do it.  The Eiffel version would not have a value like the C version, and therefore would be side-effect free.  Sure, the C version was designed to have a side effect and many C practitioners depend on that behavior in the for loop controls.  Eiffel doesn't have a for loop.  It also doesn't have a while loop.  It all seems quite self-consistent to me.
 ==Enhancing the Loop Construct==