Re: [boost] [Hana] Formal review for Hana

Subject: Re: [boost] [Hana] Formal review for Hana
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2015-06-16 14:19:07

> > If you find the chaining much cleaner, then perhaps you could make it a
> > pipable function instead:
> >
> >     int_<10> | times([]{ std::cout << "foo" << std::endl; });
> >
> > This way it could still apply to any IntegralConstant.
> «  []
> 
> That's an interesting idea. However, Hana does not have a concept of
> pipable function, so that would need to be added somehow. 

Well, if you use Fit in the future, then Fit already provides the mechanism
for that. 

> Sure, but a proper library-based Optional allows one to represent failures
> caused by more than invalid expressions, which I think is more generally
> useful. For example, you can define a safe division that returns `nothing`
> when you divide by zero. Using SFINAE for this seems like using a hammer
> to
> screw something. Also, Optional allows more sophisticated operations like
> 
>     transform(opt, f) -> applies f to the optional value if it is there,
> and
>                          return just(the result) or nothing.
>     filter(opt, pred) -> keep the optional value if it is there and it
>                          satisfies the predicate
> 
> and many more. Composing optional values like this using SFINAE might be
> harder, IDK. 

I don't see why it would be hard. Plus, there is a compile-time performance
benefit, since the compiler will stop at the first substitution failure.

    
> > > > - Concepts make no mention of minimum type requirement such as
> > > >   MoveConstructible.
> > >
> > > I believe the right place to put this would be in the documentation of
> > > concrete models like `Tuple`, but not in the concepts (like
> `Sequence`).
> > > Hana's concepts operate at a slightly higher level and they do not
> really
> > > have a notion of storage. But I agree that it is necessary to document
> > > these requirements. Please refer to this issue [6] for status.
> >
> > I was thinking more when using algorithms, since tuple will take on the
> > constructibility of its members.
> «  []
> 
> So you mean like since `filter` does a copy of the sequence, the elements
> in
> the sequence should be copy/move-constructible, right? That makes sense.
> See this issue [1].

Yes.

> >
> > Awesome. Have you thought about using a different documentation tool
> > instead, like mkdocs or sphinx?
> «  []
> 
> Yes, I'm currently considering switching away from Doxygen. Though I don't
> know what I'd switch to. I have almost only one requirement; that the
> documentation be written in the source code. 

Well I use mkdocs for Fit, and I write my documentation in the source code,
but
I have a script that slurps them up. Perhaps, mkdocs could be extended to do
this automatically.

> > Well, there is several ways it could be formailised, but either `head`
> and
> > `tail` do not exist for an empty sequence,
> 
> I don't want to use SFINAE to determine this. What if we want to support
> runtime Iterables like std::vector, that only know they're empty at
> runtime? 

Then `is_empty` would be required for runtime sequences.

> > or if `tail` always returns an empty sequence even when empty, you just
> > detect that `seq == tail(seq)`.
> 
> Well, `tail` will fail when called on an empty sequence. But let's assume
> this was not the case. You would then be required to implement `==` for
> your Iterable, which is much more complicated than implementing
> `is_empty`.

Well you could simply rely on `std::is_same`. At least, this only applies to
compile-time sequences, not runtime sequences.

> > > 1. Concatenating ranges does not make sense. A Hana Range is a
> contiguous
> > >    sequence of compile-time integers. What happens when you
> concatenate
> > >    `make_range(0_c, 3_c)` with `make_range(6_c, 10_c)`? It's not
> > >    contiguous anymore, so it's not a Range anymore.
> >
> > Even though concat takes a Range, why can't it just return a tuple
> instead?
> «  []
> 
> `concat`'s signature is
> 
>     M(T) x M(T) -> M(T)
> 
> where M is any MonadPlus. Mathematically, this is similar to the operation
> of a Monoid, except it is universally quantified on T. It would really
> break
> the conceptual integrity

How does it break the conceptual integrity? Isn't a Tuple a MonadPlus as
well?

> (and your expectations abou `concat`)

Well, I find not being able to call `concat` on Range more surprising than
it
returning a Tuple instead of a Range.

> > How is it less usable? It seems like it would be more usable, since the
> > library can now support compilers with no or flaky variable templates.
> «  []
> 
> I simply mean that `int_<1>{}` is less pretty than `int_<1>`. It is longer
> by about 28% and most importantly it defeats the philosophy that we're
> manipulating objects, not types.

I don't see how it breaks the philosophy. `type<T>()` is obviously an
object,
and it looks even more so like an object than a variable template. It is
only
two more characters, and is simpler and cleaner than using the variable
templates.

> At any rate, compilers other than Clang and GCC are probably missing far
> too
> many features (other than variable templates) for them to compile Hana. I
> don't think variable templates would change much to that.

Well, it might be possible to support compilers such as gcc 4.9 or clang
3.4.
Obviously, visual studio will be out of the question for at least another
half
of decade.

> > Using Apple's clang 6, which corresponds to clang 3.5 off of the trunk.
> «  []
> 
> So you're with XCode < 3.6, right? This is not supported, unfortunately.
> I don't know when Apple branched of clang 3.5, or what they did to it,
> but it happily explodes on my computer too. 

Well its Xcode 6.2.

Paul

--
View this message in context: http://boost.2283326.n4.nabble.com/Boost-Hana-Formal-review-for-Hana-tp4676969p4677192.html
Sent from the Boost - Dev mailing list archive at Nabble.com.