On Nov 26, 2018, at 8:46 PM, Ian Lance Taylor <i...@golang.org> wrote:
>
> On Mon, Nov 26, 2018 at 5:14 PM Dan Kortschak
> <dan.kortsc...@adelaide.edu.au> wrote:
>>
>>
>> Question:
>>
>> One of the areas where we do this is in the mat package for matrix
>> arithmetic and linear algebra. We use panics in lieue of a compile-time
>> type check for appropriate input matrix shape (e.g. the check needed to
>> ensure [mxw] <- [mxn] x [nxw] is a valid operation). I don't see any
>> way to encode this kind of information into a contract as it stands in
>> the current contracts draft. I'm not entirely sure that any kind of
>> reasonably simple contract system *would* allow this. If we assume that
>> there is some type parameterised function that operates on say [n][m]T
>> to perform a matrix mult, can anyone see a way of encoding the required
>> constraint?
>
> There is no way to express that constraint. In general contracts are
> only intended to express things that can be described in the type
> system. What you are asking for--a relationship between the lengths
> of different slice types--can not be described in the type system.
>
> This of it this way: the purpose of a contract is to decide when it is
> OK to instantiate a generic function with a given type. When making
> that decision at compile time, we don't know the length of a slice.
> So we can't use the length of a slice when deciding whether to
> instantiate a generic function.
>
> (That said, one could imagine extending contracts to permit them to
> describe non-type arguments, and then one could use an integer
> argument to set the size of an array, and then one could write a
> contract describing the relationship between arrays. Of course the
> caller would have to pass arrays rather than slices, which would not
> work well with sub-matrixes.)
This is probably not allowed at present but what about something
like this?
contract foo(c, a, b [][]T) {
len(a[0]) == len(b)
len(c) == len(a)
len(c[0]) == len(b[0])
c[0][0] = a[0][0]
}
func matrix_mult(c, a, b [][]int foo) {
...
}
That is. allow specify the *structure* of a type in a contract
"parameter". I find this more direct that specifying in a contract
body an index expression to indicate that a parameter is a slice.
This also takes care of asserting that the *component* types of
generic function parameters must match.
This contract can not be fully evaluated at compile time in general
but the run time code will be fairly small. Even if you pass
non-type arguments to contracts, this check has to be done at
run time in general.
But I really think Go2 should be extended to properly support
N-dimensional arrays. May be slices can be naturally extended to
represent subarrays! I like Julia's support for arrays quite a
bit but that probably a bridge too far :-)
--
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.
