| So, I ask to everybody: would it be right to provide a working low-level | interface, in the IO monad, even if it sucks completely, call it "the | CGA core", and ONLY THEN think about issues as initialization syntax and | a nice way to handle local state? I think it makes sense to have a clear picture of what the *programmer's* interface will look like, and then design the underlying core to support it. Or, perhaps to do both at once. If you do the low-level stuff first, you may find it just doesn't support any decent mid-level interface nicely. (The reverse is also true: one might design a programming interface that is so convenient it's just unimplementable.) After all, the mid-level interface is the goal; the low-level stuff is just a means to that end. However, its true that the fine details of the mid-level interface are not so important (what functions, with what names); it's just the architectural features that matter. | A related issue is that, ideally, the common API should start at as | low a level as possible, so that as much code as possible only needs | to be implemented once rather than separately for each back-end. Indeed so; there is another reason to keep clear sight of the mid-level goal. Simon