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

@@ 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 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 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 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.