David Green wrote:
On 2009-Oct-4, at 2:07 pm, Moritz Lenz wrote:
Michael Zedeler wrote:
It doesn't, because succ should always give the next, smallest possible
element given some ordering relation.
Where's that definition from?
The dictionary. =) It would be confusing to have a "successor" method for something that isn't orderable and discrete. An ordered continuous type like Real could have .inc and .dec; it just happens that in the common case of Ints, .succ and .inc mean the same thing.

Complex could have an .inc method, but I don't think there's any especially obvious choice (because .inc probably wants an ordered type). Would it add 1? or 1+i? Better to spell it out explicitly.
Well, Real implies ordering (at least to me ;-), I don't think we have a
class or role for countability.
A Discrete role would be useful, but is Set good enough for that?
Sets could be acting as domains for things such as Integers, so we are on two different abstraction levels there (having Integer implement Set would probably never make much sense, but an Integer object can be part of a Set).

Integers, strings and other types have a succ and pred method, but you could say that they draw upon a set (acting as their domain) when they decide the successor and predecessor of any given element. In mathematical terms it makes sense, but I am aware that from an implementation perspective, it sounds somewhat odd. It does, however solve some of the current problems that we have with iterating on Ranges and various other things.

Also, the domain should define how to compare objects and could provide details about whether the set is finite, countable or uncountable.

Does anyone know if there has been any prior discussions of such an approach?

I started changing the spec, but decided against it since I have some 10 years of design discussion to catch up on first. Links to prior discussions will be greatly appreciated.

Regards,

Michael.

Reply via email to