http://www.perlmonks.org?node_id=697605


in reply to Re^3: What will scientific computing in Perl 6 look like?
in thread What will scientific computing in Perl 6 look like?

I simply don't believe that multi method dispatch takes care of it all when it comes to different number systems. While Perl 6 offers a lot of features, to the best of my knowledge The Structure of Computer Programming is still correct when it says "Developing a useful, general framework for expressing the relations among different types of entities (what philosophers call ``ontology'') seems intractably difficult. The main difference between the confusion that existed ten years ago and the confusion that exists now is that now a variety of inadequate ontological theories have been embodied in a plethora of correspondingly inadequate programming languages. For example, much of the complexity of object-oriented programming languages -- and the subtle and confusing differences among contemporary object-oriented languages -- centers on the treatment of generic operations on interrelated types."

That is not to say that Perl 6 is not an improvement. It is. It just isn't a solution.

  • Comment on Re^4: What will scientific computing in Perl 6 look like?

Replies are listed 'Best First'.
Re^5: What will scientific computing in Perl 6 look like?
by moritz (Cardinal) on Jul 15, 2008 at 08:08 UTC
    Well, Perl 6's type system has difficulties with respect to numeric types, because they don't form a nice hierarchy. Luckily we have roles, and thus can have a type of all (scalar) numeric types without pressing them into a hierarchy.

    Implementing the numeric types correctly is a bit tricky, but the fact remains that the user (aka Perl 6 programmer) can simply add (or override) operators for each pair of types. If one of them is always a user-defined one you can guarantee no clashes with existing semantics.

    So I don't see how Perl 6 isn't a solution wrt to adding new numeric types to the language - would you care to elaborate?

      I believe the book's qualms about calling that a solution involve the possibility of a combinatorial explosion if the language forces you do define all possible pairings, and the opacity and artificial stupidity of the solution if the computer is attempting to use artificial intelligence to second-guess the programmer's ideas of what should be intuited when types are not arrangeable in a simple "tower".

      Of course, this does not stop us from trying to solve the problem anyway... :)

        Exactly.

        If you limit yourself to a few numeric types, the problem won't seem to be that big a deal. If you know the long list of numeric types that mathematicians have (including many number of parametrized families of numeric types), it starts to become harder. Particularly when the answer has to be a different type than either operand (eg a Gaussian integer plus a rational number is generally a Gaussian rational).