On Thu, Jan 04, 2007 at 04:32:11AM -0700, Luke Palmer wrote: : >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.
Yes, though I'd generalize sleep() to pretty much any time API, since time is (to the first approximation) continuous. The time() function will return a floater, for instance. It should be considered wrongish to supply any timing API that only lets you specify integer seconds plus integer fractions of a second. Such APIs are not interoperable, and floaters are getting fast enough that timing calculations should not be a bottleneck. : >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. Agreed. Perl 6 is about picking good defaults along with the extensibility. : 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]... There are intermediate solutions that don't require a full crossbar solution. We could have a pecking order of interchange formats such that the "best" one is negotiated by any two numerics packages. If two packages both can do algebraic form, they use that. Otherwise if both can do Rats, they use that. Otherwise they use the biggest Flt they can both manage. We probably require all numerics to support Flt64 or some such. Perhaps the pecking order can be user-defined to sneak Dec or Fix in there somewhere, or to rate Flt better than Rat for speed reasons. Of course, any two numerics packages can negotiate to make a direct conversion and bypass the canonical pecking order entirely. But if Num is generic numerics then it could presumably be aliasable within a lexical scope to any type that supports the pecking order. The default would presumably be Flt. Larry
