Re: Comments on the preprocessor list data structure

From: vesa_karvonen (vesa_karvonen_at_[hidden])
Date: 2002-01-21 16:16:09

Wait until the end of the message. There is a summary of the new 
naming proposal.

From Gustavo Guerra:
> From: "vesa_karvonen" <vesa_karvonen_at_h...>
> > //! Expands to the I:th element of the list L.
> > #define BOOST_PP_LIST_AT(L,I)
> Don't forget to mention that it starts at 0. Ith is a little 
ambiguous.

Done.

From:  Douglas Gregor
> As a disclaimer: I've not ever used Haskell, and my functional 
programming 
> experience is quite limited in that I've only stumbled my way 
through LISP 
> and ML on occassion; most of my functional programming-like work 
has been in 
> writing template metaprograms. Yet on the C++ side I use STL 
essentially 
> every day.

This is exactly why I already changed "map" to "transform". I 
recognize the benefit in using STL like names, too.

From Gustavo Guerra:
> Would prefer FIRST and REST instead of HEAD and TAIL, though.

hmm... What do other think about these? "First" sounds good, 
but "rest" is perhaps somewhat ambiquous alone (not?). However, I 
think that "tail" is somewhat ambiquous, too.

From "David Abrahams":
> From: "Douglas Gregor":
> > On Monday 21 January 2002 01:22 pm, you wrote:
> > > What do you think about the name "take"?
> >
> > It doesn't give as much information as, say, "get_first" would 
(IMHO). Or
> > even something like "front_N" would make more sense to me.
[...]
> I was looking for this function in elisp recently. It appears they 
use the
> unfortunate name, "butfirst" <snicker>.

:) Unfortunately butfirst is too long, IMO.

What about the following:

  HEAD -> FIRST      (first element of the list)
  TAIL -> REST       (all but first ...)

  TAKE -> FIRST_N    (first n elements ...)
  DROP -> REST_N     (all but first n elements)

From Gustavo Guerra:
> From: "vesa_karvonen" <vesa_karvonen_at_h...>
> > So, you like "fold_left" and "fold_right"?
> >
> > I considered using "accumulate" (and "reverse_accumulate"
> > and "accumulate_left", etc...), but IMO it sounds way too 
arithmetic.
> > Also "fold" is well known concept in functional programming.
> > Furthermore I don't want to make it appear as if either one of the
> > folds would be more primitive.
> 
> "fold_left" and "fold_right" are so much better than accumulate_xxx.
> Maybe fold_l and fold_r instead?

They would be shorter. Currently the _R postfix is reserved for a 
special use (see BOOST_PP_FOR() documentation), but it could be 
changed (but not to _D, because it is reserved for another purpose).

If we want such short names, then I'd probably go for "foldl" 
and "foldr", because they are used in many functional languages. 
Unfortunately they are difficult to read. I'd go with the longer 
names.

From:  Douglas Gregor
> Looking at the folds again, it looks to me like std::transform(). 
Just to be 
> pesky, I think "fold_left" would work well as "transform" 
and "fold_right" 
> would be "reverse_transform."

"transform" (= "map" in several FP languages) is already used and it 
is a close parallel of the STL "transform". Yes, "fold" doesn't sound 
like STL, but I don't like "accumulate", which is the STL equivalent.

From "David Abrahams":
> That said, "accumulate" is an unfortunate name choice, since it is 
so much
> more versatile than that - it's not even neccessarily a numeric 
operation.
> "Reduce", "fold", or the others would have been better names. I 
wouldn't be
> opposed to providing two names in this particular case.

Yes. Most list functions, including "transform" are implemented in 
terms of "fold". "fold" is a sort of a fundamental higher order 
function on sequences. This is also why I don't like the "accumulate" 
name. std::accumulate is defined in the <numeric> header and has a 
distinct numerical flavour. I want to avoid that flavour, because I 
want folds to be used whenever possible instead of BOOST_PP_WHILE.

From Gustavo Guerra:
> Also, can we get a shorter preffix than BOOST_PP_LIST_xxx? Maybe
> BOOST_PPL_xxx?
>
> The change from PREPROCESSOR to PP helped a lot, but things still 
get too
> much verbose.

hmm... Currently there is also BOOST_PP_TUPLE_xxx. A possible option 
would be to drop the data structure prefixes altogether. A couple of 
names would have to change. How about:

  BOOST_PP_LIST_CAT -> BOOST_PP_CONCAT
                    or BOOST_PP_FLATTEN

Both "concat" and "flatten" are used at least in Ocaml (they are the 
same function).

  BOOST_PP_LIST_ENUM -> BOOST_PP_ENUM_EACH

This would parallel the BOOST_PP_FOR -> BOOST_PP_FOR_EACH naming.

For consistency, and to further avoid verbosity, the TUPLE prefix 
could also be dropped (the long names would be obsoleted and 
supported for some time):

  BOOST_PP_TUPLE_ELEM -> BOOST_PP_ELEM
  BOOST_PP_TUPLE_EAT -> BOOST_PP_EAT

I think this would be nice, because BOOST_PP_TUPLE_ELEM() is the 
single most heavily used function of the preprocessor library. 
Actually, I'd like to hear if someone can suggest an even shorter, 
but at least as intuitive, mnemonic than ELEM.

Do these changes sound too bold?

I think that these changes should not bring too many problems. 
Perhaps the biggest problem I see is that it might be difficult to 
find intuitive names for new PP macros at some point. On the other 
hand, I don't see much scope for extending the library in terms of 
new data structures, etc... At the moment, I think that adding more 
data structures would simply be futile.

Of course, I'm not ignoring the problem that it may be a little bit 
more difficult to learn to use the data structures at first, because 
the prefixes do give some cognitive context.

So, here is the naming as I currently find best:
- short enough (to reduce readability problems in PP metacode)
- as close to STL as possible, but not too close

BOOST_PP_LIST_HEAD       -> BOOST_PP_FIRST
BOOST_PP_LIST_TAIL       -> BOOST_PP_REST
BOOST_PP_LIST_TAKE       -> BOOST_PP_FIRST_N
BOOST_PP_LIST_DROP       -> BOOST_PP_REST_N

BOOST_PP_LIST_CAT        -> BOOST_PP_FLATTEN (avoids confusion with 
CAT)

BOOST_PP_LIST_TO_TUPLE   -> BOOST_PP_TO_TUPLE (questionable but 
does...)
BOOST_PP_TUPLE_TO_LIST   -> BOOST_PP_TO_LIST  (...not seem dangerous)

BOOST_PP_TUPLE_ELEM      -> BOOST_PP_ELEM (very heavily used function)
BOOST_PP_TUPLE_EAT       -> BOOST_PP_EAT  (for consistency)

BOOST_PP_LIST_APPEND     -> BOOST_PP_APPEND
BOOST_PP_LIST_AT         -> BOOST_PP_AT
BOOST_PP_LIST_CONS       -> BOOST_PP_CONS
BOOST_PP_LIST_ENUM       -> BOOST_PP_ENUM_EACH
BOOST_PP_LIST_FILTER     -> BOOST_PP_FILTER
BOOST_PP_LIST_FOLD_LEFT  -> BOOST_PP_FOLD_LEFT
BOOST_PP_LIST_FOLD_RIGHT -> BOOST_PP_FOLD_RIGHT
BOOST_PP_LIST_FOR_EACH   -> BOOST_PP_FOR_EACH
BOOST_PP_LIST_IS_CONS    -> BOOST_PP_IS_CONS
BOOST_PP_LIST_IS_NIL     -> BOOST_PP_IS_NIL
BOOST_PP_LIST_NIL        -> BOOST_PP_NIL
BOOST_PP_LIST_REVERSE    -> BOOST_PP_REVERSE
BOOST_PP_LIST_SIZE       -> BOOST_PP_SIZE
BOOST_PP_LIST_TRANSFORM  -> BOOST_PP_TRANSFORM