Trust me when I say that monadic bind for simple things like option should always be inlined away. In any sane language. This holds just as true in Haskell as in rust. I have many nontrivial examples of monadic bit fiddling codes in Haskell that generate the exact same assembly id expect c to generate.
That said, not every monad is as simple as andThenOption. You may not want to inline monadic bind significantly more complex/interesting monads. That said, any fault in Inlining things which are cheap and suitable to inline should be treated as being faults of the optimizer and constitute examples to include In a optimizer performance test suite, rather than an argument against higher order type traits or abstractions. On Sunday, March 2, 2014, Clark Gaebel <[email protected]> wrote: > As long as monadic bind is usually inlined away, I'll be happy. Needless > closure allocation can add a performance argument against using HOFs. > > > On Sun, Mar 2, 2014 at 12:46 AM, Carter Schonwald < > [email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');> > > wrote: > >> indeed. I wonder how many rust idioms will change once HKT is sorted out? >> (its something i'm very excited to find out :) ) >> >> >> On Sat, Mar 1, 2014 at 2:31 AM, Vladimir Matveev >> <[email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');> >> > wrote: >> >>> Hi, Tobias, >>> >>> Yes, there is. A monad is a functor by definition, so it has to accept >>> a type to produce another type. It can't be represented in another >>> way, at least in Haskell. You can't come up with a sensible definition >>> of a functor without HKT: >>> >>> class Functor (f :: *) <probably something else> where >>> fmap :: (a -> b) -> f -> f -- ??? >>> >>> The above does not make sense at all: you can't specify relationship >>> between a and b in f's codomain, and additional parameters to the type >>> class won't help. >>> Similarly, you cannot make a monad without HKT too. >>> >>> MPTCs with functional dependencies are used in Haskell only to create >>> monad *transformers*. In fact, it is possible to create transformers >>> without MPTCs+FDs (and without type families), but they will be very >>> inconvenient to use - you won't be to obtain transformer operations >>> like (get :: StateT s m a -> s), (ask :: ReaderT r m a -> r) and >>> others for your monad stack for free. >>> >>> 2014-03-01 2:54 GMT+04:00 Tobias Müller >>> <[email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');> >>> >: >>> > Eric Reed >>> > <[email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');>> >>> wrote: >>> >> In general, monads require higher-kinded types because for a type to >>> be a >>> >> monad it must take a type variable. That is, Option<T> and List<T> >>> could >>> >> be monads, but int and TcpSocket can't be monads. So imagine we >>> wanted to >>> >> define a trait Monad in Rust. >>> > >>> > Just for my understanding. Is there an inherent reason that a monad >>> has to >>> > be a higher kinded type (type constructor)? Couldn't it also be >>> represented >>> > somehow as a multiparam trait/typeclass? >>> > AFAIK, higher kinded types are standard haskell, while MPTCs are not, >>> so >>> > it's the obvious choice for haskell. Is it also for rust? >>> > >>> > Tobi >>> > >>> > _______________________________________________ >>> > Rust-dev mailing list >>> > [email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');> >>> > https://mail.mozilla.org/listinfo/rust-dev >>> _______________________________________________ >>> Rust-dev mailing list >>> [email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');> >>> https://mail.mozilla.org/listinfo/rust-dev >>> >> >> >> _______________________________________________ >> Rust-dev mailing list >> [email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');> >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > > -- > Clark. > > Key ID : 0x78099922 > Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
