# Re: numerics, roles, and naming

```Darren Duncan wrote:
> I'm inclined to consider a "Discrete" to be broad enough to include Boolean,
> as well as every single enum type in general; it would also include Order,
> say.  So I would also then add a more specific something, say
> "DiscreteNumeric".```
```
There are discrete things that are not ordered (such as gaussian
integers), and there are ordered things that are not discrete (such as
real numbers or strings).  As well, I was using the term "Discrete" as
shorthand for "DiscreteNumber", just as "Real" can be thought of as
shorthand for "RealNumber": the role's purpose, regardless of name, is
to mandate methods that are mostly unique to integer math (e.g.,
infix:<%>).  As such, it would be silly to apply the role to, say, an
enum of the days of the week: Thursday % Tuesday should not equal
Sunday; it should be nonsense.

And with that in mind, the role (whatever it's called) should not be
composed into Boolean, even conceptually: while Boolean values can be
mapped to numeric values, they are not inherently numeric, any more
than strings are.  Never mind the fact that there's no practical
application for such things as infix:<%> when talking about a class
with two possible values.

More generally, we need to be careful to keep anything new firmly
grounded in the practical.  If we introduce a "Discrete" role, it
should be because doing so allows us to do something more easily
(taking into account the effort involved in writing the role in the
first place), or because it makes some task possible that would
otherwise be impossible.  A role representing discrete numbers might
just meet these requirements, in that they let you write functions
that depend on being able to, say, factor numbers or find remainders
without worrying about what kind of numbers they are.  And even here
I'm leery, given the fringe status of non-Integer discrete numbers.
I'm not at all sure what practical benefit a generic "Discrete" role
would bring to the table.

Remember also: we're putting together the Perl 6 core here; we need to
show some discretion in terms of what to include vs. what gets "farmed
out" to perl 6 modules.  I suspect that gaussian integers belong
firmly in the latter camp; as such, they are germane to discussions
about core features only to the extent that the core needs to
anticipate such things.

--
Jonathan "Dataweaver" Lang
```