Re: [boost] [qvm] Terseness of syntax etc.

Subject: Re: [boost] [qvm] Terseness of syntax etc.
From: Francois Duranleau (xiao.bai.xiong_at_[hidden])
Date: 2015-12-08 14:07:45

On Tue, Dec 8, 2015 at 11:25 AM, Phil Endecott
<spam_from_boost_dev_at_[hidden]> wrote:
> 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 found the documentation indeed poor in concrete/complete examples
(and the unit tests don't help much).

> 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?)

There is also the function r, for which i is a template argument.

> 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>) ?

Plus, did I miss or there are no accessors with a dynamic index value?
(I guess I missed it, because where ir as mentionned above).

> 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.
> http://lists.boost.org/mailman/listinfo.cgi/boost

I totally agree with all you said. In addition, I would shy away from the X,
Y, Z (and combinations) accessors using capital letters in order to
avoid clashes with macros
(I recently hit a clash with a struct member I named B0 and a macro in
some Android system header; there is no B0 here, but I just want to
illustrate the protential problem).

-- 
François