Jon, thanks for your feedback; it was both informative and supportive.
Jon Lang wrote:
Darren Duncan wrote:
2. There doesn't seem to be a role for "complex" as there is for "integer"
or "rational" or "real" or "numeric". So, if the boxed Perl complex number
is called "Complex" and the machine native one is called "complex" or
"complex128" or whatever, what would one name the role that is common to all
of these?
I'm definitely in favor of there being a Complex role - not just for
the reasons given above, but also to have a common role that applies
to a complex number regardless of the coordinate system that's being
used to store the value (e.g. cartesian vs. polar). Both should be
able to provide you with the real, imaginary, magnitude, and direction
components; but classes based off of the cartesian model should be
able to do the former two directly and calculate the latter two, and
vice versa. A single role that's agnostic about the coordinate system
would allow us to use any of these in a function call. For that
purpose, I think that the common, underlying role should be called
"Complex".
I agree 100%. I also foresaw the cartesian vs polar thing, and considered it
very important, but I didn't mention it in my post because for some reason I
assumed that the existing Complex type already supported both views, or I
thought I recalled the Synopsis already talking about it.
Anyway, yes, a Complex role *must* include both the cartesian and polar
possible-representations (possreps), and then there can be a composing class
optimized for each one.
Following the above pattern, you'd think that "Complex" would be best used
as th role name and so something else is needed for the type, either as some
abbreviation, or alternately with additions.
Conceivably one could have a complex type defined in terms of any
combination of the various real or rational or integer types, such as
"NumComplex" or "RatComplex" (and "FatRatComplex") and "IntComplex" etc.
For practical purposes, I think that the component types for Complex
should be standardized as Real - that is, the Complex role should
assume that the components do the Real role.
That's reasonable.
As I indicate above, I
think that a more significant distinction should be the coordinate
system: cartesian complex numbers are essentially optimized for use
with addition and subtraction; polar complex numbers are a more
efficient choice for multiplication and division; raising a number to
a complex exponent works most efficiently if the exponent is cartesian
and the result is polar, and vice versa for logs. And so on.
And now I learned something about complex math.
For the integer version, my understanding is that number theory already
provides a suitable term, "Gaussian integer", which is a complex number
whose real and imaginary parts are both integers.
So I suggest using "Gaussian" as the name option for an "IntComplex".
Or maybe better yet for completion sake, make "Gaussian" a role and
something like "Gaus" the type or something.
Hmm... true enough. I'd rather have Gaussian be to Complex as
Integral is to Real: a separate role, not necessarily related in any
sort of role composition sense, but serving a similar purpose. Note
that Gaussian would not have separate cartesian and polar forms; by
definition, it operates off of a cartesian coordinate system. While a
polar version could exist in theory, it doesn't in practice; and even
if it did, it wouldn't be interchangeable with the cartesian version,
the way that they are when the components are Real.
Personally I prefer the idea of Int and Rat etc being disjoint as programming
language data types, even if they are considered subsets by some conceptions,
because then we can just have Int as the one primitive type in terms of which
everything else is defined.
So it stands to reason in such as system that making Gaussian/Int-Complex types
and Real-Complex types disjoint is consistent with the fact that Int does *not*
compose the Real role.
OTOH, Gaussian definitely has analogs comparable to the differences
between Integral vs. Real, in that Gaussian and Integral have the
concept of factors and everything that goes with them (e.g., primes,
gcf, lcm, remainders, etc.) Perhaps we need a role to encapsulate
that notion, much like we have one that encapsulates the notion of
order (e.g., before/after). Or would that turn out to be unnecessary
clutter, seeing as how we only have two examples of roles that would
compose it (Integral and Gaussian), one of which is a highly technical
fringe case?
The role may still be a good idea, though.
See also Boolean, which currently is used by just Bool and Bit (and bit).
On a tangent, something else I was wondering or suggesting is whether it would
be reasonable for the Boolean role to be composed by anything that supports
bitwise operations (I don't mean shifting, but not/and/or/xor/etc) since I
believe all those bitwise operations are direct analogies to boolean operations.
I would assume in this case that all those operators in the role would be
virtual, since each would be implemented differently. Mind you, I could be
mis-imagining what exactly the Boolean role contains. (Also, if you want to be
thorough, it would also contain the other 7
nand/nor/xnor|iff/imp|implies/nimp/if/nif dyadic infix ops, even if they are
easy enough to define in terms of the others.)
<snip>
From a layman's view of things, I keep on finding myself wanting to
say "Integer" rather than "Integral". That said, it's not that hard
to retrain myself; and I do see some benefit to the notion that role
names are adjectives while class names are nouns, as long as it's
applied consistently to the standard roles. That said, see below.
Still: when I first saw "Integral", the first thing that came to mind
was "a calculus operation", not "whole numbers".
4. If "Integral" is better called "Integer", or regardless ...
Would "Numeric" be better called "Number"? Would there by any objection to
renaming it such? What are advantages of the former over the latter?
Basically, same idea, if we're going more for nouns or adjectives role
names.
IMHO, we should be going for nouns for role names. Adjectives should
be reserved for use with a role's parameters - that is, a named
parameter in a role's signature is an adjective, just like a named
parameter in a routine's signature is an adverb.
I agree. As far as I'm concerned, a role is a type (a set of values/objects),
and so its name should be a noun. What type is it? The role type is a union
over all of the other types that compose that role. (Whereas the other union
type declares itself what other types its values come from.) Unlike a class, a
type isn't defined by whether you can instantiate it. You probably can't
instantiate a "Dog|Cat" union type either, but you can instantiate Dog or Cat
probably. Part of what defines a type is whether you can declare that a
variable or parameter or attribute etc can hold values of it.
So we can also interpret that any role or class name that looks like an
adjective could in fact just be an abbreviation of a noun. Such as, "Integral"
is short for "IntegralNumber". I believe that all of the existing roles I
recall can be considered that way. This said, if we have a choice to use a word
that is a noun by itself, I may consider that preferable.
So, say, I suggest "Number" over "Numeric" and "Integer" over "Integral", etc.
-- Darren Duncan
