[go-nuts] Operators in Go

You are opening the Pandor's box of generics, about
which many many words have been written on this mailing
list. Summary of the summary of the summary:
generics are hard, and no solution adequate to the
demands of the Go implementors has yet been
devised.

Chris

IIRC, the main objection the go devs (and others) have to this is that it
allows (bad) developers to create a situation where 'a+b' doesn't mean what
you'd think, by overloading .Plus().

That seems like an odd excuse: it's the same as any other function, if it's
named poorly then that falls on the shoulders of the developer. I don't see
+ as carrying any more implicit meaning then a function named DoX that
instead does Y.

But I understand, generics are difficult.

Hidden and/or surprising costs are a concern IMO.

When you see `DoX()`, you're well aware that if you don't (yet) know
what 'DoX' does, than you cannot estimate its cost/performance.

When you see `a+b`, you know, that there are no hidden costs above:
integer/float add (small constant cost) or string concatenation
(bigger, non constant cost). Introducing operator overloading voids
such performance assumptions even for functions so common/frequent
that many/most programming languages allow their invocation by writing
operators instead of function calls.

-j

an example.. in Python, mydict["foo"], myobj.foo and myobj.foo = 3 can mean
anything. It could load something from disk, or make a connection to some
remote server. Or launch ICBMs.

For a saner approach, see typeclasses:
http://en.wikipedia.org/wiki/Type_class (a type which implements the Eq
interface can do "==", and a type that implements the Ord interface can do
">"/"<", etc., and you can then simply have functions that take arguments
of that interface type. To get the whole benefit, you would need to be able
to make it a constraint instead of a concrete type, so you're able to both
take and return a variable of type "a" which satisfies e.g. Eq or Ord. In
Go you have to return some specific type and type-assert manually.) This is
a big thing to do and has many problems. It's been discussed many times.
Here's a summary of the predicament: http://research.swtch.com/generic

Agreed, there's a limit to how far you should go. But on the other hand
it's a bit odd that we have to have either 4 differently named versions of
a function or we have to explicitly cast every argument. Not to say that
explicit casting is bad but there's a limit to how much boiler plate a
programmer should have to write. (And if someone's code is launching ICBMs
using the + operator I'm not sure I want to live on this planet any more).

I'm not suggesting general operator overloading, I've spent long enough
hacking C++ to see some horrible uses of it. I'm merely focused on why it
seems there's no clean way (That I know of) to write simple operations for
all numeric types.

For a saner approach, see typeclasses:
I work mostly in Haskell now so I'm aware of typeclasses, and go interfaces
are similar to an extent. The main problem is that Haskell is more than a
little generous about what form your functions take (infix, prefix) and go
isn't. And yes without some sort of Minler-Hindley type system typeclasses
lose a lot of steam.

So out of curiosity, are there any generics solutions which are favored by
the Go community?

Because this would require Go to support function type inheritance and
polymorphism. Why ? Because you need type inheritance to implement the
concept of 'all numeric types', and polymorphism to be able to
distinguish between the various numeric sub types and implement proper
behavior like float64 = float64.

This is why I believe generics can not be added to Go without
affecting the fundamental design choices of the language.

Dave

I think you're only having this because you want to "write generic math
functions like Abs".

You're quite right; writing such functions in Go is not a sensible
operation. At the same time, it's also not terribly useful *in practice. *In
idiomatic Go, it doesn't come up much that you *need *such a function.

Thomas

It is not terribly useful in *your *practice, because of the types of
applications that you write. It is not useful in *my* practice, mostly
because I don't use Go for anything numeric. It is obviously an issue for
the OP.

Isn't that just an efficient way of expressing the following?:

deaths += city // Launch nuke.

Sorry, obviously feeling dark today.

Dan

Comments like this always leads me to wonder, do programmers have a higher
percentage of psychopaths than other professions? :)

Dark humour is a way of coping with an otherwise unmanageable world. I pity those who come from cultures that frown on its use.


On 07/02/2013, at 1:16 AM, "Robert Johnstone" wrote:

Comments like this always leads me to wonder, do programmers have a higher percentage of psychopaths than other professions? :)


On Tuesday, 5 February 2013 18:14:54 UTC-5, kortschak wrote:
Isn't that just an efficient way of expressing the following?:

deaths += city // Launch nuke.

Sorry, obviously feeling dark today.

want to live on this planet any more

I'm not sure you will be able to. + is a very common operation!

I don't think there's a generally-agreed-upon approach to generics, or it
probably would have been implemented already. Robert Griesemer floated that
somebody had made some reasonable suggestions a while ago, but I'm not sure
if that turned into anything. Personally, I think typeclasses and type
inference just feel like a natural fit with what Go already has.

http://channel9.msdn.com/Blogs/Charles/Erik-Meijer-and-Robert-Griesemer-Goaround
22:27. You probably won't be too satisfied since it is quite sparse
on details ("we have an internal proposal, an implementation, and a couple
of test programs.") Since there hasn't been much/any discussion of it, I
assumed that it hasn't borne much fruit.

Yeah, I've also had this observation. I'm not much into compiler theory,
so I don't understand what's so radically different about type classes that
they're hard to support in Go, but I don't think Go has to support type
classes to support operator overloading. It would require a redefinition
of how the compiler treats binary operators. I'm not even sure that it'd
have a huge performance impact, if the compiler was smart about inlining
functions.

Just to be clear, I'm talking specifically about: "If a type A supports
func (a A) Plus(A) A, then A3 = A1 + A2 is legal and will be converted at
compile time to A3 = A1.Plus(A2)". For the primatives that already support
+, the compiler would just use whatever asm logic it uses now, and no
run-time performance penalty. There'd probably be a small compile-time hit.

The argument against this that IMO has the most merit is the obfuscation
factor. I think instinctively people understand tha a.Plus(b) could map to
"rm -rf /", but I think all of that math training we've had since we were
wee tots means "a + a" invokes more instinctive assumptions that make
operator overloading inherently more risky.

--- SER

Here's a technical problem with this idea that comes up with == (assuming
the corresponding method is named Equal):

type T struct { /* whatever */ }

func (t1 *T) Equal(t2 *T) bool { ... }

func f() {
a := &T{}
b := &T{}
if a == b {...}
}

This is legal Go today, and means pointer identity. With your suggested
feature, it changes meaning.

There has been discussion many times about this in the past, dealing most often with the use of Go in numerical computing. One of the approaches that has been suggested (I think by Michael Jones) was a numerical dsl or Go-like language to Go compiler. While this complicates the build process I think it has a lot of merit.

Dan

only tangentially related:
https://github.com/remyoudompheng/go-vectops

-s

Neat! (...he says, brain exploding from reading about Haskell tricks
without really knowing Haskell...) But I don't see how that saves you
from insane implementations. It doesn't matter if a function is called
Equal() or __eq__() or operator==(), I can always implement it stupidly:

func (self MyStruct) Equal(other MyStruct) bool {
return self.a == other.b && self.b != other.a
}

or insanely:

func (self MyStruct) Equal(other MyStruct) bool {
if rand.Float64() > 0.9 {
nuclearwar.LaunchICBMs()
}
}

If a language chooses to support operator overloading, it doesn't
really matter how "obj1 == obj2" becomes a call to that method ... the
language can't stop me from writing a crappy implementation. I suppose
a pure functional language could stop me from having side effects
(like nuclear war), but that's an edge case.

Isn't it? Or is Haskell more stupendously powerful than I thought?
(Although it seems unlikely that Go will wake up tomorrow with the
ability to detect and prevent side-effect-ful functions...)

Greg

Sorry, I should have been clearer.

Yes, it's true that Haskell wouldn't let you perform IO in e.g. (==) unless
you use unsafePerformIO to do something outside the IO monad, but my main
point was that in Haskell (and Go) it's trivial to inspect how a given type
implements the Eq type class/"interface" -- in Python it's really hard to
know: did you inherit from a class that override _getattr_/_setattr_, is
your "dict" based on something that inherits from a class that inherits
from a class that overrides how values are retrieved, ...?

I don't mean to imply that == will absolutely do an equality check, just
like implementing a Swap(i, j int) that deletes the items at those indices
from your slice won't actually sort the items if you use sort.Sort. If you
let somebody define what equality means for their own type, then you can't
avoid that. But having the ability to do so is very useful.

Actually, let me change that: I don't think being able to change == is
necessary, but being able to make a function that takes any type that does
equality, or ordering, and using the respective interfaces' methods, is
very useful. Go kind of has that, but you can't pass a slice of values of
type a (which has a Less method) and return a sorted slice of values of
type a, or give the caller a value of type a back from a map of strings to
values of type a.

This argument depends on the operators being a single global function, but
they are not. The operators are in fact overloaded based on their
arguments' type. As you've already mentioned, you cannot treat the
performance implications of adding two integers the same adding two
strings. The proposal would not allow the redefinition of existing
operators, and so do nothing to modify the performance (or the analysis of
performance) of existing operators. Concerns over existing behaviour are
unfounded.

With respect to the custom operators, the performance analysis of
MyCustomNum(1).Add(MyCustomNum(2)) is no different than MyCustomNum(1) +
MyCustomNum(2). As always, you obviously need to be aware of variables'
types when reading code, because their type affects their behaviour. The
behaviour of even a simple expression such as v1 + v2 depends on the type
of v1 and v2 (even in Go, without operator overloading, this is still true).

The real issue is the trade-off between language simplicity and the
capacity to create abstractions. Go is relatively easy to learn because it
is relatively simple. The language is safer, but it is less sharp.

programming languages. But just because a feature does not change the
meaning of existing programs does not mean that feature has no conceptual
cost. By adding possibilities, you increase the burden of understanding
code -- even code that was written before the feature was added. The
fallacy is from the statement "it would not modify the performance of
existing operators" to "it would not modify *the analysis of* performance
of existing operators". The former is true, the latter false, because to
determine whether the mark "+" in the program text is an existing operator
requires more work.

In Go, "+" can only mean addition or string concatenation. Yes, it's
overloaded, but there are only two possibilities, both written down in the
spec. With operator overloading, there are an unbounded number of
possibilities I might have to consider, until I page in the definition of +
for the operand types. That decreases readability. Of course, the same is
true for Add, even in Go. But in Go, at least the operators are fixed by
the language. To coin a phrase, a program's surface of polymorphism -- the
amount of program text whose meaning can vary unboundedly by type -- is
much less in Go than in, say, C++, where essentially everything can vary
except "." and ";".

Your ability to create abstractions is not reduced by the lack of operator
overloading. Just your ability to express those abstractions in a
particular notation.

I partially agree. The language would be more complex, and so more
difficult to understand. However, you've ignored more point below. A + on
two integers will always have the same behaviour. Introducing operators
for other types does not change that. Since you must always be aware of
the types, your burden for understanding code using ints or strings does
not change.

In Go, "+" can only mean addition or string concatenation. Yes, it's
Again, the operations available (i.e. method, functions, operators) for an
expression always depends on the type. You position is similar to saying
that only two or three types can have the method String(), because
otherwise knowing what method will be called in any given situation is too
confusing. In practice, this is not the case. You know which method
String() is called because you know which type is being used. For
operators, it would be the same.

This is a fair point. The OP was suggesting essentially syntactic sugar,
so clearly the same architecture is possible. However, as someone who has
written a lot of numeric code, the readability win from custome operators
is a very big win. It can be taken to far and abused, but it can also
improve readability immensely when used appropriately.

My position is that I'm willing to put up with the uncertainty for
methods, but not for operators.

To me, it's more than just poor naming though. It opens the door for
unanticipated and hidden issues and adds complexity and/or inability to
effectively reason about the performance of the code.

It also adds impetus to map a wide range of unrelated concepts onto a
fairly small set of symbols such as +, -, *, << etc, just to achieve infix
notation. For a perfect example of this, consider how C++ iostream
overloads << and >>.

Overloading of method names or operators is a WIBNI, a
Wouldn't-It-Be-Nice-If feature. It does simplify some code, but it also
introduces a lot of complexity. One of the main attractions of Go is that
it is a simple language. It's possible to know it all and there are very
few corner cases and almost no parts of the language that are best avoided.
The language specification is about 50 pages, including examples. Compare
this to Java or C++. There might be one or two savants who actually know
these languages, but I have still haven't come across anyone who could tell
what the following single line of Java code does:

System.out.println(null);

Hint: think about method name overloading.
Solution: http://www.nada.kth.se/~snilsson/print-null-java/

As others have said, designing a generic language is easier said than done.

Consider your Abs function's interaction with integer constants:

var thousand int8 = Abs(-1e3)

Would this compile? Overflow? Where would it overflow? In the call:

x := -1e3; Abs(int8(x))
Abs(24)
24

Or in the result:

x := -1e3; Abs(x)
Abs(-1e3)
1000
int8(1000)
-24

Eugh... and don't get me started on MinInt ! :)

I realise you were talking generically (pun intended), but whatever generic
solution Go gets (if at all), will have to deal with the rest of the
language.

I feel like operator overloading, for the 'hidden costs' listed elsewhere,
is not a good fit for go. If go were a language where all operators were
syntactic sugar for methods, and even the builtin types implemented those
methods (so that the implementation was solidly consistent), it might be
another matter, but that's not the case.

Re: overloading and generics: overloading is only a small subset of
generics, and I don't think we should be describing generics and
overloading as being the same thing. Overloading could perhaps be done much
more simply alone than what most discussions about "generics" in Go have
centered around, yet most discussions have quickly come to the conclusion
that overloading is not a part of generics that we, as a language
community, feel will be a strong benefit. Given then, that overloading
could be simpler than generics, yet we haven't seen the overwhelming value
of their inclusion, it stands as two reasons against the proposal.

"Generic" discussions, on the other hand, seem to focus on iteration, and
allowing methods to accept the same type as the receiver (guaranteeing
compile-time type equivalence) while still being able to implement the same
interface as types with same-named methods that, in concrete terms, have a
different function type signature. Neither of those scenarios are related
to overloading.

Even in Python, operator overloading doesn't work quite right.
Mixed-mode operations don't necessarily do what you'd expect.

Python overloads "+" for concatenation. This works
for any sequence type, so [1,2] + [3,4] = [1,2,3,4]. But
the array types in the NumPy package also define "+", with
numeric semantics:

array([1,2]) + array([3,4]) = array([4,6])).

Conversions are allowed:
array([1,2]) + [3,4] = array([4,6]))

Python, remember, has duck typing, so if you pass
a Python list to a function that expected a numPy array,
or vice versa, you won't get a compile error. But you
will not get the expected answer, either.

In C++, it's worse. C++ has function overloading,
templates, and automatic conversions. You can have hours of
fun with operator overloading in C++. Visit "boost.org". Lots
of fun templates to try to understand. You'll learn more
about C++ overload resolution rules than you ever wanted
to know. Here's one of the better writeups on this, by
IBM:
http://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/index.jsp?topic=%2Fcom.ibm.xlcpp8l.doc%2Flanguage%2Fref%2Fcplr315.htm

I've done heavy matrix programming in C++; I used to
do physics engines for animation and games. I've written
C++ libraries to help. While it's convenient to be able to
multiply vectors and matrices, it's not a huge help to
be able to write

a * b

instead of

a.matmult(b)

Saving a few characters in the code isn't worth the time
spent trying to figure out what went wrong when something
unexpected happens.

Keep Go simple.

John Nagle

Amen to that. If given only one slide to describe Go that would be my first
bullet point; closely followed by "Good directors cut", "The proof is in
the pudding", and "The devil is in the details".

I remember James Gosling saying that there is a very narrow window in which
to design a programming language. Early on, you don't have enough
experience with the language to make informed design decisions and just a
little bit later, when a lot of people have started to use the language,
there is very little room for change. Go had a very long and fruitful
design period and that's one of the major reasons it's so good. But that
was yesterday. Now is the time to use the language, not the time to
redesign it.

Which is fine if your formula is as simple as a*b. That is quite often not
the case with numerical computing.
It isn't about saving characters, it is about making the formula look more
like its mathematical notation. That makes it much more intuitive and easy
to follow for those who are used to seeing equations on paper.

I do like the DSL idea. One thing that has occurred to me is that it could
be possible for godoc to parse a DSL into LaTeX which could be displayed as
they would be written. This would help to alleviate some of the readability
problems. Since the notation comes from the code itself, one could look at
the LaTeX version and be sure that the actual code is correct.

The trick would be that the DSL needs to be compiled along with the rest of
the Go code. Having to interpret the DSL at runtime would be an efficiency
issue.

Hey, here's a crazy compromise idea: Go could allow operators to be used as
method names but require that they be decorated in some fashion to
distinguish them from built-in operators, for example surrounding them with
backquotes (à la Haskell's "treat as infix" syntax). Thus, a `+` b `*` ccould be syntactic sugar for
a.`+`(b.`*`(c)). This should give the best of both worlds: a visual
distinction between built-in and user-defined operators combined with the
ability to write more readable, math-like expressions.

Oh, and for crazy compromise idea #2, backquotes (or whatever) could more
generally be used, Haskell-like, to invoke a method of type func(T, T) Tusing infix notation. Hence, a
`Myfunc` b would be syntactic sugar for a.Myfunc(b). The differences with
crazy compromise idea #1 are that (1) it adds only a calling convention
without changing how identifiers are lexed, and (2) all such invocations
have equal precedence so one would have to parenthesize to control the
order of operations: a `MyAdd` (b `MyMult` c). Note that these two ideas
are orthogonal to each other.

What do you guys think? Have I finally found a solution to the
operator-overloading versus no-operator-overloading debate that makes
everyone happy?

— Scott

I'm not crazy about the backquotes, but I think your first idea shows promise.

To be clear, nothing in this area is going to change any time soon.

Ian

With Go as-is, you can print abstract functions like this: http://play.golang.org/p/tcQ6QWB_4h
While this doesn't give WYSIWIG code, it can give WYSIWYG unit tests like this:

// Output: ((a+b)*(c/d))
func TestF(t *testing.T) {
a, b, c, d := PrintVar("a"), PrintVar("b"), PrintVar("c"), PrintVar("d")
fmt.Println(F(a, b, c, d))
}

FWIW,
--Glenn

So long as the decorations are chosen to be as unobtrusive as possible, I
could see something like that.

First off, I think that's the most reasonable proposal for operator
overloading that I've seen in go, since it doesn't conflict with things
like sort.Interface's Less method, and the overloaded cases would "stand
out", thus somewhat mitigating the "hidden costs" counter-argument. That
said, I probably would avoid using them on principle, even if added to the
language, and I do see some potential problems that would need to be
accounted for or explained away before the proposal would be consistent
enough to be a candidate feature:

How would order of operations be addressed? Somebody somewhere is going to
complain that, in their particular case, + should have a higher precedence
than *, and since anyone would be able to dispense with sanity anyway (by
having side effects and un-math-like semantics), it'd be hard to argue that
their desire is wrong.

Also, some would desire for any number of consecutive, equivalent,
applications of an operator, to result in a single invocation.

For example, `func(T, ...T) T` instead of `func(T, T) T` -- i.e. `t1 + t2 +
t3` being sugar for t1.`+`(t2, t3)

(an aside: I agree with Ian about the backticks if only because it makes
this syntax difficult to explain conventionally).

This would be important for efficiency if anyone wanted to overload
operators for set logic (when it is generally more efficient to iterate
over smaller sets when performing an intersection). Conceivably people
would also want this capability anyway, "just because", since the door
already would've been opened to potentially insensible behavior.

Also, how would you handle unary operators? `^` as a unary vs `^` as a
binary operator, as well as `+`, `-`, and `<-` ? `&` (address of) and `*`
(deference) would be a bit absurd, but there wouldn't be any consistent
justification in preventing use of those.

If `!` were allowed as a unary method, or `==` as a binary method, would
they be required to return a bool, or could they return T? If they returned
a bool, it would be argued that the mechanism should evolve beyond
syntactic sugar, and that anything implementing `!` be allowed in any
boolean context. For example:

type Boolish struct {}
func (b Boolish) `!`() bool { return true }
if Boolish{} { /* do something */ }

If that were allowed, then it would certainly mean that at least one
predefined interface (the "Banger" interface?) would end up in the language
spec itself, and it'd then be a bit hypocritical to keep out standard
iterator interfaces (special cased by range loops), and to some extent,
making the functionality in strings proper methods on the builtin string,
etc.

I don't necessarily have a problem with that proposal, so long as `+`
converts to a normal plus for the built in types. For the stuff I do, being
able to write code that naturally works for a float input, a complex input,
and a custom input would be a huge win. Something that's more go like would
be http://play.golang.org/p/AnYm0xxqx_ , where a couple of specific
interfaces are provided that allow generics, and the built in types satisfy
those definitions by definition. The problem is knowing what set of
interfaces need to be provided. Would Add, Subtract, Multiply, Divide,
Pow, CastFloat be enough? Most math functions can be defined by those
operations. Since they would be specifically defined, for example, Add
would take a type T and return a type T, they would be less prone to abuse
(though not immune).

Would you really want CastFloat? and what's to then stop someone from
proposing a more fine-grained set of special methods that include
CastFloat32 and CastFloat64? Also, an important property that CastFloat (or
any Cast* name) has is that, unlike the back-tick proposal, suddenly we'd
be conferring special behavior to names that have always been valid Go
method names.

What benefit would come from requiring `+` to transparently work for
builtin types? It would require the parser to be more complex (instead of
potentially just syntactic sugar, it would now require a type determination
and interface implementation check first), and people would waste
keystrokes on making the code non-obvious. Because of the parse
requirement, gofmt wouldn't be able to strip the quotes, and readers would
be confused, looking for a `+` method implementation when none exist for
that type. I personally believe that if the programmer cannot manage to
write + for the non-overloaded behavior, and `+` for the overloaded
behavior, then at the very least, they cannot be trusted to properly
document their code since the readability of such code would be
comparatively nil.

CastFloat is probably the wrong name, maybe it's CastConstNum. Perhaps I
haven't thought hard enough, but I don't know how you would write the
"addOne" function in the code sample I linked if you don't have some way of
converting numeric constants into your custom type. I don't understand your
objections to it as far as special behavior. For any type it would still
be a valid method. It would be a method on a type Foo that takes in a
float64 and returns a type Foo. There is no special behavior there at all.
The special behavior is that Foo satisfies the interface
gennum.CastConstNumer, where normally one cannot write an interface like
that as you can't specify a function that returns a generic type.

The original poster was talking about the ability to write generic math
functions like abs, presumably to work on float32, float64, complex128,
etc. How would that work if '+' doesn't apply to built-in types? You'd
suggest that the programmer has to write his own wrappers around all the
basic types so they can use the abs programmed with `+`?

I was actually suggesting that, for consistency sake, such casting methods
_should_ have special names, just as Scott suggested that the name for a
plus overloaded method actually take on a special syntax which cannot be
used by normal method names. That way, you don't run the risk of a clash
between existing methods/interfaces, and overloading (of which I'd consider
conversions to be the case). Given that Go properly calls the equivalent of
non-pointer C casts "conversions", a non-special method name would probably
be called something like ConvFloat64. However, I actually seriously have
had methods called ConvFloat, so I do know that there's a real possibility
of a naming conflict unless 'special names' (which would not be
syntactically valid in Go 1) are used.

I don't think there's any great need to have a conversion func that
specifically accepts a float64 parameter, since type assertions already
cover that need -- when converting from a builtin type to T, you'd only
need a single method, which takes interface{}, and uses type assertions or
reflection to initialize and return a T value.

I see what you mean with respect to generics. I'd be worried that newcomers
to Go might read something about the generics aspect, and end up using `+`
even in places where they should be using +. They might not correct their
code because they can get away with it. Perhaps compiler enforcement could
mitigate this, such that `+` could not be used in a context where the
operands are concretely defined? I'd still rather that builtin types never,
ever, have methods, and that some kind of code-generation is somehow used
instead to handle the builtins (or invisible runtime functions that cannot
be directly called without unsafe/reflect). This could be done, since
overloaded methods would have special names anyway, and thus could be
special cased. I'm not even convinced that we should allow these overloaded
methods to be specified in interfaces, since doing so would add more
runtime flexibility, thus once again making any kind of generics once again
harder to accommodate -- the quickest way to get any kind of generics
(especially without completely destabilizing the rest of the language)
would be to apply them only to a small, special set of circumstances.

Maybe this is something that could be implemented as an extension to GOWEB
(the literate programming tool).

That's not necessarily a feature. Mathematical notation in advanced
mathematics tends to have implicit conventions which make it hard to
parse. The machine learning community uses superscripts for both
exponents and indices in the same equations. Mathematicians introduce
newly defined operators without specifying their precedence. You're
just supposed to know.

Mathematica has a formal way of dealing with this. Their solution
is to use a rather bulky, but unambiguous, notation. Matlab doesn't
get fancy in this area, either.

Sometimes it's easier to read the Matlab than the blackboard.

John Nagle

To be fair, it's hard to raise a vector to a power, and it's hard to index
into a scalar :)

(I agree with you)

Have a look at BLAS or LAPACK client code. I don't think this is true - the two domains are quite different, one is trying to concisely explain the principles of the idea without reference to concrete implementation, the other focuses intimately on those details and except in trivial cases you would not want it to do otherwise.