On 1/4/07, Darren Duncan <[EMAIL PROTECTED]> wrote:
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.
Well, that's true to an extent. It's also true that we don't need anything but function abstraction, function application, and source filter capability to implement the language core. But that's kind of skirting the issue.
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.
They are necessary for I/O: mainly (and I think only) in the sleep() function.
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.
Well, that could make a lot of design work easier *for us*. Somebody still has to design it There's a lot to be said for pushing design issues off to CPAN. But I don't think this is the right time. All numerics modules would have to know how to work with each other (lest you would not be able to use a module whose numerics disagreed with yours, if any non-integral numerics were in the interface). That's not going to happen (and it becomes quadratically harder to add new numerics modules). You could have a canonical form that the numerics interface would have to know how to convert to, but that isn't stripping all non-integral numerics from the language: it's stripping all but one. But, supposing that we chose, eg. Rat for that[1]... Parrot has a native floating point type, requiring that the numerics module implementor would have to modify the code generator and optimizer, a royal pain in the ass (assuming we can come up with a modular way to do such a thing in the first place...). Finally, it's just weird. Perl is great at being "easy to get going with", the TIMTOWTDI thing. Having to import a module in order to divide two numbers, before you know what a module is, is too confusing to beginners. Most perl tutorials start with "start every script with #!/usr/bin/perl" (and many times) "#!/usr/bin/perl -w use strict;". We're turning strict and warnings on by default because we thought that having to start every script with a particular string was poor huffman coding. Do you really want to add "use Numerics::Float" to that list of "always use these" strings?
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.
This I agree with. Numerics are important enough to design an architecture for. But I don't think that it would be a good decision to punt them to CPAN, because they need to be pervasive in the language: it's pretty important to get the numerics "module" right, but it's much more important that everybody agrees on which one to use. Luke [1] There are problems with choosing a canonical form, because the only numeric form that can accurately represent all others is the "algebraic form" (not to be confused with algebraic numbers) where you just delay all operations that lose any accuracy whatsoever.
