On Thu, Dec 5, 2013 at 5:07 PM, Daniel Micay <[email protected]> wrote:
> On Thu, Dec 5, 2013 at 10:43 AM, Gábor Lehel <[email protected]> wrote: > >> The container types they do have have weird ad hoc overloadings. e.g. Map > >> is treated as an iterable container of pairs, but this means you can't > write > >> code that is parametric in the Traversable container type that can do > >> anything sensible. It is one of those solutions that seems like it > might be > >> a nice idea unless you've had experience programming with more > principled > >> classes like Foldable/Traversable. > > > > Not quite sure what sort of overloadings this is referring to, but > if/when > > we add an Iterable trait, this means that perhaps the impl for maps > should > > iterate only over values, rather than key-value pairs, so that it makes > more > > sense to use the same generic code for both e.g. maps and arrays. (Of > course > > a (key, value) iterator should still be provided separately.) > > > > When we gain higher-kinded types, we should also be able to add the > actual > > Foldable and Traversable traits themselves. > > I think it makes sense to treat a map as a sequence of tuples. When iterating over a map, sure thing. When writing generic code over any kind of container, not so sure. In that case a `Map<K, V>` can be viewed as V values indexed over K keys, while `[T]` can be viewed as T values indexed over `uint` keys -- and so perhaps there should be a separate `IterableWithKey` trait for this kind of thing, where arrays would also be iterated as (index, value) pairs. That said, maybe you wouldn't ever want to write generic code over `Iterable`, only `Iterator`, and so this concern wouldn't actually end up applying. > > >> You wind up with code that looks like myMap.map(...).toMap all over the > >> place due to CanBuildFrom inference woes. > > > > No idea what this is about. > > I think this is similar to `collect` in Rust, where a container type > needs to be provided and usually can't be inferred. I'm not sure how > it could be done differently. > Hmm. Seems like the sort of thing that HKT might help with. > > >> Monads are toys due to the aforementioned restriction. (>>=) is called > >> flatMap. Any chain of monadic binds is going to be a series of non-self > >> tailcalls. A function calls flatMap which calls a function, which calls > >> flatMap... This means that non-trivial operations in even the identity > >> monad, like using a Haskell style traverse for a monad over an arbitrary > >> container blows the stack after a few thousand entries. > > > > Rust is not any better on this front. While we still had segmented > stacks we > > could've handled this, if not in constant space but at least on the > stack, > > but we no longer do. > > > > I'm wondering whether the fact that we're going to have moves and drops > > statically tracked by the compiler might make it more realistic to think > > about TCE again. I think the biggest remaining obstacle would be the > calling > > convention. > > I don't think it's a good idea to add any frontend support for > tail-call elimination. It's not something that's ever going to be > acceptable with optimizations disabled because it drastically changes > debugging. > That seems like something the programmer would be in a good position to make an informed choice about. The other obstacles seem more significant than this one. (I'm assuming that *if* we ever add TCE, it would be have to be invoked explicitly (there's currently the `be` keyword reserved for this, which seems a bit strange, but not as if I have a better idea). So it's not like the compiler would always unconditionally eliminate tail calls and the unsuspecting programmer would be foiled in her debugging. She would be able to pick her poison.) -- Your ship was destroyed in a monadic eruption.
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
