[boost] [qvm] Terseness of syntax etc.

Subject: [boost] [qvm] Terseness of syntax etc.
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2015-12-08 11:25:04

Adam Wulkiewicz wrote:
> The formal review of Emil Dotchevski's QVM library begins today 
> on 7th Dec and ends on 16th Dec.
> Full documentation is also viewable on Github: 
> http://zajo.github.io/boost-qvm/

Following are some comments about the docs and syntax.  This is
based on an earlier look at the library when it was first
announced and a quick look recently to see what has changed.
I've not looked at the source code or tried to use the library.

I wish that the docs started with a page showing how to use the
library's built-in types.  Currently, the first code that is
presented shows how to define traits to make a user-supplied
type work with the library.  This is too advanced for the first
page of the tutorial.  The docs should start by showing how to
do some high-school vector algebra using the built-in vector
and matrix types.

I find most of the identifiers too short.  To give just a couple
of examples: "transp" is used to mean "transpose".  You save
typing three letters, and get confusion with transparent,
transport, etc.  Then look at the names of some traits classes;
elsewhere we have type_traits, allocator_traits, iterator_traits
etc. all spelt out in full, but in qvm we have q_traits, v_traits
and m_traits.  I could go on but really almost every identifier
is too short for my tastes.

I had a quick think about how a struct with x,y,z members could
be adapted.  Am I right in thinking that it would be necessary to
write accessors like this inside the traits specialisation:

float ir(int i, xyz_vec const & v) {
   switch (i) {
     case 0: return v.x;
     case 1: return v.y;
     case 2: return v.z;
   }
}

?  If so, do we think that a compiler would successfully optimise
that when it realised that x, y and z were in contiguous memory?
(I guess you could also have an array of member pointers; would
that work any better?)

I'm really not a fan of the old operator% and now operator, syntax.
To me, (v,XY) looks like you're forming a row-vector with two elements.
Is there a reason why these accessors can't be written with function
syntax, i.e. XY(v) ?  Or, for matrices, something like element<4,2>(m)
rather than (m,A<4,2>) ?

I guess that what we'd really like to be able to do is to override
operator. and write v.XY.  There are proposals for adding operator. to
the core language.  Would those proposals support what is needed here?
Actually, maybe this is closer to another proposal - the unified call
syntax, which would make v.XY() equivalent to XY(v).

I'll be interested to see what others think about these and other
aspects of the proposal.

Regards,  Phil.