Boost :

Date view	Thread view	Subject view	Author view

Subject: Re: [boost] [Hana] Informal review request
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2015-03-08 12:59:55

Next message: Louis Dionne: "Re: [boost] [Hana] Informal review request"
Previous message: Sandilya Jandhyala: "[boost] [gsoc15]Request for feedback: Enhanced vector and deque containers proposal"
In reply to: Vicente J. Botet Escriba: "Re: [boost] [Hana] Informal review request"
Next in thread: Louis Dionne: "Re: [boost] [Hana] Informal review request"

Vicente J. Botet Escriba <vicente.botet <at> wanadoo.fr> writes:

>
> Le 07/03/15 21:00, Louis Dionne a Ã©crit :
> > Vicente J. Botet Escriba <vicente.botet <at> wanadoo.fr> writes:
> >
> >> Le 07/03/15 17:38, Louis Dionne a Ã©crit :
> >>> Vicente J. Botet Escriba <vicente.botet <at> wanadoo.fr> writes:
> >> [...]
> >>
> >> Do you have an equivalence in Haskell to your datatype/generalized type?
> > No, but shooting from the hip you could approximate them with type
> > classes.
>
> A type class that is instantiated with another type class?

Like I said, I don't know Haskell well enough to tell whether
there's a direct mapping between data types in Hana and something
else in Haskell. Is there an equivalent to Fusion/MPL tags in Haskell?

> [...]
>
> DoesÐµ•…¹ÌÑ¡…Ðå½Ô…É”…ÍÍ½¥…Ñ¥¹œ„€‰ÁÉ¥¹¥Á…°ˆÑåÁ”±…ÍÌ€(ø€¡½‰Ñ…¥¹•‰äÑ¡”™Õ¹Ñ¥½¸‘…Ñ…ÑåÁ”¤Ñ¼„‘…Ñ„ÑåÁ”°Ñ¡…Ð¥ÌÕÍ•Ñ¼€(ø¥¹ÍÑ…¹Ñ¥…Ñ”Ñ¡”½Ñ¡•ÈÑåÁ”±…ÍÍ•Ìü()$Ý…Ì©ÕÍÐÕÍ¥¹œÑ¡”QÕÁ±”ÑåÁ”±…ÍÌ…Ì„¡…¬Ñ¼€‰É½ÕÀˆÑ¡”€)‘¥™™•É•¹ÐQÕÁ±•8É•ÁÉ•Í•¹Ñ…Ñ¥½¹ÌÕ¹‘•ÈÑ¡”Í…µ”Õµ‰É•±±„¸…¥¸°)$´¹½Ð„!…Í•±°Ý¥é…É…¹Ñ¡•É”µ¥¡Ð‰”„±•…¸Ý…äÑ¼‘¼¥Ð¸(((ø€øøl¸¸¹t(ø€øø¥˜å½Ô¡…Ù”…¸¡•Ñ•É½•¹•½ÕÌÑåÁ”…ÌÁ…¥È™½È•á…µÁ±”°Ñ¡”µ…Ñ¡•µ…Ñ¥…°(ø€øøÑÉ…¹Í™½É´™Õ¹Ñ¥½¸Í¡½Õ±(ø€øø(ø€øø€€€€€€ÑÉ…¹Í™½É´€èÁ…¥È¡P±T¤à€¡P€´øH¤à€¡T€´øL¤€´øÁ…¥È¡H°L¤(ø€øø(ø€øøÌ¬¬¡…Ì½Ù•É±½…‘•™Õ¹Ñ¥½¹ÌÝ”‘½¸Ð¹••Ñ¼Á…ÍÌÑÝ¼™Õ¹Ñ¥½¹Ì°‰ÕÐ(ø€øø©ÕÍÐ…¸½Ù•É±½…‘•™Õ¹Ñ¥½¸¸(ø€øQ¡…ÐÌ…¸¥¹Ñ•É•ÍÑ¥¹œÁ½¥¹Ð½˜Ù¥•Ü¸!½Ý•Ù•È°Ý¥Ñ Ñ¡¥Ì…ÁÁÉ½… °(ø€øå½Ô…¸ÐÍ…äÑB—"—2gVæ7F÷"â—B–ç7FVB&V6öÖW2£ââ&”gVæ7F÷"³%Òà£à£â&–v‡BâgVæ7F÷"†2öæÇ’öæRG—R&ÖWFW"â–â†6¶VÆÂ–÷R6âæ÷B‚ˆˆ˜[œÙ›Ü›HÚÝ[[˜ÙHÝ[™XÙZ]™HÛÈ[˜Ý[ÛœË™YØ\™\ÜÈÙ‚ˆˆH˜XÝ]ÙHÛÝ[›ÝšYHHÚ[™ÛHÝ™\›ØYY[˜Ý[Û‹‚ˆˆZ\Š
HØ[ˆ™HÙY[ˆ\È[ˆ[œÝ[˜ÙHÙˆ[˜ÝÜˆ\È\Ý

HÙ\Ë‚ˆˆÙH™YY[ˆ[X\Âˆˆ[\]HÛ\ÜÈ‚ˆ\Ú[™ÈZ\•HZ\ŽÂ‚”ÙYH™[ÝË‚‚‚ˆˆ]YH›ÝÈ\ÙHH\H[œÝXYÙˆHZ\ˆ\È[ˆ^[\H™XØ]\ÙH]ˆˆÝXÚÜÈ[Ü™HÛÜÙ[HÈÚ]\[œÈ[ˆ[˜H
Z\ˆ\È›ÝH[˜ÝÜ‚ˆˆ[ˆ[˜JK‚ˆ\O‹‹ˆÚÝ[‰Ý™HH[˜ÝÜˆ™Z]\‹‚ˆˆ˜[œÙ›Ü›H[ˆ™XÛÛY\Î‚ˆ‚ˆˆ˜[œÙ›Ü›Hˆ\JK‹‹‹ŠH
HOˆŒJH‹‹ˆ
ˆOˆ›ŠBˆˆOˆ\JŒK‹‹‹›ŠBˆ‚ˆˆš\œÝYˆ[ÝH\ÙH\È\›ØXÚ[ÝHØ[‰ÝØ^H]\H\ÂˆˆH[˜ÝÜ‹ˆ]\ÈÈ™HH‹Q[˜ÝÜ‹ÚXÚthe N-argument
> > equivalent to the BiFunctor. Furthermore, you have to provide
> > N different functions to be able to transform it. So for example,
> > when transforming a tuple(int, int, int), you would have to say
> >
> > transform(tuple(1, 2, 3),
> > [](int i) { return i + 1; },
> > [](int i) { return i + 1; },
> > [](int i) { return i + 1; }
> > )
>
> As pair<T,T>, and list<T> tuple<T,T,T> can be seen as an instance of a
> Functor. But not its heterogeneous variants.

Fine, but what about tuple<T, U, T>? Clearly, transform should
receive three different functions:

    transform : tuple<T, U, T> x (T -> A) x (U -> B) x (T -> C)
                                ->
                          tuple<A, B, C>

And•¹”Ý”ÍÑ¥±°¡…Ù”„€ÌµÕ¹Ñ½È€¡™½ÈÜ½”Ñ¡…Ðµ•…¹Ì¤¸€)$Ñ¡¥¹¬$´ÍÑ…ÉÑ¥¹œÑ¼Õ¹‘•ÉÍÑ…¹Ý¡•É”½ÕÈÙ¥•ÝÌ‘¥Ù•É”è()e½Ô••À½¸ÑÉå¥¹œÑ¼Í•”¡•Ñ•É½•¹•½ÕÌ‘…Ñ„ÍÑÉÕÑÕÉ•Ì±¥”€)ÑÕÁ±•Ì…ÌÁÉ½‘ÕÐÑåÁ•Ì°Ý¡¥ Ñ¡•ä…É”…ÐÑ¡”µ½ÍÐ‰…Í¥Œ±•Ù•°¸()$±¥™ÐÑ¡”ÑåÁ”µÍåÍÑ•´½¹”±•Ù•°¡¥¡•ÈÕÀ…¹Í•”ÑÕÁ±•Ì…Ì„€)™¥á•µ±•¹Ñ …ÉÉ…åÌ½˜½‰©•ÑÌÝ¥Ñ Ñ¡”Í…µ”€‰ÑåÁ”ˆ€¡•¹•É…±¥é•€)ÑåÁ”¤¸Q¡¥Ì…ÁÁÉ½… ¡…ÌÍ½µ”…‘Ù…¹Ñ…•Ì°±¥”‰•¥¹œ…‰±”Ñ¼±½½¬)…Ð½‰©•ÑÌ½˜Ñ¡”QåÁ”‘…Ñ„ÑåÁ”…Ì½‰©•ÑÌ½˜Ñ¡”Í…µ”€‰ÑåÁ”ˆ¸)Q¡½Í”½‰©•ÑÌ…±°¡…Ù”„½µµ½¸¥¹Ñ•É™…”°Ý¡¥ ½ÉÉ•ÍÁ½¹‘ÌÑ¼€)Ñ¡”€ñÑåÁ•}ÑÉ…¥ÑÌø¸(((ø€øQ¡…ÐÌ¹½Ð€‰¡•Ñ•É½•¹•½ÕÌˆÁÉ½É…µµ¥¹œì¥ÐÌ©ÕÍÐ…¸•ÅÕ¥Ù…±•¹ÐÝ…ä½˜(ø€øÝÉ¥Ñ¥¹œ(ø€ø€€€€€€(ø€ø€€€€€ÈÄ€ô˜Ä¡ÐÄ¤(ø€ø€€€€€ÈÈ€ô˜È¡ÐÈ¤(ø€ø€€€€€€¸¸¸(ø€ø€€€€€É¸€ô™¸¡Ñ¸¤(ø€øâv†W&RF¶&RF†RVÆVÖVçG2öbGWÆRÂæBf¶&RF†P£ââgVæ7F–öç2ÖVBöâ—B'’F†RâÔgVæ7F÷"w2G&ç6f÷&Öà£ââv†BvR7GVÆÇ’vçB—0£âà£ââ#Òb‡C£ââ#"Òb‡C"£ââââà£ââ&âÒb‡Fâ£âà£ââv†W&Rf—2FVf–æVB0£âà£ââb¢†–çFW'6V7F–öâöbF†RFFG—W2öbF†RGWÆRw2VÆVÖVçG2£ââÓà£ââ‡6öÖR÷F†W"G—R£â’vÒ7W&RFö–ær7V6‚¶–æBöbG&ç6f÷&ÖF–öç2—2W6VgVÂâ†÷vWfW"F†R[˜ÝÜœÈX]\šX[^™H[\Ù[™\Ëˆ]\Èš[ˆ\ÜÙ[˜ÙH^XÝHHØ[YH[™È\ÈÚ]\[œÈÚ]H\ÚÂ˜Ø]YÛÜžK^Ù\][ÝH™\XÙH\HˆžH™Ù[™\˜[^™Y\H‹‚‚‚ˆˆ[ˆÝ\ˆÛÜ™Ë˜\ÈH[˜Ý[ÛˆÚÜÙHÛXZ[ˆ\ÈHÙ]Ùˆ[ˆˆØš™XÝÈÚ]ÚXÚHØ[ˆÈ‹ˆYˆ\™H\™HØš™XÝÈ[ˆH\Bˆˆ]Û‰ÝÝ\Ü–‹[ˆH›ÙÜ˜[H\È[Y›Ü›YYˆÛÛ˜Ù\ÂˆˆÚ[]\È]XÚÛÜÙ\ˆÈ\Ë‚‚ˆÈ[ÝHYX[ˆÊÊÌMËÌŒÛÛ˜Ù\ÏÈÛÝ[‰Ý\HÛ\ÜÙ\Èˆ[\™OÂ‚–Y\ËÊÊÈÛÛ˜Ù\ËˆH\ÝYX[]ÊÊÈÛÛ˜Ù\ÈÛÝ[[\Âœ]ÛÛœÝ˜Z[ÈÛˆ˜[Z[Y\ÈÙˆ\\ËÚ]Ý]]š[™ÈÈš^Z\‚œ™\™\Ù[][Û‹ˆ‚‚ˆˆË‹‹—Bˆ‚ˆˆÝÈH˜XÝÈ]™HZ]\Kˆ[™X^X™OOˆXZÙ\È][Ü™HYšXÝ[Âˆˆ[\˜XÝÚ]]\›ÙÙ[™[Ý\ÈØš™X?
> > Let's try to implement a type _maybe<A>:
> >
> > template <typename A>
> > struct _maybe {
> > struct empty { };
> >
> > union { A a; empty e; } val;
> > bool is_nothing;
> >
> > constexpr _maybe() : val{empty{}}, is_nothing{true} { }
> > constexpr _maybe(A a) : val{a}, is_nothing{false} { }
> > };
> >
> > Now, let's try to implement, for example, the `maybe` function,
> > which has signature maybe :: B x (A -> B) x _maybe<A> -> B.
> > Remember that those A's and B's are actually generalized types,
> > not usual C++ types (we're working with heterogeneous stuff):
> >
> > template <typename Default, typename F, typename M>
> > constexpr auto maybe(Default def, F f, M m) {
> > €É•ÑÕÉ¸´¹¥Í}¹½Ñ¡¥¹œ€ü‘•˜€è˜¡´¹Ù…°¹„¤ì(ø€ø€€€€€ô(ø€ø(ø€øM••µÌ±•¥ÐüQ¡¥ÌÝ½ÉÌè(ø€ø(ø€ø€€€€€µ…å‰” Ä°mt¡¥¹Ð¤¤ìÉ•ÑÕÉ¸¤€¬€Äìô°}µ…å‰”ñ¥¹ÐùìÅô¤ì(ø€ø(ø€ø ÕÐÑ¡¥Ì‘½•Ì¹½Ð°•Ù•¸Ñ¡½Õ ÍÑèéÑÕÁ±”ðø…¹ÍÑèéÑÕÁ±”ñ¥¹Ðø¡…Ù”(ø€øÑ¡”Í…µ”•¹•É…±¥é•ÑåÁ”è(ø€ø(ø€ø€€€€€µ…å‰” (ø€ø€€€€€€€€€ÍÑèéÑÕÁ±”ðùíô°(ø€ø€€€€€€€€€mt¡¥¹Ð¤¤ìÉ•ÑÕÉ¸ÍÑèéµ…•}ÑÕÁ±”¡¤¤ìô°(ø€ø€€€€€€€€€}µ…å‰”ñ¥¹ÐùìÅô(ø€ø€€€€€€¤ì(ø€ø(ø€ø%Ð™…¥±ÌÝ¥Ñ (ø€ø€€€€€€(ø€ø•ÉÉ½Èè¥¹½µÁ…Ñ¥‰±”½Á•É…¹ÑåÁ•Ì€ ÑÕÁ±”ð¡¹¼…ÉÕµ•¹Ð¤øœ…¹€ÑÕÁ±”ñ¥¹Ðøœ¤(ø€ø€€€€€É•ÑÕÉ¸´¹¥Í}¹½Ñ¡¥¹œ€ü‘•˜€è˜¡´¹Ù…°¹„¤ì(ø€ø€€€€€€€€€€€€€€€€€€€€€€€€€xùùø€€ùùùùùùùùùø(ø(øQ¡¥ÌÍ••µÌ¹½Éµ…°Ñ¼µ”¸()%Ð}¥Í|¹½Éµ…°°‰ÕÐ¥ÐÌ¹½ÐÕÍ•™Õ°¥¸„½¹Ñ•áÐ½˜‘•…±¥¹œÝ¥Ñ €)¡•Ñ•É½•¹•½ÕÌÙ…±Õ•Ì°‰•…ÕÍ”å½Ô…¸ÐÉ•ÑÕÉ¸½‰©•ÑÌbF–ffW&Vç@§G—W2g&öÒF†BgVæ7F–öââv†BvRæVVB—2Fò7F÷&RF†R–æf÷&ÖF–öà§&WV—&VBFòÖ¶RF†B'&æ6‚–âF†RÖ–&Rw2G—RÂæBF†VâvR6âÝ[^™\ÜÚ[Ûˆ[œÚYHH[˜Ý[Û‹‚ˆˆYˆ]Ø\ËÙHÛÝ[\ÙH›ÛÛÏKš\×Û›Ý[™Ï˜È\ÙHÝ™\›ØY[™ÂˆˆÈXÚÈÚXÚœ˜[˜ÚÙIÜ™H^XÝ][™È[œÝXYÙˆÚ[™È]]ˆˆ[[YKZÙHÙHÈšYÚ›ÝËˆ\È\È^Z[™Y[ˆHÙXÝ[Û‚ˆˆÛˆH[Z]][ÛœÈÙˆÛÛœÝ^ˆÌ×K‚‚ˆÙ\È]YX[œÈ][Ý\ˆ]H\\ÈX^X™H[™Z]\ˆ\™H\ØX›HÛ›H\ÈˆY]K\›ÙÜ˜[[Z[™ÈÛÛÏÈHÛ‰ÝÙYHÚ\™HÛÝ[H\ÙH[H][‹][YK‚‚–[ÝIÜ™HšYÚ^H\™H[ÜÝH\Ù[\ÜÈ][[YK\ÝZÙH˜›ÛÜÝŽ›Ü[Û˜[[™›ÛÜÝŽ˜\šX[\™HÛÛ\][H\Ù[\ÜÈ]˜ÛÛ\[K][YKˆ] ÜÈ^XÝHHÚ[È[˜H\ÈHÛY]\›ÙÜ˜[[Z[™×È›Xœ˜\žK‚‚”][Ý[™Èœ›ÛHX^X™IÜÈØÝ[Y[][ÛˆÌ—N‚ˆˆË‹‹—BˆÝÙ]™\‹\™H\È[ˆ[\Ü[\Ý[˜Ý[ÛˆÈXZÙH™]ÙY[ˆˆX^X™H[™::optional: just(x) and nothing do not share
    the same type. Hence, whether a just or a nothing will be
    returned from a function has to be known at compile-time for
    the return type to be computable at compile-time. This makes
    Maybe well suited for static metaprogramming tasks but very
    poor for anything dynamic.

> >
> >> [...]
> >>
> >> My point was more on how the library is checking the fist argument of
> >> Transform is a Functor and that the second argument is a "function" from
> >> the Functor's underlying type T to another type U.
> >>
> >> transform : Functor<T> x (T -> U) -> Functor(U)
> >>
> >> If the implementation declares transform as
> >>
> >> auto transform = [] (auto F, auto Fun)
> >>
> >> Couldn't the the library c¬Ñ¡…ÐÑ¡”…ÉÕµ•¹ÑÌÁ…ÍÍ•¥¸…¹Õ¸(ø€øøÉ•ÍÁ•ÐÑ¡”É•ÅÕ¥É•µ•¹ÑÌü(ø€øe•Ì°‰ÕÐÑ¡…ÐÝ½Õ±É•ÅÕ¥É”Õ¹€ÍÑ…Ñ¥¹œÑ¡…Ð¥Ð¥Ì„™Õ¹Ñ¥½¸(ø€ø™É½´‘…Ñ„ÑåÁ”PÑ¼‘…Ñ„ÑåÁ”T°Ý¡¥ ¥Ì¥µÁÉ…Ñ¥…°¸%¸Á…ÉÑ¥Õ±…È(ø€ø¥Ðµ•…¹ÌÑ¡…ÐÑ¡¥Ìè(ø€ø€€€€€€(ø€ø€€€€€ÑÉ…¹Í™½É´¡µ…•}ÑÕÁ±” Ä°€È°€Ì¤°mt¡¥¹Ð¤¤ì(ø€ø€€€€€€€€€É•ÑÕÉ¸¤€¬€Äì(ø€ø€€€€€ô¤ì(ø€ø(ø€øÝ½Õ±¹½ÐÝ½É¬¸%¹ÍÑ•…½¹”Ý½Õ±¹••Ñ¼ÝÉ¥Ñ”(ø€ø(ø€ø€€€€€ÑÉ…¹Í™½É´¡µ…•}ÑÕÁ±” Ä°€È°€Ì¤°¡…¹„èé™Õ¹Ñ¥½¸ñ¥¹Ð¡¥¹Ð¤ø¡mt¡¥¹Ð¤¤ì(ø€ø€€€€€€€€€É•ÑÕÉ¸¤€¬€Äì(ø€ø€€€€€ô¤¤ì(ø€ø(ø€øQ¡•¸°Í…äå½Ô¡…Ù”(ø€ø(ø€ø€€€€€ÑÉ…¹Í™½É´¡µ…•}ÑÕÁ±” Ä°ÍÑèéÍÑÉ¥¹ì‰…‰Œ‰ô°µå}±…ÍÍíô¤°(ø€ø€€€€€€€€€¡…¹„èé™Õ¹Ñ¥½¸ðüüü üüü¤ø¡mt¡…ÕÑ¼à¤ì(ø€ø€€€€€€€€€€€€€€¸¸¸(ø€ø€€€€€€€€€ô¤¤ì(ø€ø(ø€øQ¡”Ý…ä$Í•”¥Ð°¥ÐÌ©ÕÍÐ¹½Ð½¹Ù•¹¥•¹Ð¸½¥¹œ¥Ð÷VÆ@£ââFVf–æ—FVÇ’f÷&6RW2Fò&RÖF†VÖF–6ÆÇ’6÷'&V7BF†÷Vv‚à£ââ–ç7FVBÂ’–ÒFò6F6‚Ö÷7B&öw&ÖÖ–ærW'&÷'2'’6†V6¶–æp£ââF†Bb—2gVæ7F÷"‡v†–6‚—2V7’’â–b–÷R6VæB–â&æFöÐ£ââgVæ7F–öâÂF†VâF†R6ö×–ÆW"v–ÆÂFVÆÂ–÷Rv†W&R–÷Rw&Rw&öærÀ£ââ'WB†ævöâwBà£âB˜HÙ]ÙˆÛÛ[[ÛˆÛÛ˜Ù\ËÚXÚHžHÈ[X›ÙH[ˆHÛÛ˜Ù\Ù‚™]H\Kˆ\™IÜÈHÛX[Ù[™\˜[^˜][ÛˆZ\ÜÚ[™Èœ›ÛH^H[™\œÝ[™[™ÂÈœšYÙHHØ\™]ÙY[ˆÛÛ˜Ù\È[™]H\\ËÚXÚH[šÈ\™BHØ[YH[ˆH[™ˆÙYHH™[X\šÈ]H[™ÙˆHÙXÝ[ÛˆÛ‚™Ù[™\˜[^™Y]H\\ÈÌ×K‚‚‚ˆH[šÈ]H™YYÈ[™\œÝ[™™]\ˆHØÛÜHÙˆHXœ˜\žK\Èˆ[˜HH\™H[˜Ý[Û˜[›ÙÜ˜[[Z[™ÈXœ˜\žHÜˆ[›Ý\ˆØ^HÈÈ\™HˆY]K\›ÙÜ˜[[Z[™ÈÜˆ›Ý]HØ[YH[YK]™\ÝšXÝYÈHˆ[Z]][ÛœÈÙˆH[\œÙXÝ[ÛÂ‚“ZÙH\Ú[Û‹[˜H\ÈHXœ˜\žH]œšYÙ\È™]ÙY[ˆ[[YH[™˜ÛÛ\[K][YKˆ˜\ÚXØ[K[ÝHØ[ˆX[š\[]HÙ\]Y[˜Ù\ÈÚ]š]\›ÙÙ[™[Ý\ÈØš™XÝÈ[ˆ[K]Z\ˆ[™Ý\ÈÈ™HÛ›ÝÛ‚˜]ÛÛ\[K][YKˆHÛ›ÝÈre's a way to generalize this so that
it works with homogeneous sequences whose size is known at runtime
too, but I'm not tackling this right now.

Then, type-level computations come for free when you have
heterogeneous sequences, but we had just never saw it as
clearly as we do now.

Hana is not just a "pure functional" library that works at runtime.
It's a generalized Boost.Fusion which happens to use concepts from
the functional paradigm because it's convenient.

Regards,
Louis

[1]: https://github.com/ldionne/hana-thesis
[2]: http://ldionne.github.io/hana/structboost_1_1hana_1_1_maybe.html
[3]: http://ldionne.github.io/hana/index.html#tutorial-hetero

Next message: Louis Dionne: "Re: [boost] [Hana] Informal review request"
Previous message: Sandilya Jandhyala: "[boost] [gsoc15]Request for feedback: Enhanced vector and deque containers proposal"
In reply to: Vicente J. Botet Escriba: "Re: [boost] [Hana] Informal review request"
Next in thread: Louis Dionne: "Re: [boost] [Hana] Informal review request"

Date view	Thread view	Subject view	Author view

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk