Hey,
I’m not sure how people feel about Option types but there seem to be a few
hundred uses in the rust codebase. Wanted to share an idea we use in our custom
type system (“Hack”) at Facebook to make it a bit nicer to safely deal with
null references. We don’t use Option types directly. I don’
I, for one, would really like to see rust steal named and optional
arguments from OCaml. They're a huge boon to code readability.
On Tue, Feb 25, 2014 at 10:24 PM, Aran Donohue wrote:
> Hey,
>
> I’m not sure how people feel about Option types but there seem to be a
> few hundred uses in the r
On Tue, Feb 25, 2014 at 7:24 PM, Aran Donohue wrote:
>
>
> Anyway, we like this feature and I'd be happy to see it adopted
> elsewhere.
>
>
There are few languages out there that take an approach like this,
including Kotlin and Fantom. I agree it is a cool feature; however, the
Option type is mor
Turns out Rust's Option type already has all this behavior, so I think
we're all on to something :)
Option is a little more powerful than nullable pointers because you can
have Options of non-pointer values. IIRC, Option<~T> is actually compressed
to be a nullable pointer. I actually really like t
Turns out Option.and_then is literally Option's monadic bind. Both
do-notation and Haskell's list comprehensions (which generalize to monads
and I think are equivalent to Scala's for-comprehensions) actually just
desugar into calls to the monad's bind and return functions (Option's
return is just |
Hey Eric, thanks a ton for this. I knew there was some relationship
between HKT and monads, but hadn't taken the time to read into the
literature. This explanation is exceedingly simple and clear. Thanks.
(and now I _really_ want HKT for Rust, but I understand why it won't
happen immediately.)
___
Eric Reed 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 and List 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.
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 :: *) where
fmap :: (a -> b)
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 wrote:
> Hi, Tobias,
>
> Yes, there is. A monad is a functor by definition, so it has to accept
> a type to produce another
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 <
carter.schonw...@gmail.com> wrote:
> indeed. I wonder how many rust idioms will change once HKT is so
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 g
On 03/03/14 07:27 PM, Carter Schonwald wrote:
> 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
Well, hkt hasn't been done yet so there's that too :-)
On Monday, March 3, 2014, Daniel Micay wrote:
> On 03/03/14 07:27 PM, Carter Schonwald wrote:
> > 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
Tobi, good question!
I see Vladimir already answered, but I'll throw my own answer in too.
I think you can encode HKTs in MPTCs (MPTCs are just relations on types,
HKTs are just functions on types, and functions are specific kind of
relation [you might run into a problem with HKTs being themselves
14 matches
Mail list logo
