Re: [boost] Re: Interest in FC++?

From: Brian McNamara (lorgon_at_[hidden])
Date: 2003-06-26 15:21:19

On Thu, Jun 26, 2003 at 01:36:58PM +0200, Dirk Gerrits wrote:
> Brian McNamara wrote:
> > - Reuse: FC++ "reinvents" a number of Boost's libraries in its
> >      implementation, such as smart pointers and metaprogramming
> >      tricks.  A Boost version of FC++ should reuse Boost libraries for
> >      this.
> 
> I agree. While FC++ probably would bring in a lot of new stuff, there is 
> *considerable* overlap with Boost's current libraries.
> On the function side there's: bind, mem_fn, compose, function, 
> functional, and of course lambda. And then there are smart_ptr, mpl, and 
> preprocessor.
> 
> Reusing will probably make the implementation a lot cleaner, potentially 
> more robust, and ...

I have taken a closer look at what is and is not reusable.  Here's what
I've come up with:

Reusable: 
   smart_ptr: boost::shared_ptr and boost::intrusive_ptr seem to do
              exactly the same thing as fcpp::Ref and fcpp::IRef

   mpl: it looks like some things here, like if_ and find can be reused.
        There may be more, too.

   type_traits: boost::is_base_and_derived replaces fcpp::Inherits

   concept_check: it may be possible to re-use some of the machinery
                  here for reporting "custom error messages".

Non-reusable:
   bind, mem_fn, compose, function, functional, lambda:
      (It looks like much of compose and functional is subsumed by
      bind/lambda anyway.)  FC++ "indirect functoids" are similar to
      boost::function objects.  fcpp::ptr_to_fun is similar to bind 
      and mem_fn.  fcpp::lambda is somewhat similar to boost::lambda.
      In each of these cases, however, none of the boost stuff can be
      reused in FC++, as FC++ uses/requires so-called "full functoids"
      to work.  FC++ must necessarily duplicate these, owing to the
      fundamental differences in the library architecture.

> > - Naming conventions: FC++ uses a naming convention other than Boost's
> >      (including systematically using capital letters in identifiers).
> 
> From what I have been able to tell in such a short time, the 'camel 
> hump notation' is mostly used in the implementation and only slightely 
> so in the interface. For example, things like Fun0, Fun0Impl, ... are no 
> problem because you want to reuse Boost's facilities for these anyway. 
> And the functiods are already 'properly' named in lowercase. Of course, 
> there is some work to be done here, but I don't think it would be a big 
> problem, do you?

It's much more insidious than this.  There are a number of types of
names which use captial letters visible in the client interface to the
FC++ library.  Here are the major categories of examples that spring to
mind:

   Functoids.  Every functoid (like id, map, enumFrom, compose) is an
   instance of a corresponding data type which begins with a capital
   letter (Id, Map, EnumFrom, Compose).  Being able to name the type of
   any functoid is important.

   Data types.  Classes like List and Maybe have names starting with
   capital letters.

   Signature information.  We use names like Arg1Type, Arg2Type,
   and ResultType as typedefs for functoid signatures.

   LEType computer.  Lambda expressions' types are named by the LEType
   computer, which uses some all-caps names like LAM, LV, CALL, etc.

While some of these names are ones that I have made up, and thus can be
changed "on a whim" to lowercase versions, there are still two classes
of naming issues which I hesitate to change:

   Haskell names.  Many functoids (like enumFromTo, takeWhile, zipWith,
   etc.) and datatypes (like Maybe) have the exact same names and 
   behavior as their counterparts in the Haskell programming language.  
   I've named them this way to cater to programmers coming from a
   Haskell background, and am hesitant to change them.

   Functoid types.  The obvious alternative to naming the type of a
   functoid with a leading capital letter (e.g. "compose" has type
   "Compose") is to add a suffix (e.g. make it so "compose" has type
   "compose_type").  Functoid type names are used a lot, though, and I
   am not fond of the idea of making the type names longer than the
   names of the instances.

I dunno if either of the examples above constitutes reason enough to
bend the rules with regards to naming conventions, but I want to ask.
   
-- 
-Brian McNamara (lorgon_at_[hidden])