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.
