I just had a thought, which may or may not help this discussion along.

It occurs to me that, while they still need privileged support in Perl 6 the language, non-integer numbers aren't actually all that important as far as implementing the language core goes.

That is, I consider non-integers only a little more central than say, date and time types, as far as how necessary they are for bootstrapping Perl 6, which is to say, I don't think they are necessary at all.

Eg, are non-integer numbers used anywhere to implement any of: the meta-model, grammars and parsing, control flow, generic collection types, input and output, whatever? AFAIK, those are mainly implemented with booleans, integers, strings, and collection types.

So, if non-integer numbers are officially language extensions, such as date and time types are, though they may be privileged by having their operators automatically imported for ease of use, and by how they are implemented, then that could make a lot of design work easier.

For example, the extra space of putting them aside will let us expand them to make them more thorough, such as dealing well with exact vs inexact, fixed vs infinite length, fuzzy or interval based vs not, caring about sigfigs or not, real vs complex vs quaternon, etc. This would also allow easier substitutions of such math libraries by specializations for science or statistics or whatever, as the need may be, since we don't really want to bundle *everything* with the language.

Really, dealing with non-integer numbers properly deserves, conceptually or actually, a separate component or several just for them, as per unix philosophy of dedicated pieces doing what they do well.

I hope this proposal makes sense.

-- Darren Duncan

Reply via email to