The calculus talks about expressions (including variables) denoting objects — rather than the objects themselves, which only exist at run time)\. It is easy to see that an expression is no longer aliased: it disappears from the alias relation.

I use FrameMaker for anything a bit complicated typographically — glad you like it.

– BM

I wonder what your view is on invariant data structures and LINQ style programming where you would write: list.All(item => item > 0) – unfortunately we still cannot write list.All(> 0) in a language such as C#. There are quite efficient invariant data structures like finger trees and it would appear natural in a concurrent world that we use invariance to protect ourselves from working on quicksand and invariant data structures also go like hand-in-glove with declarative query-style programming and is very easy to reason about.

Thoughts?

Less appropos, I use contracts everywhere in my C# programs but since there is no syntactic support for them, they look much more ugly than Eiffel contracts.

By “approve” I don’t mean that I agree, of course (but I hope you didn’t think I was trying to censor your critique).

By using emotionally charged language you make it hard to answer factually; let me simply note that even the simple loop you propose can be significantly simplified:

across list as l loop print (l.item) end

which I think reads better. You also do not say how you would write loops representing predicates, such as:

across list as l all l.item > 0 end

which we have started to use extensively in contracts.

Thanks for the compliment, much appreciated, on the alias analysis work.

– BM

There is an important semantic difference. If you consider the `across’ construct carefully you will note that it is more powerful than typical “foreach” loops. The key is in the use of the cursor variable, following `as’. It adds considerable flexibility, for example by allowing access to the index of the element, to the index of the iteration (not necessarily the same!), to the previous element, the next element… Most “foreach” loops do not have this flexibility.

As to the choice of keyword: Eiffel avoids multi-word keywords for clarity, so `foreach’ was not considered. A more natural-sounding choice would have been `over’, but too many existing programs use this name as identifier; `across’ was not to everybody’s taste but seemed reasonable enough.

– Bertrand Meyer
(Sorry for the delay in approving your comment for publication, I had no time to take care of the blog in recent weeks.)

The NSF and many other funding agencies are well aware of this situation and are trying to do something about it. Yes perhaps their language is a little hyped but at least it is a move in the right direction. Unfortunately with the whole of the academic research sector being “metricized” with h-factors, g-factors, impact factors, and rankings to suit our bean-counting administrations they are fighting a losing battle. Just check for yourself how many papers Andrew Wiles (solver of Fermat) or Perelman (solver of Poincare) have written over their careers and think about their real impact.

There is also an interesting case of violated reflexivity in the Eiffel standard. Check ECMA-367 section 8.21.3

“The Boolean_expression e ~ f has value true if and only if the values of e and f are both attached and such that e.is_equal (f) holds.”

In other word, with x: detachable ANY, x ~ x must yield False per the Eiffel standard.

Be reassured, under Eiffelstudio it yields True.

1. I don’t have access to the standard as it seems the reference document is not free of charge. Why you must pay to know the standard is one topic but I’ll leave it for another time. Wikipedia has a link to a recent draft (1.2.9) and I believe you’re refering to section 7.11 that I will quote here:

“Comparisons are exact and never overflow or underflow. Four mutually exclusive relations are possible: less
than, equal, greater than, and unordered. The last case arises when at least one operand is NaN. Every NaN
shall compare unordered with everything, including itself. Comparisons shall ignore the sign of zero
(so +0 = −0). Infinite operands of the same sign shall compare equal.

Languages define how the result of a comparison shall be delivered, in one of two ways: either as a condition
code identifying one of the four relations listed above, or as a true-false response to a predicate that names the
specific comparison desired.”

I didn’t see anything else in this draft specifying that NaN comparison should yield false, however “Every NaN
shall compare unordered with everything, including itself” leaves no doubt about that since unordered is not equal.

Note that raising an exception would violate the standard, I believe, since comparing two numbers even if one is a NaN is a non-signaling operation.

2. I think the problem is that we want to maintain not two properties (equality is reflexive, and NaN /= NaN) but three, the third being that all objects can be compared. This is captured by the fact that is_equal is a feature of ANY, while other comparison features such as is_less come from specialized classes like COMPARABLE.

In a world with is_equal being a feature of an abstract class (EQUATABLE? It sounds ugly) the REAL class would not inherit this feature. Real numbers could not be compared with is_equal. They would be compared with a dedicated feature taking one of “less than”, “equal”, “greater than” and “unordered” as an argument, that could then safely return true or false as specified by the standard.

3. I’ve been confronted in the past with problems such as this one. Almost always, it comes from trying to mix orange and apples in a single value or concept. The way out is then to clearly separate the involved values and concepts in different entities. For instance, consider this definition of REAL:

class REAL
…
feature
value: ARRAY[INTEGER_8] — The numeric value
meaningful: BOOLEAN — False if a NaN
…
end

Then the value of a number is separate from the boolean attribute that indicates if it has a meaning. The proper redefinition of is_equal becomes

is_equal (other: like Current): BOOLEAN
do
if meaningful and other.meaningful then
result := value.is_equal(other.value)
else
result := False
end
end

This definition satisfies x /= x when x.meaningful is False.

4. You could argue that this is only an artificial trick to reconcile Eiffel contracts and the IEEE standard. I think it goes deeper than that. Equality in Eiffel, and probably all languages, is only an approximation of mathematical equality. If you asked, during a math course “does x = x?” then sure I’d answer yes. But during a computing course? I’d answer “depends…”. Many aspects of computer languages are traductions of mathematical operations and properties that want to stay as close as the original concept, but never succeed that it.

There are well known examples. Take this function for instance:

identity_with_a_trick (n: INTEGER): INTEGER
do
result := n * 2
result := result // 2
ensure
same_value: result = n
end

It is naive to think that dividing or multiplying a number is harmless, it can raise an exception. The function above can raise a post-condition violation exception.

So to answer prof. Meyer’s question “A programming language should support the venerable properties that equality is reflexive and that assignment yields equality (…) Do you agree?” I respectfully disagree in general, and fully agree when equality is defined for the objects being compared. IEEE 754 standard simply states it isn’t.

If a1, a2, … and b1, b2, … are sequences of real numbers that both approach 0, then the sequence of quotients a1/b1, a2/b2, … in general will not approach any real number, but will rather have a set of (extended) real numbers as its limit (the smallest of which is known as the inferior limit and the largest of which is known as the superior limit).

We can adopt the convention that an ordinary function applied to a set is equal to the set of function values, and we can then go on to calculate with sets of real numbers much as with real numbers (the first person to do this may have been Weierstrass). Let us now consider the question of equality between such sets. We know that {3, 4} and {4, 7} are different by ordinary set equality, but if we apply the equality function to the pairs (3, 4), (3, 7), (4, 4), and (4, 7) then the results will be False, False, True, and False, respectively, giving us the set {False, True}. In fact, we get the same result if we compare {3, 4} to itself.

How are we to interpret an equality that evaluates to {False, True}? If we interpret it as True then transitivity of equality will quickly lead to all real numbers allegedly being one and the same thing. I would say that what this really means is that there is a not-too-unnatural sense in which all real numbers are _equivalent_. If we interpret {False, True} as being False, then we allegedly have things/objects/entities which are not equal to themselves (or maybe I should say that we have a single thing/object/entity which is not equal to itself – without equality we have no standard for counting things.). Finally, we may prefer to restrict the domain of definition of our equality relation so that the cases that gave {False, True} are excluded from consideration.

Based on these three possibilities one might conclude that we cannot have NaN=NaN without getting x=y for any real numbers x and y (thus vindicating IEEE 754). However, we also have the set equality that makes {3, 4} distinct from {4, 7}, and we can use this type of equality to introduce yet another type of equality: We may consider all sets that contain more than one real number to be one and the same object, and we may call this object “NaN”. In fact, there is mathematical research that supports treating NaN as a first-class object: See http://en.wikipedia.org/wiki/Wheel_theory .

Math is partial and there are different ways to handle this. Problems show when these ways are mixed, for example through the interactions between Boolean and Real.

One way is the use of NaN and any other 3-valued logic. But then, Boolean value should have a NaB. Another is the use of preconditions. That is what Eiffel uses. To be consistent, Eiffel should raise a precondition violation whenever an operation would produce a NaN.

Of course, floating-point numbers are imperfect substitutes for mathematical real-valued numbers – I think REAL is a poor choice of name for the type in a programming language, as it has the potential to mislead the mathematically minded – since many functions on floating-point values that a mathematician would expect to be identity functions will turn out to accumulate imprecision, resulting in similarly surprising x != x.

Kind regards,

Ian

In void-safe mode the compiler will reject the code (although I haven’t checked this yet on an actual example).

is the calculus able to determine if and when an object is not aliased anymore?

Also, which typesetting system do you use for your publications? Latex? I find the results awesome.

S.

across s as c loop print (c.item) end

If ’s’ is declared to be of a detachable type, and if it actually is Void at run time, does this ‘across’ loop raise a Void-target call exception? (This is what C# does if the structure supplied to a ‘foreach’ loop is null. I’m fixing one such NullReferenceException bug right now that has gone undetected for months in our C# code.) Or does ‘across’ recognise that the structure is Void, and treat it the same as if it were empty, performing zero iterations of the loop? (This is what I wish C# ‘foreach’ loops did; I wish it frequently, unfortunately.)

Or would the Void-safe Eiffel compiler reject the above code if ’s’ is detachable?

- The simplest is to make the class a descendant of one of the existing descendants of the ITERABLE class, such as INDEXABLE (which is for example used as ancestor by all the list classes). Then you have nothing more to do; you get a standard cursor.

- If you want a more specific cursor, make the class a descendant of ITERABLE and write the specific cursor class as a descendant of ITERATION_CURSOR, effecting the queries `item’ and `off’. This gives you finer control in case your structure has specific properties that should be accessible through the cursor. As an example, you can look at how this was done for HASH_TABLE in such a way that in a loop

across my_hash_table as mht loop … end

you can in a loop body access both mht.item, giving the current item in the hash table, and mht.key, giving its key.

I will release my current implementation as open source in a few weeks.