Jon, thanks for your feedback; it was both informative and supportive.

## Advertising

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 tosay "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