Ambidexter questions

Although the goals of Ambidexter are stable, some aspects of the language are tentative. Comments and advice are welcome, particularly regarding the topics listed below.

• impurity — This is not a pure functional language. Although Monadic I/O is supported, there are ways in which I/O effects can interact with the internals of non-I/O expressions. I'm pretty sure arrows can bring back purity. Perhaps uniqueness types would be an alternative. Another approach which I am favoring more and more is a hierarchy of continuation functors including pure evaluation and IO.
• back end — Will need to integrate with a back end VM or compiler, with the goals of utility, portability, and support for concurrency. Maybe SEAM.
• modules — Existentials may give decent hiding, but should they be tied to the file system, and if so how? From the opposite point of view, what should be tied to the file system? Limited to existentials? What about names, which is what everyone expects. I did some pretty good thinking about this at one point. Why didn't Haskell go with the ML approach?
• separate compilation — What aspects of separate compilation facility would be first priority?
• currying vs. passing tuples — The builtin functions are oriented toward currying the arguments. Would a version that passes multiple arguments using tuples succeed?
• functions applied from right — This is an experiment, because my intuition has often told me that I'd like to read the argument before reading the thing which transforms it. Although it reads well in expressions, it does not fit together with the way curried types are written — in types the arguments are written in the order they are combined with a curried function, whereas in expressions they appear in the opposite order. Most people will find this unfamiliar, but other than that, are there reasons to switch function application to the usual order? Would there still be reasons if the library didn't use currying extensively?
• by-name types — The type constructs are dual to the intuitive types when working from a by-name point of view. How good and bad would it be to add support for the dual types?