Hi Dan, What you are referring to is called *behavioral types* (see, *e.g., * https://www2.ccs.neu.edu/racket/pubs/fse01-flf.pdf).
If you want to go that route, you need (usually arbitrarily complex) behavioral contracts (not to be mistaken with the term type contracts used here) and static checks (*e.g., *based on abstract interpretation of a program). It would be super cool if Go2 natively supported behavioral contracts and check some of them automatically, but I doubt that there is enough resources/will/motivation. For example, behavioral contracts are a great fit for matrix operations as you can observe in Numpy and OpenCV libraries. (In case you want to use behavioral contracts in Go1, we developed https://github.com/Parquery/gocontracts to help us deal with contracts at run-time, and hope to start working on a Go tool based on abstract interpretation in some 2-3 years from now). On Tue, 27 Nov 2018 at 10:41, Dan Kortschak <dan.kortsc...@adelaide.edu.au> wrote: > Yes, this was raised as a possibility by Ian. But this negates a very > valuable aspect of matrices that I completely failed to consider in > writing the question: the issue of submatrices and how these are > valuable. > > On Mon, 2018-11-26 at 20:49 -0800, Tamás Gulácsi wrote: > > Just a silly idea: what if you make the dimensions (m,n) part of the > > type, not just T, somehow? > > > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
