Boost logo

Boost :

From: joel de guzman (joel_at_[hidden])
Date: 2001-05-25 22:09:20


Hi,

I am having second thoughts with the + operator for
sequencing. At first, it seems to be ok but further
use of the operator gives me a feeling that something
is wrong.

Why I dislike the + for EBNF sequencing:

1) The same reason why I dislike string's + operator for
concatenation. Concatenation and sequencing is *not*
commutative. a + b should be equivalent to b + a. I
feel that this is wrong and should not be propagated.

Among all the other binary operators in Spirit, only this one
violates the basic laws of commutativity as basically understood
of the operator. I believe an accepted non-commutative operator
is more appropriate.

2) EBNF operators [|&-^] are 'set-like' operators. It is
quite common to see | to mean set union, & to mean set
intersection, - to mean set difference and ^ to mean set
exclusive or.

Yet it is also common to see the + operator as a substitute
for set union. Although this is arguable in the view point
of the rule: "when in doubt, do as the ints do", since
a | b != a + b (for integers), some set libraries and even
languages do use the + as a synonym for |. For some this
closely resemble the mathematical set operator (+ enclosed
in a circle).

3) It clashes with the meaning of + in EBNF and regular
expressions which is solely used for iteration and means
repeat one or more. One of the goals of Spirit is to
mimic as closely as possible the syntax of EBNF.

Possible substitutes:

a >> b >> c... The original Spirit syntax. >> arrows denote sequencing.
Non-commutative

a / b / c ... Non-commutative. Similar to unix file paths and URLs e.g.
root/development/c++/myfile.cpp

a % b % c... Non-commutative. A bit of an eye-sore though

So there. I prepared a bit to elucidate my points. I always
want to keep an open mind. Especially since I am aware
that these are well respected people I am dealing with in
this mailing list.

Comments?

Thanks a lot for eveything,
Joel de Guzman


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk