Brian Hulley wrote:
Cale Gibbard wrote:
Unifying these two under a single operation is certainly trickier, and it's a little more questionable that it should be done at all, given that their types are so different -- below is the closest I could come to it off-hand. <snip>
Thanks! I'm impressed. Obviously there is a lot more power in type classes than I'd thought.
Of course, this still doesn't solve the original problem I was trying to address, namely that I want identifier bindings to be pulled into scope by their typed context (ie value type or return type + arg types) so that functional programmers could get the same advantages (in fact even more advantages) than OOP programmers. With type classes, every use of any specific identifier, within the whole program, would have to be declared an instance of a single global type class, which would then be imported unqualified into the module so that you could write insert (1,2) m etc without having to qualify the word "insert". (Because if these type classes/instances were imported qualified we'd just swap "Set.insert" for "Collection.insert") With the ty-tuple idea, all functions in a module are automatically organised into sub-modules and brought into scope only when needed, so every function in a program could be typed into a single file thus freeing the programmer from the onerous burden of having to work out where to put them manually. (The programmer would still put data declarations into different modules) I must admit my thinking is strongly influenced by years of C++ programming, but so far I haven't seen any description of how one decides what module a function should be placed in in functional programming, and the existing module system seems like a pauper's alternative to static class methods in C++, C#, or Java, since in Haskell, you need to use the same name for the module and the type (for Data.Set etc) yet this choice of same name is not enforced by the language even though the user thinks of them as being "the same", and in fact two import directives are needed to maintain the illusion that they are the same so you can write Set a and Set.insert etc... Regards, Brian Hulley