Every time that we've added magic, we've lived to regret it and ultimately revert it. If there exists only a single lesson of the past few years of language evolution, let it be this.
Furthermore, any discussions of monads and/or HKT are pie-in-the-sky at this point. Our complexity budget is stretched thin enough as it is. Assume that Rust 1.0 will *not* have these features, and plan accordingly. On Tue, Dec 24, 2013 at 12:09 PM, Daniel Micay <[email protected]>wrote: > On Tue, Dec 24, 2013 at 11:23 AM, Bill Myers <[email protected]> > wrote: > > Some languages support a special "do notation" that allows to express > monadic operations more naturally. > > > > However, there is an even more powerful option, that I'd call "in > notation" (I came up with it, but it's obvious, so I'm sure there's some > language that has something like it). > > > > The idea is that we add an "in" keyword, and in-types, which are the > type "in T" where T is a monadic type. > > > > In-types are physically represented as the monadic type, but > semantically behave like the type contained in the monad; they are > constructed with the expression "in x". > > > > The "out" keyword does the opposite, converting an in-type to the > wrapped type. > > > > Operations performed on in types actually act on the value inside of the > monad, as better specified below > > > > Quick examples: > > out(in Some(3) + 6) gives Some(9) > > out(in Some(3) + in Some(6)) also gives Some(9) > > out(in Some(3) + in None) gives None > > out(in ~[1, 2, 3] + 10) gives ~[11, 12, 13] > > out(in ~[1, 2, 3] + in ~[10, 20, 30]) gives ~[11, 21, 31, 12, 22, 32, > 13, 23, 33] > > > > Internally, when the compiler encounters any expression including an > in-type (expressions include control flow constructs), it proceeds like > this (considering its operands from left to right): > > 1. Optionally, if the expression is correctly typed (e.g. calling a > function that takes an in-type), it compiles it normally > > 2. If the expression does not have an in-type value itself, it converts > the expression into a closure, and passes it to map() > > 2. If the expression does have an in-type value itself (for example in x > + in y has an in-type when viewed as a function of in x, due to the > presence of in y), it converts out(expression) into a closure, and passes > it to flat_map() > > > > Non-movable control flow like return or break is forbidden in expression > involving in-types (they can be implemented with a flag, but that causes > other equivalence issues). > > > > The advantage of this is that special do-notation syntax is not > required, and one can naturally manipulate the values. > > > > The disadvantage is that it adds a layer of "magic", making what the > code actually does less obvious. > > > > This is particularly true with list-like monads, where simple things > like (in x) + (in y) actually become a double loop with quadratic run-time; > this can be optionally avoided by only allowing "in notation" to be used > with monads that call the closure once. > > > > Also, side effects will be performed a different amount of times > depending on the monad values, which may also not be obvious. > > > > Note that there are a lot of details that I omitted for the sake of > brevity, and would need to be handled. > > I'm strongly against adding complex language features like this. > Parser expansion hacks or complex fallback paths have no place in the > language proper. The pattern should be possible to encode in traits > and needs to be proven as a widely applicable form of code reuse with > an insignificant cognitive and performance overhead before discussing > syntactic sugar makes sense. > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
