Hana Typeclass

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Hana Typeclass

Robert Ramey
I can't review the whole library. So I'm confining my observations to just a couple of aspects. My method is
to review some section of the documentation. it looks like a critique of the documentation, but it's really
observations on the underlying design of the library.

In this post I'm addressing Typeclass.  

Typeclass

"Conceptually, type classes are an artifice allowing humans to manipulate objects of heterogeneous types with well-defined semantics.

OK

They serve a purpose very similar to C++ concepts (which are not in yet) and to Haskell type classes, except they do not have language support"

OK - But I would argue that C++ concepts do have library support.  It may not be perfect, but it's good enough for government work.

template <class T>
struct Printable {
private:
    T t;
    std::ostream os;
public:
    BOOST_CONCEPT_USAGE(Printable)
    {
        os << t;
    }
};

"Type classes in Boost.Hana are a library-level implementation of such type constraints allowing us to organize our generic programming."

When I read this it seems to be identical to the definition of what Boost Concept Checking is.

"Getting concrete"

Here is where we start to have problems.  Rather than the simple BCC example above, we've got something a lot more complex and hard to understand. the example

struct Printable {
    BOOST_HANA_TYPECLASS(Printable);
    // This is valid, but it's probably not a good idea unless those are
    // strongly related to the type class.
    int foo;
    void bar() const { };
    struct baz { };
};

Describes what not to do - but doesn't describe what one is supposed to do.

"As you will see later with minimal complete definitions, it is often useful to put other related members in a type class; don't hesitate to do it when it makes sense."  

Upon reading this - we don't know enough to know that "related members" means and what it means to "make sense".

"When I introduced type classes, I said they allowed us to bundle together related operations called methods. This is because type classes can be seen as defining some kind of public interface consisting of the operations that are valid with any object satisfying some constraints"

which is the C++ concept - or my own "type constraint"

"I also said that they made it possible to explicitly state that a type satisfies those constraints, and how it does so"

I would phrase this differently:

explicitly state what operations must be valid when applied to a given type in order to deem it as fulfilling the "type constraints"

"From now on, I will refer to the set of all types satisfying the constraints of a type class T as the instances of T"

A big problem as far as I'm concerned.  In C++ we use the phrase "instance of type T" for an entirely different thing.

I would use the phrase: a "Printable" type - in the case of the example above.  When referring to a set of type constraints I would pick something like "modeling the type constraints T or modeling the Printable type".  This is familiar language to us.

"To associate methods to a type class, we create a layer of indirection through the instance member of the type class. For example, let's say we want to have a method named print in the Printable type class:
…"

The whole rest of this section goes into how to create a set of types modeling "Printable".  OK  - But why is this necessary at all?  If one tries something like:

template<class T>
void f(T & x) {
        BOOST_CONCEPT_ASSERT((Printable<T>));
        std::cout << x;
}

class x {
};

f(x); // compile time error here

the program will trap at compile time with an error inside of Printable indicating that f doesn't model Printable because the operation ostream << x isn't supported by x;  That's what I need.

With type class it looks like that is expected that there be a default implementation for f if x isn't printable. It's not at all clear what this default definition is supposed to do.  Print default error message at runtime? or
what?  The documentation notes that the usage of a default would be rare.  But if it were to be used - it conflicts with the original purpose if type constraints (or concepts or type classes, etc).

It's still not clear to me what happens if I use your type class system and invoke f(x).  Do I get a compile time error? - what kind? where does it point to?  How does it help the user find his error?

To me the "type class" of the Hana library is a muddled re-implemenation of the boost concept check library.  Its much more complicated and subtle and not as well documented and doesn't add anything to BCC.

Robert Ramey
Reply | Threaded
Open this post in threaded view
|

Re: Hana Typeclass

Niall Douglas
On 3 Aug 2014 at 11:32, Robert Ramey wrote:

> To me the "type class" of the Hana library is a muddled re-implemenation of
> the boost concept check library.  Its much more complicated and subtle and
> not as well documented and doesn't add anything to BCC.

You probably didn't mean to Robert, but that review came across as
mean spirited. I'm going to assume you didn't mean it that way, the
same way you didn't mean it that way when you hassled Paul, also a
GSoC student by the way, in his C++ Now presentation about porting
AFIO to Boost.

Hana is different. This student engineer new to Boost and the way
things are done here has tried to break new ground and do new stuff
which demonstrates the power delivered by C++ 14 compilers. He's
taken a very Haskell-y route, right down to the un-C++ terminology
and not using STL idioms, but then so what if he has? The STL is an
ancient legacy design, it may be time to diverge drastically, or it
may not.

I have no idea if what he's done or how he's done it is the best
approach - I'm not competent in this area like Eric or Joel is. But
how he went about the prior art research, the benchmarking of all
implementation approaches, the presentation of his work at C++ Now
before proceeding with implementation, all of this bodes extremely
well indeed. Whatever he has done, it isn't going to be ill judged
and muddled, that's for sure.

Hana isn't BCC. It's far more - it's potentially a hint of how C++ in
the 2020s could look like, which hopefully is not how things are
currently done right now. I hope that the Boost culture is still able
to welcome radically new ideas and new engineers and stride forth
instead of this constant defence of the (ancient) past and its way of
doing things as if we're losing something vital other than our
membership, which if I can remind you, has been dropping for two
years now.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

SMime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Hana Typeclass

Louis Dionne
In reply to this post by Robert Ramey
Robert Ramey <ramey <at> rrsd.com> writes:

>
> I can't review the whole library. So I'm confining my observations to just a
> couple of aspects. My method is to review some section of the documentation.
> it looks like a critique of the documentation, but it's really observations
> on the underlying design of the library.
>
> [...]

Looking at all the discussions about concepts and comments about type classes
that Hana has brought up, I really think I messed up when I tried to answer
the "what are type classes" question in the documentation. The docs marketed
them as something they were not (an implementation of concepts) and poorly
reflected my own view. I'm working on fixing this (and other aspects of the
documentation).

For now, I'd rather have people think of type classes as a Boost.Fusion tag
dispatching system on steroids. It's much closer to that than from C++
concepts, Boost.ConceptCheck and other library implementations of concepts.
Do not forget that Hana is (roughly) a library for manipulating heterogeneous
containers, like Fusion. For users, type classes should have about the same
importance as that of tag-dispatching in Fusion, so that's not a major aspect
of the library, even though the current documentation is misleading on that
point.

Regards,
Louis



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Hana Typeclass

Robert Ramey
In reply to this post by Niall Douglas
Niall Douglas wrote
On 3 Aug 2014 at 11:32, Robert Ramey wrote:

> To me the "type class" of the Hana library is a muddled re-implemenation of
> the boost concept check library.  Its much more complicated and subtle and
> not as well documented and doesn't add anything to BCC.

You probably didn't mean to Robert, but that review came across as
mean spirited. I'm going to assume you didn't mean it that way,
I don't mean to be mean spirited and I haven't made any comments
referring to anything but the documentation and code.  The statement
above accurately summarizes my views after spending a couple of
hours looking at part of the documentation.  I realize that it's not
positive - but I honestly think that Louis is on the wrong track here
and I don't know how else to say this.  
the same way you didn't mean it that way when you hassled Paul, also a
GSoC student by the way, in his C++ Now presentation about porting
AFIO to Boost.
well, I don't remember hassling anyone - at least on purpose.  The
only thing I remember about that presentation was mentioning that
I thought that porting a new library to work with C++03 was
not necessary to be considered for inclusion into Boost.  I thought
was unfortunate that he spent this (considerable) effort and said
that had I known about it, I would have defended a decision not
to do it.  That's all I remember, so maybe I did hassle him.  If
so sorry about that.  If you want to pursue this, feel free tocreate a
separate thread.
Hana is different. This student engineer new to Boost and the way
things are done here has tried to break new ground and do new stuff
which demonstrates the power delivered by C++ 14 compilers. He's
taken a very Haskell-y route, right down to the un-C++ terminology
and not using STL idioms, but then so what if he has?
I understand that.  But when I look at this I'm seeing
a) re-invention of the wheel
b) and the new wheel compares unfavorably with the wheel we
already have.

The STL is an ancient legacy design, it may be time to diverge drastically, or it
may not.
well, algebra is an ancient legacy design - but it's still quite useful.
STL has a number of rough edges - but it had a clear understandable
design so it will be around for quite a while.  Certainly, with C++xx
it might be possible to make something better, but we haven't seen
it yet.  We've seen some hints though - ranges touch on upon this.

constexpr and the "melding" of compile time/runtime programming
will yield something interesting and I suspect that this is what
Louis is driving at.  But we haven't arrived anywhere yet.

I have no idea if what he's done or how he's done it is the best
approach - I'm not competent in this area like Eric or Joel is. But
how he went about the prior art research, the benchmarking of all
implementation approaches, the presentation of his work at C++ Now
before proceeding with implementation, all of this bodes extremely
well indeed. Whatever he has done, it isn't going to be ill judged
and muddled, that's for sure.
I'm aware of this and don't dispute it.  This why  that's why I took
some time to make a good argument based sincere attempt to study
things in depth as far as I could.  I've made a sincere criticism based
on references to specific quotes from the documentation and
examples.  If I'm missing something I'd be happy to hear about it.

Hana isn't BCC. It's far more -
I didn't say that hans is BCC. I said that hana type classes offer no more
than BCC - I stand by that statement.

it's potentially a hint of how C++ in
the 2020s could look like, which hopefully is not how things are
currently done right now.
well, I've been flogging my ideas about how C++/Boost should look
in the future. (So far with very little success).  So I'm not
unsympathetic to changes - in fact I think they are necessary.

I hope that the Boost culture is still able
to welcome radically new ideas and new engineers and stride forth
instead of this constant defence of the (ancient) past and its way of
doing things as if we're losing something vital other than our
membership, which if I can remind you, has been dropping for two
years now.
My view is that Boost needs to improve the quality of it's product.
Boost Libraries need:

a) better design
b) better conceptual integrity - easier to understand, better isolation
between interface and implementation.
c) better documentation - so far the only documentation approach which
has really worked well is that implemented for STL which "formally"
defines type constraints for generic algorithms.  We need to build on
that - not set it aside.
d) Easier tools to make and submit libraries.
e) more submissions
f) more and better peer reviews.

This is what drives me.

Robert Ramey
Reply | Threaded
Open this post in threaded view
|

Re: Hana Typeclass

Joel de Guzman
In reply to this post by Niall Douglas
On 8/4/14, 4:42 AM, Niall Douglas wrote:

> Hana is different. This student engineer new to Boost and the way
> things are done here has tried to break new ground and do new stuff
> which demonstrates the power delivered by C++ 14 compilers. He's
> taken a very Haskell-y route, right down to the un-C++ terminology
> and not using STL idioms, but then so what if he has? The STL is an
> ancient legacy design, it may be time to diverge drastically, or it
> may not.
>
> I have no idea if what he's done or how he's done it is the best
> approach - I'm not competent in this area like Eric or Joel is. But
> how he went about the prior art research, the benchmarking of all
> implementation approaches, the presentation of his work at C++ Now
> before proceeding with implementation, all of this bodes extremely
> well indeed. Whatever he has done, it isn't going to be ill judged
> and muddled, that's for sure.

I'd do it differently, if I were Louis. There was at least one library
a few years ago (FC++) that attempted to get Haskell style into Boost.
It was not accepted into Boost for many reasons such as the alien
abstractions that somehow go against the grain of C++. This is C++,
not Haskell. Another problematic point is the totally immutable design,
again as an outcome of the Haskell lineage. It seems Louis likewise
advertises Hana as immutable/const only. C++ folks embrace references
and non-const operations as part of being C++. Perhaps Louis should
study FC++'s Boost review and learn from it.

That being said, let me go for the record that I think Louis is
doing a splendid job on Hana especially in the way he takes
advantage of advanced C++14 facilities. If he can make it more
C++-ish rather than Haskell-ish, then I think he'll be on the right
track for acceptance.

Regards,
--
Joel de Guzman
http://www.ciere.com
http://boost-spirit.com
http://www.cycfi.com/




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Hana Typeclass

Niall Douglas
On 4 Aug 2014 at 5:59, Joel de Guzman wrote:

> On 8/4/14, 4:42 AM, Niall Douglas wrote:
> > I have no idea if what he's done or how he's done it is the best
> > approach - I'm not competent in this area like Eric or Joel is. But
> > how he went about the prior art research, the benchmarking of all
> > implementation approaches, the presentation of his work at C++ Now
> > before proceeding with implementation, all of this bodes extremely
> > well indeed. Whatever he has done, it isn't going to be ill judged
> > and muddled, that's for sure.
>
> I'd do it differently, if I were Louis. There was at least one library
> a few years ago (FC++) that attempted to get Haskell style into Boost.
> It was not accepted into Boost for many reasons such as the alien
> abstractions that somehow go against the grain of C++. This is C++,
> not Haskell. Another problematic point is the totally immutable design,
> again as an outcome of the Haskell lineage. It seems Louis likewise
> advertises Hana as immutable/const only. C++ folks embrace references
> and non-const operations as part of being C++. Perhaps Louis should
> study FC++'s Boost review and learn from it.
Firstly, I enormously appreciate your feedback here as you're one of
the established domain experts in this space. So thanks for that.

For those interested, FC++'s report is at
http://lists.boost.org/boost-announce/2004/04/0041.php. Worth
reading.

I would add the following points to what you said, bearing in mind I
don't think myself competent in this domain:

1. From my limited understanding, FC++ had to make the compiler jump
around a lot, which made using it frustrating because it ended up
making the compiler create a ton of unnecessary output in order to
remain pure to use. Hana shouldn't have that problem.

2. I am not at all convinced that the STL idiom is appropriate for
compiler programming. With respect, Fusion and Phoenix I found
personally too brittle to use and too steep a learning curve to use
in any of my own code, plus I always struggled personally with why
some bit of design was the way it was and other bits were not (if you
searched as to why, the answer usually was language or compiler
limitations). A Haskell idiom is at least well understood and fully
thought through, and if it can be efficiently implemented by a C++ 14
compiler I would prefer to import a Haskell idiom than to create
something less fully baked and full of design inconsistencies which
steepen learning curves.

3. I personally found the immutability a huge positive in my
conceptualisation, and one I thought was a huge benefit over
Fusion/Phoenix for me. It lets the compiler fold away stuff much
easier, plus my brain likes to think in terms of forward progressions
of collapsing stuff into simple well understood chunks. I absolutely
admit this is probably an artefact of my lack of experience in this
domain, but for me at least as a next gen MPL++ that seemed right on
the money. MPL98 I have used in my own code after all, but anyone who
has used it gets the feeling it should be a lot better in some hard
to pin down kind of way.

> That being said, let me go for the record that I think Louis is
> doing a splendid job on Hana especially in the way he takes
> advantage of advanced C++14 facilities. If he can make it more
> C++-ish rather than Haskell-ish, then I think he'll be on the right
> track for acceptance.

I think he also needs to keep it small and tightly focused to stand a
chance - too many libraries are handed to Boost for review which
overlap others in a non-improving way. It may well be that when he
finishes the table of MPL98 to Hana equivalents the light bulb will
go on for everyone and the way forward becomes clear.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

SMime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Hana Typeclass

Robert Ramey
In reply to this post by Louis Dionne
Louis Dionne wrote
Robert Ramey <ramey <at> rrsd.com> writes:

Looking at all the discussions about concepts and comments about type classes
that Hana has brought up, I really think I messed up when I tried to answer
the "what are type classes" question in the documentation. The docs marketed
them as something they were not (an implementation of concepts) and poorly
reflected my own view. I'm working on fixing this (and other aspects of the
documentation).
Your library needs concepts - just as fusion does.  I don't see how your
"type class" is different.  In fact, looking at my haskell book, I don't see
how haskell type classes are different either. (maybe a little - but not much).
For now, I'd rather have people think of type classes as a Boost.Fusion tag
dispatching system on steroids.
what's tag dispatching? - OK - just kidding (only partially).  But to me it's
really an implementation technique and making it a center piece of the
documentation doesn't uses understand this.  To me, the documentation
should be:

parameterized types
algorithms
  compile time
  runtime

One thing that the documentation needs is a good motivating example(s).
The user should be able to look at this and in 1/2 hour know how this is
going to make his life easier.  Here's an example

the 8 queens problem:

a) class C++ solution using mutable objects, containers, etc.
b) solution using HANA
  1) why it's more verifiably correct
  2) why it's shorter
  3) why it's faster
  4) why it's faster than the same algorithm rendered in Haskell
c) scale to N queens

See http://cppnow.org/schedule-2014/

Regards,
Louis



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Hana Typeclass

cppljevans
On 08/03/2014 05:30 PM, Robert Ramey wrote:> Louis Dionne wrote
>> Robert Ramey
>> <ramey <at>
>>  rrsd.com> writes:
[skip]

>
> One thing that the documentation needs is a good motivating example(s).
> The user should be able to look at this and in 1/2 hour know how this is
> going to make his life easier.  Here's an example
>
> the 8 queens problem:
>
> a) class C++ solution using mutable objects, containers, etc.
> b) solution using HANA
>   1) why it's more verifiably correct
>   2) why it's shorter
>   3) why it's faster
>   4) why it's faster than the same algorithm rendered in Haskell
> c) scale to N queens
>
> See http://cppnow.org/schedule-2014/
>
> Regards,
> Louis

Another good motivating example would be something like spirit,
although, to make a good example, it would have to be extremely scaled
down from spirit, but would have the essentials, such as:

  1) some way to represent a record of recusive equations ( the
     grammar productions ). This record would actually be a sort of
     fusion-like map from the rhs name or "index" to the corresponding
     lhs expression expression.

  2) some way to compile those productions into a record or map of
     recursive parse functions where, again, the map key would be the
     rhs name and the value would be the corresponding parse
     function.  I believe in spirit2 this is what proto did (at least,
     IIRC, there were several transforms with "compile" in their
     names).

I've no idea if this is even possible, but if it is, then to make it
usable, it would have to be as fast or faster to compile than the
current spirit3 implementation which Joel is currently working on:

http://article.gmane.org/gmane.comp.parsers.spirit.general/25490

Compile times were raised as in issue in this thread:

http://article.gmane.org/gmane.comp.parsers.spirit.general/26746

IIRC, Joel used, I think, Argument Dependent Lookup to alleviate the
compile times; however, I can't find the post now. Sorry.

-regards,
Larry









_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost