Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 15:06

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 24 07:47

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 23 02:04
    pthom commented #432
  • Jan 18 12:46

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 16 22:27
    ricejasonf commented #434
  • Jan 05 06:22
    ricejasonf commented #330
  • Jan 03 11:40

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 02 00:33
    ricejasonf closed #434
  • Jan 02 00:33
    ricejasonf commented #434
  • Jan 02 00:04
    ricejasonf opened #434
  • Dec 27 2018 13:11

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Dec 22 2018 11:56
    pthom commented #432
  • Dec 22 2018 11:55
    pthom commented #432
  • Dec 21 2018 15:48
    pthom synchronize #432
  • Dec 21 2018 09:19
    sdebionne opened #433
  • Dec 21 2018 00:08
    ricejasonf commented #432
  • Dec 21 2018 00:03
    ricejasonf commented #432
  • Dec 20 2018 23:36
    pthom commented #432
  • Dec 20 2018 23:36
    pthom commented #432
  • Dec 20 2018 23:13
    ricejasonf commented #432
Louis Dionne
@ldionne
Hmmm… Would there be a way to prototype something without using Hana per-se? E.g. implementing a similar framework, but naively, which would reduce the complexity of implementing it from scratch by a lot?
Manu Sánchez
@Manu343726
Well, defining a library of concepts using Concepts Lite, and then add those to Hana in the future sounds great for me.
Louis Dionne
@ldionne
Basically, what we’re talking about is implementing Hana’s concept hierarchy (or a similar one) using concepts lite instead of my ad-hoc tag-dispatching system, right?
Manu Sánchez
@Manu343726
Right
Louis Dionne
@ldionne
And then see if we’re able to handle both compile-time and runtime stuff through it?
Manu Sánchez
@Manu343726
Yep
Louis Dionne
@ldionne
Ok, we’re on the same page. Then, it should suffice to consider a very much simplified version of Hana. Basically, it would be useful to see if you’re able to handle compile-time optionals (hana::Maybe) and compile-time sequences (hana::Tuple) through such a hierarchy, but no need to define 1000x algorithms like hana::Sequence does.
Manu Sánchez
@Manu343726
Looking at your implementation, Hana internals are mostly C++11. Template variables, generic lambdas, etc are more part of the user side, right?
Louis Dionne
@ldionne
There’s also generalized constexpr and automatically deduced return type, which are quite important.
But if we’re only considering a barebones frame of the library, without providing a lot of algorithms, we might be able to reduce the requirements to C++11.
Manu Sánchez
@Manu343726
Let's translate your existing concepts to gcc-clite then, and see how they work.
Louis Dionne
@ldionne
Yeah, I think that’s the way to go.
Manu Sánchez
@Manu343726
We could get concepts from range_v3 too.
Louis Dionne
@ldionne
Probably, but I’m not too familiar with the proposal since I’ve been working on Hana. One thing that will probably hurt is the presence of iterators and sentinels. Since we want to have type sequences, an iterator should “point to a type”. When you increment it, the type it points to must change, and so the type of the iterator itself must change. This precludes stuff like iterator++.
Manu Sánchez
@Manu343726
Okay, let's get simple and start with Hana only.
Manu Sánchez
@Manu343726

I don't know what OS/distro you use for development. I'm an ArchLinux guy, so I have submitted a gcc-clite package to the repository: https://github.com/Manu343726/gcc-clite-aur

$ yaourt  -S gcc-clite

should work. It builds gcc from scratch, so be patient and go for a coffee :)

Louis Dionne
@ldionne
I’m on OS X :worried:
I should be able to simply build it by hand
Manu Sánchez
@Manu343726

Check sources https://github.com/Manu343726/gcc-clite-aur/blob/master/PKGBUILD It's just a plain call to gcc configure script plus some sed replaces to fix issues related to the legacy texinfo version they are using for the docs.

mkdir build 
cd build

# Patch texinfo >= 5.0 issues. See https://gcc.gnu.org/bugzilla/attachment.cgi?id=29520&action=diff
sed -i -- 's/@itemx/@item/g' ../gcc-clite-0.3/gcc/doc/*.texi

# Configure (Note --disable.werror)
../gcc-clite-0.3/configure --disable-werror --program-suffix=-clite --program-transform-name='s/^gcc$/gcc-clite/g' --enable-languages=c++

make
make install

Check GCC install docs too.

Louis Dionne
@ldionne
Yeah, I think I’ll be OK. I already have a GCC trunk so I’m familiar with the process (but the first time I did it was f*cking painful).
Louis Dionne
@ldionne
@Manu343726 I’m building GCC-clite right now; everything seems fine so far.
Manu Sánchez
@Manu343726
I'm testing concepts with Turbo. This is so awesome
definitely concepts are the right way to go for algebraic datatypes and typeclasses
Manu Sánchez
@Manu343726
There is no fancy "X does not satisfy Y concept" error message though. Just ignores the template. At least there's no 100k lines error like with SFINAE.
Louis Dionne
@ldionne
Exciting.
Can you put your experiments in a repo so I can watch it?
Manu Sánchez
@Manu343726
sure. I'm playing with Turbo datatypes now. I have added a concepts-lite branch, file examples/main.cpp.
Louis Dionne
@ldionne
Cool, thanks.
Manu Sánchez
@Manu343726
Note the order of concept parameters. It feels reversed for me.
Louis Dionne
@ldionne
I don’t get it. What do you mean?
Manu Sánchez
@Manu343726
Binary concepts such as Comparable<T,U> can be used explicitly via a requires Comparable<T,U> expression. The shorthand is template<Comparable<U> T>
I feel that should be template<Comparable<T> U>...
Louis Dionne
@ldionne
Oh, I get it.
Louis Dionne
@ldionne

Is it possible to constrain template-template parameters with concepts? Imagine the following (flawed) constraint:

template <typename Xs>
constexpr bool Foldable() { return ...; }

template <Foldable Xs>
constexpr decltype(auto) sum(Xs&& xs) {
    return foldl(xs, 0, _ + _);
}

Instead, the correct thing to write would be

template <template <typename> class Xs>
constexpr bool Foldable() { return ...; }

template <typename T>
constexpr bool Monoid() { return ...; }

template <Foldable Xs, Monoid T>
constexpr decltype(auto) sum(Xs<T> /* perfect forwarding magic */ xs) {
    // we also need to define the 0 and + of the Monoid
    return foldl(xs, 0, _ + _); 
}
Is this possible?
Manu Sánchez
@Manu343726
It works! Seems like any kind of template parameter is allowed
Louis Dionne
@ldionne
Awesome. I think Hana could benefit a lot from concepts. It could make a lot of tag-dispatching issues like the need to write sum<int> go away.
Manu Sánchez
@Manu343726
template<template<typename...> class T>
constexpr bool Template() { return true; }

template<Template T>
struct foo
{
    using type = T<int>;
};
Bye bye ugly template-template parameters.
Louis Dionne
@ldionne
lmfao
Wut wait.
Universal non-type template params?
template <typename T>
constexpr bool Integral() { 
    return T is in {int, char, long, ...}; 
}

template <Integral i> 
struct foo { };
Manu Sánchez
@Manu343726
Whaaaaaaaaaaaaaaaaaaaaaaaaaaat?????????? Wait wait wait.
Louis Dionne
@ldionne
I don’t know, I’m just throwing stuff around. My GCC-clite is still compiling :)
Manu Sánchez
@Manu343726
Nooooo, it expects a class :(
Louis Dionne
@ldionne
Too bad.
Anyway, I have to go for a bit, bye.
Manu Sánchez
@Manu343726
Bye
Manu Sánchez
@Manu343726
It's explained on the examples http://concepts.axiomatics.org/~ans/
The implementation only does constraining on types. Note he is still using template functions.
Manu Sánchez
@Manu343726
what's up with your gcc build? were you able to give concepts lite a try?