lichtkind

At TPC in Glasgow I held two talks (slides and Video stored or linked on my domain as linked on conference site) about my module Perl6::Math::Matrix. To me the most interesting parts of this talk were musings about how to write a good API in and for Perl 6. And since I already got from the audience a lot of good suggestion(, which are all implemented by now [by the critic or me]), I will write here also a series of posts about this topic and maybe get some inspirations more.

Basic Properties

As said during the talk: the basic design decisions were to see the Matrix as an array of arrays and a read-only data object. This allows me to cache all lazy evaled, computation heavy properties and not worry about them changing. It also forces me to create new Matrix objects when computing derivative matrices.

Class Types

Such design decisions concerning the data structures are the most important to me. They also include thought about which data types we will need, which led me to my wish having a data type for a valid row and column index. This is not possible in Perl 6 yet, but I talked with Jonathan and he seems to gets slowly convinced about the usefulness of what I would call class types (subset that can check against attribute data). It is not about inventing strange things but all the methods in the code that have to call a checker method, that tests if an index is valid is a big code small to me.

Cell Types

Last not least the cells of the Matrix are of the type Numeric, which is the umbrella for all (you may guessed it) numerical types. As part of my talk we had a dispute between some audience member, $Larry and me, about the demand, Bool should be an allowed cell type. As a resulted we found out, that Bool is already included in Numeric (but converts to Int, when .Numeric is called on the value, since its just an ordinary enumeration [False, True]). The other end of the spectrum (widest type) is Complex, which is very good to have since it is used by mathematicians and some matrix properties only make sense if you allow complex values. In some cases (which will be the topic of some later part), I will recognize the types Bool, Int, Num, Rat, FatRat and Complex and treat them differently, but in ordinary signatures Numeric will be used, when dealing with single call values.