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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
