RE: locating package.conf II
In July 2003, a discussion in this list named locating package.conf (http://www.haskell.org/pipermail/glasgow-haskell-users/2003-J uly/005511.htm l) concluded that make install on Windows is not supported. Has this evolved since then? No, 'make install' is still not supported on Windows, sorry. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Package with no dependencies causes GHC to mislay standard prelude
Unpacking the attached bundle and running the following with ghc=GHC6.2 (Linux, compiled from the ghc-6.2 tag), produces the following: # cd packagesbug /home/ger/test/packagesbug # CompileBug /home/ger/test/packagesbug/package1 Chasing modules from: CompileFlags.hs Compiling CompileFlags ( CompileFlags.hs, CompileFlags.o ) Reading package info from stdin... done. Expanding embedded variables... done. building GHCi library `/home/ger/test/packagesbug/package1/package1.o'... done. Saving old package config file... done. Writing new package config file... done. Chasing modules from: UseCompileFlags.hs Compiling UseCompileFlags ( UseCompileFlags.hs, UseCompileFlags.o ) /home/ger/test/packagesbug/package1/package1.o: unknown symbol `__stginit_Prelude_' Loading package package1 ... linking ... ghc-6.2: panic! (the `impossible' happened, GHC version 6.2): can't load package `package1' Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. packagesbug.tar.bz2 Description: BZip2 compressed data ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Generics... no Tuples 2 either...
Yes, sorry about that. We'll add them shortly. (It's nice to know that someone is using this stuff!) Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] On Behalf Of Abraham Egnor | Sent: 26 February 2004 22:18 | To: MR K P SCHUPKE | Cc: [EMAIL PROTECTED] | Subject: Re: Generics... no Tuples 2 either... | | I've been frustrated by the same lack of instances; as a stopgap, here's | one for a three-tuple. The pattern is pretty clear and can easily be | extended to whatever size you'd like. | | tupCon = mkConstr 1 (,,) Prefix | | instance (Data a, Data b, Data c) = Data (a, b ,c) where | gfoldl k z (a, b, c) = ((z (,,) `k` a) `k` b) `k` c | toConstr _ = tupCon | fromConstr _ = (undefined, undefined, undefined) | dataTypeOf _ = mkDataType [tupCon] | | MR K P SCHUPKE [EMAIL PROTECTED] writes: | | Any chance of Data instances for tuples of size | greater than 2... One of the nice things about generics is | you can use them by deriving Data on your datatypes - of | course this doesn't work if you all of a sudden have to | put a load of boiler-plate in just to use tuples... | | Regards, | Keean Schupke | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | | | | | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] performance tuning Data.FiniteMap
[Moving to GHC users list] There are several things that aren't research issues: notably, faster copying, fewer intermediate lists, fewer state-monad-induced intermediate closures. These are things that would move sharply up our priority list if you had a real application that was stumbling on them. What I obviously can't promise is that improving these things would solve your problem -- if, indeed, you turn out to have one! Simon | -Original Message- | From: S. Alexander Jacobson [mailto:[EMAIL PROTECTED] | Sent: 26 February 2004 23:27 | To: Simon Peyton-Jones | Cc: [EMAIL PROTECTED] | Subject: RE: [Haskell] performance tuning Data.FiniteMap | | Is fixing GHC arrays a big research job or is it | something that someone can straightforwardly | handle if my site actually gets enough traffic to | warrant it? | | -Alex- | | On Thu, 26 Feb 2004, Simon Peyton-Jones wrote: | | | But in managing this tradeoff, what is faster: | | * constructing/destructing e.g. 16 trees (for a 65000 item table) | | * 2 memcpy of 256 item arrays (perhaps after you primop?) | | | | If the later is not dramatically slower than I | | will bias towards more arrayness. | | I doubt the latter is dramatically slower, but you'd have to experiment | to find out. And GHC is not doing as well as it should on arrays just | now. (One of the things on our to-do list.) Might vary between | implementations too. | | Simon | | | _ | S. Alexander Jacobson mailto:[EMAIL PROTECTED] | tel:917-770-6565 http://alexjacobson.com ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] Per-type function namespaces (was: Data.Set whishes)
The idea that I've been throwing around is to be able to define a separate namespace for each type; a function can either belong in a global (default) namespace, or belong in a particular type's namespace. So, in the above example, instead of writing addToFM fm ..., we could instead associate an 'add' function with the FiniteMap type, so we could write fm.add ... instead. Provided that fm's type is monomorphic, it should be possible to call the 'correct' add function; if we defined another 'add' function that's associated with Remember, too, that in OO languages the type of 'fm' is usually declared, in advance, by the programmer. In Haskell it isn't. That makes it much harder to figure out which 'add' function is going to be used. Which 'add' function is chosen depends on type type of 'fm'. But the add function that is chosen in turn influences the type of the other arguments. For example, in the call (fm.add foo), the type of 'foo' is influenced by the choice of 'add'. But the type of 'foo' might (by the magic of type inference) affect the type of 'fm' In Haskell today, you can at least tell what value is bound to each identifier in the program, *without* first doing type checking. And the binding story, all by itself, is somewhat complicated. The typing story is also (very) complicated. Winding the two into a single indissoluble whole would make it far more complicated still. My nose tells me that this way lies madness. But I've been wrong before. Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Per-type function namespaces (was: Data.Set whishes)
On 27/02/2004, at 9:51 AM, David Bergman wrote: So at the moment, many Haskellers will append the type name to the function to indicate that it only works on that particular data type. In this respect, Haskell is at a disadvantage vs most object-oriented languages, because in them, you can write x.add, and the type system will perform object-oriented polymorphism for you and call the correct add method, no matter if x is a FiniteMap or a Set. Writing addToFM fm ... or addToSet set ... is surely a lot more inconvenient than writing fm.add or set.add, no? Yes. But, you are refering to overloading, no? And, not subtype polymorphism (which is what I denote with object-oriented polymorphism)? Just to make things clear in my mind. Yes, what I'm referring to is essentially overloading. I called it object-oriented polymorphism because that's typically what OO people call such a thing :). (I should know better to use OO terminology on a Haskell list; won't happen again ...). However, it's form of overloading that Haskell cannot currently handle well with type classes -- Oleg's post proves that you can do it, of course, but that's a (very good) hack rather than a long-term solution. So, you have thought of automatically, but implicitly, introduce a namespace for each data type, and then have Haskell employ Koenig Lookup, to decide which function an expression is refering to? It's a bit like Koenig lookup in that it has the same effect, although it's probably easier for the compiler to infer the namespace wanted, since we write expr.function ... rather than function expression Writing function expression ... would work too, but then it looks like a standard function call rather than a function call associated with a particular type, and I think that causes more confusion. Long-time Haskell users understand that writing foo.f means use f in namespace foo; changing around the language semantics to mean that f foo now means use f in namespace foo would make lots of people rather unhappy :). You realize, of course, that mere intranamespacial parameter type lookup (regular overloading) would achieve the same effect, without the (implicit) namespaces? I'm not sure what you mean by intranamespcial parameter type lookup -- can you explain? There are a number of means by which the x in x.add can be communicated to the actual function: it's similar to the hidden 'self' or 'this' variable that's present when you invoke a method on an object in OO. Perhaps x is passed to the function as its first parameter, or maybe it could be its last parameter, or even an arbitrary parameter (where the parameter it's passed as could be defined in the type signature of the function). Perhaps 'self' or 'this' could be an implicit parameter. Any one of them will work just fine, I think. Again, I think you are confusing the runtime dispatching subtype polymorpism from overloading. Overloading would do what you want, while the subtype polymorphism could (still) be handled by class, and instances of classes, the Generic Programming way. I (think I) understand the difference between dynamic binding vs overloading: here, all I'm after is trying to use the type system to give us a very simple form of overloading (e.g. based on the first argument to a function), that gives us the same effect as a per-type name space. -- % Andre Pang : trust.in.love.to.save ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Per-type function namespaces (was: Data.Set whishes)
On 27/02/2004, at 4:48 PM, Brandon Michael Moore wrote: On Fri, 27 Feb 2004 [EMAIL PROTECTED] wrote: On 27/02/2004, at 1:13 PM, [EMAIL PROTECTED] wrote: 1) now I have to manually declare a class definition for every single function, and I have to declare it in advance before any module defines that function (most serious problem; see below), 2) I then have to declare instances of that type class for every function I define, 3) the type signature for phase reveals no clues about how to use that function. Declaring a type class instance is really no problem. I agree that declaring a type class instance per function is not a huge deal (if it can be automatically done by the compiler). However, declaring the instance first requires declaring the type class itself, and that _is_ a problem, because that's exactly what I'm trying to work around. Without 20/20 hindsight, you cannot say with certainty what type signatures a generic function (like 'phase' or even 'add') can support, because it's not a generic function, it's a function which is When you declare a type class, you are making a trade-off: you are saying that the interface for this function is forever set in stone, and it cannot be changed by any instances under any circumstances. In return for saying that interface is immutable, you get two major benefits: (1) an immutable interface, i.e. so you can guarantee that whenever you use ==, you _know_ the type signature is :: Eq a = a - a - Bool, and no instance can try to subvert that (unless your name is Oleg ;), and (2) you get very powerful overloading capabilities. However, the disadvantage of this tradeoff is that because the type signature is now set, you just used up another function name in the namespace. So type classes are the wrong approach to solve this problem, because what I'm after is being able to clutter up a namespace as much as I like with whatever names I like, but I don't want a polymorphic function--I want a function which only operates on one specific, primary data type. With the per-type namespace separation I'm advocating, you do not need to know and declare in advance that each function will be overloaded, you simply write a FiniteMap.add function and a Set.add function, and you get a simpler form of namespace separation (or overloading) based on the first parameter that's passed to it. It is a solution which is more _flexible_ than requiring type class definitions, and it is better than having hungarian notation for functions. In fact, I think that, right now, if we replaced the current namespace separation offered by the hierarchical module system, and instead only had this sort of per-type namespace separation, things would still be better! How much of the structure of the first paramater would you look at? Could you an implementation for pairs that depended on the actual types in the pair? I think you should try to take advantage of the existing type class machinery as much as possible here, even if what you want are not exactly (standard) type classes. The idea is if you write fm.add, you look at the type of fm as much as possible. If you see that fm is polymorphic, all bets are off, and the compiler raises an error and quits with prejudice. If fm is monomorphic, you should be able to infer its type (which includes pairs/tuples) and thus know which namespace to select to find the correct add function. So the main requirement for this to work is whether it's possible to infer the type of fm; since I'm not a type theorist, I have no idea if that is in fact possible at all. I realise my idea isn't very general in that it only allows this namespace lookup/overloading based on the type of a single argument parameter, and I think it would be possible with a bit more thinking to generalise it to work based on multiple arguments (e.g. via argument-dependent lookup, or whatnot). But even in its current form, I honestly think it offers far more flexibility and would lead to cleaner APIs than is currently possible. Read the paper and see if you think something like that might be useful. In any case, I think there's a decent chance that something useful for this would also be useful for building interfaces to object-oriented libraries, and vicea versa. I think there's probably something that covers both cases nicely and uniformly. I've had a read of both the SPJ/Shields paper on OO-style overloading in Haskell, and I've also had a skim over another paper called A Second Look at Overloading which describes another overloading calculus called System O. I don't think either paper directly addresses the problem I'm trying to solve, although some elements in the paper (e.g. closed classes) may provide a framework which is capable of addressing the problem, if something like fm.add can be translated to such a framework via major syntactic sugar :). -- % Andre Pang : trust.in.love.to.save
RE: [Haskell] Per-type function namespaces (was: Data.Set whishes)
At 09:28 27/02/04 +, Simon Peyton-Jones wrote: Which 'add' function is chosen depends on type type of 'fm'. But the add function that is chosen in turn influences the type of the other arguments. For example, in the call (fm.add foo), the type of 'foo' is influenced by the choice of 'add'. But the type of 'foo' might (by the magic of type inference) affect the type of 'fm' In Haskell today, you can at least tell what value is bound to each identifier in the program, *without* first doing type checking. [...] Nicely explained. Until this, I had a feeling that the proposed type-directed value-binding resolution was potentially problematic for Haskell, but couldn't say why. #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] Per-type function namespaces (was: Data.Set whishes)
On Fri, 27 Feb 2004, Simon Peyton-Jones wrote: The idea that I've been throwing around is to be able to define a separate namespace for each type; a function can either belong in a global (default) namespace, or belong in a particular type's namespace. So, in the above example, instead of writing addToFM fm ..., we could instead associate an 'add' function with the FiniteMap type, so we could write fm.add ... instead. Provided that fm's type is monomorphic, it should be possible to call the 'correct' add function; if we defined another 'add' function that's associated with Remember, too, that in OO languages the type of 'fm' is usually declared, in advance, by the programmer. In Haskell it isn't. That makes it much harder to figure out which 'add' function is going to be used. Which 'add' function is chosen depends on type type of 'fm'. But the add function that is chosen in turn influences the type of the other arguments. For example, in the call (fm.add foo), the type of 'foo' is influenced by the choice of 'add'. But the type of 'foo' might (by the magic of type inference) affect the type of 'fm' In Haskell today, you can at least tell what value is bound to each identifier in the program, *without* first doing type checking. And the binding story, all by itself, is somewhat complicated. The typing story is also (very) complicated. Winding the two into a single indissoluble whole would make it far more complicated still. I thought this wasn't the case if there are type classes invovled. What value is + bound to in 1 + 1? All I can think is to say that the appropriate value of + is selected based on the types, or to say that the value here is the class member (subsuming several instances). Either way I don't see a method for overloading individual function names having a greatly different story either way. Actually, picking a version of a function (from the versions in scope) based on which type actually works might be useful. It seems to extend the handling of overlapping names in a useful direction again, resolving ambiguity by assuming you meant to write a typeable program. We would probably want some special syntax with the imports to request/flag this behaviour, like import A; import B; import C; resolve foo. One heuristic would be typechecking with no information on the name(s) and checking that there is a unique way to resolve the ambiguity at each point. My nose tells me that this way lies madness. I think the general principle of using types to capture and infer intent is still sound. It would be nice to have ad-hoc overloading also in cases where we don't see a common intent between several functions to capture with a typeclass (intents that we can't capture are arguments for improving the class system). A lot of haskell already looks like madness already anyway :) We just need to find things that look like good madness ;) But I've been wrong before. Simon Brandon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Regular Patterns (RE: [Haskell] regular expression syntax)
Subject: [Haskell] regular expression syntax - perl ain't got nothin on haskell Agreed, Perl certainly ain't got nothing on Haskell, but we could go even further than just imitating (although better than the original) Perl functionality. =) Hence: As a spin-off of another project [1], we found ourselves in need of a nice way of expressing regular expression matching in Haskell, and not only for strings. We came up with the idea of HaRP: Haskell Regular Patterns. We have implemented this as a pre-processor to ordinary Haskell and it works quite well. However it is something we are still working on, and if it hadn't been for this discussion on the list we would probably have waited a few weeks more before presenting it, but here goes: Simple pattern matching on concrete, fully specified lists can be done in Haskell as so: foo [Foo, Bar, Baz] = ... We propose an extension of this to regular pattern matching, example: foo [/ Foo Bar* Baz /] = ... The intuition of the above is that we get a match for any list that starts with a Foo, ends with a Baz, and has zero or more Bar in between. Regular patterns that can be used are: * - match zero or more + - match one or more ? - match zero or one a | b - match a or b (/ a b /) - match the sequence of a, then b (this is also implicit in the top level [/ ... /]). Applying the regular expressions on patterns gives some extra nice features. One is that the regular patterns are type safe, i.e. they are not encoded in strings. Another is that identifiers can be named and bound inside regular patterns, examples: foo [/ _* a /] = ... = a is bound to the last element of the list foo [/ a@(/ _ _ /) _* /] = ... = a is bound to the list containing the first two elements foo [/ (/ a _ /)* /] = ... = a is bound to the list of the first, third, fifth etc elements of a list of even length Note that since we introduce bindings of identifiers inside what we call numerating patterns, i.e. patterns that imply an uncertain number of matches, identifiers are automatically bound to lists inside such patterns. We also introduce an explicit list-binding operator, @:, for accumulating items in lists as so: foo [/ (_ a@:(/ _ _ /))* /] = ... = a is bound to a list of lists (exactly what the elements will be is left as an exercise to the reader ;) The types of sub-patterns are as follows (a :: a, b :: b): a* = [a] a+ = [a] a? = Maybe a (/ ... /) = [e], where e is the type of the elements in the list matched, regardless of sub-patterns ( a | b ) = Either a b As more complete example using all the presented features: foo [/ _ [EMAIL PROTECTED] b [EMAIL PROTECTED] 4+ [EMAIL PROTECTED] e@(/ f@:6 g /)* h@( 8 | (/ 9 i /) ) /] = (a,b,c,d,e,f,g,h,i) Assuming all the numerical literals are of type Int, foo will have the following type: foo :: [Int] - (Int, Int, [Int], Maybe Int, [[Int]], [Int], [Int], Either Int [Int], [Int]) Examples of applying foo to some lists: ? foo [0,1,2,3,4,5,6,7,8] (1, 2, [3], Just 5, [[6,7]], [6], [7], Left 8, []) ? foo [0,1,2,3,3,3,4,6,0,6,1,6,2,9,10] (1,2,[3,3,3], Nothing, [[6,0],[6,1],[6,2]], [6,6,6], [0,1,2], Right [9,10], [10]) Discussion of each variable in detail: a :: Int - a binds to a single element at top level (top level meaning it is bound outside any numerating pattern). b :: Int - b binds to a single element at top level. c :: [Int] - c is bound to a zero-or-many pattern, and it will contain all the matches of the sub-pattern, in this case all matches of 3. d :: Maybe Int - d is bound to a zero-or-one pattern, and it will be Nothing in case of zero matches, and Just the match to the sub-pattern in case of a match, in this case 5. e :: [[Int]] - e is bound to a zero-or-more pattern, and will thus contain a list of all the matches of the sub-pattern. In this case the sub-pattern is a sequence, which has a list type, so the type of e is a list of lists. f :: [Int] - f is bound using the list-binding operator @:, so its type will always be a list of the type of the sub-pattern, regardless of the context it appears in. It will contain all matches of the sub-pattern (Note that a normal bind using @ would have been illegal here). At top level (and in ordinary pattern matching), the pattern foo is equivalent to [EMAIL PROTECTED], but inside numerating patterns the pattern foo is equivalent to foo@:_. (see discussion below) g :: [Int] - g is equivalent to g@:_ as mentioned above, so the same will hold for g as for f. h :: Either Int [Int] - h is bound to a choice pattern (or union pattern if you prefer), so it will be bound to the match of one of the two sub-patterns, annotated with Left or Right. In this case the left sub-pattern matches a single element of type Int, whereas the right sub-pattern matches a sequence of type [Int]. i :: [Int] - Since the choice pattern is numerating (each of the sub-patterns are matched zero or one times), i is equivalent to i@:_. For completeness, another example to show how
Re: Regular Patterns (RE: [Haskell] regular expression syntax)
Niklas Broberg wrote: .. We came up with the idea of HaRP: Haskell Regular Patterns. taking data and patterns as typed trees obviously is the right thing (tm). in principle, such patterns describe regular tree languages (if we disregard nested data types for the moment - they give CF languages) and they could be translated into finite tree automata, which leads to fast matching algorithms (but cost some preprocessing time). you want to always return exactly one match (or none)? this forces you to make ad-hoc decisions (longest/shortest match etc.) when defining the semantics. I think a lot of similar issues are being discussed w.r.t. XML processing. see http://citeseer.nj.nec.com/388107.html and many others. -- -- Johannes Waldmann, Tel/Fax: (0341) 3076 6479 / 6480 -- -- http://www.imn.htwk-leipzig.de/~waldmann/ - ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Per-type function namespaces (was: Data.Set whishes)
In my humble opionon explicit module prefixes are a feature, which enhance code clarity, and not something you want get rid of using rather complex namespace extensions. However, as Alastair Reid's mail in this thread indicates there are weaknesses in haskell's export mechanism. But these would be far more easy to fix than introducing the suggested per type namespace extension. The present export list is also rather ugly from an aesthetic point of view, clottering the module header. I would love to see an, repeatable, explicit 'export' directive with similar keywords as the import directive. Allowing for example: 'export [all] hiding (...)' with obvious semantics. Per Larsson ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] Per-type function namespaces (was: Data.Set whishes)
Andre Ozone wrote: On 27/02/2004, at 9:51 AM, David Bergman wrote: So at the moment, many Haskellers will append the type name to the function to indicate that it only works on that particular data type. In this respect, Haskell is at a disadvantage vs most object-oriented languages, because in them, you can write x.add, and the type system will perform object-oriented polymorphism for you and call the correct add method, no matter if x is a FiniteMap or a Set. Writing addToFM fm ... or addToSet set ... is surely a lot more inconvenient than writing fm.add or set.add, no? Yes. But, you are refering to overloading, no? And, not subtype polymorphism (which is what I denote with object-oriented polymorphism)? Just to make things clear in my mind. Yes, what I'm referring to is essentially overloading. I called it object-oriented polymorphism because that's typically what OO people call such a thing :). No, they do not. What they call polymorphism, we call subype polymorphism or, if we are really hard-core and/or old school, even ad-hoc polymorphism. They do not even realize that overloading falls in the category of polymorphism at all... (I should know better to use OO terminology on a Haskell list; won't happen again ...). I think it is good that you do. We need that touch of engineering realism sometimes ;-) However, it's form of overloading that Haskell cannot currently handle well with type classes -- Oleg's post proves that you can do it, of course, but that's a (very good) hack rather than a long-term solution. I personally use (Haskell) classes for that overloading purpose, but in a sense that Generic Programmers would call concept modelling. So, you have thought of automatically, but implicitly, introduce a namespace for each data type, and then have Haskell employ Koenig Lookup, to decide which function an expression is refering to? It's a bit like Koenig lookup in that it has the same effect, although it's probably easier for the compiler to infer the namespace wanted, since we write expr.function ... rather than function expression Whether it is prefix or postfix should not alter the complexity of the lookup considerably. Writing function expression ... would work too, but then it looks like a standard function call rather than a function call associated with a particular type, and I think that causes more confusion. Long-time Haskell users understand that writing foo.f means use f in namespace foo; changing around the language semantics to mean that f foo now means use f in namespace foo would make lots of people rather unhappy :). I would want it to look as an ordinary function. The single biggest problem with Haskell, in my extremely humble opinion, is the shared namespace for all data type accessors, with which you probably agree. It is what irritated me the most with Entity-Relationship Diagram, that all fields need to have unique name globally. This in contrast to instance variables, methods and general overloading, as often found in OO languages. You realize, of course, that mere intranamespacial parameter type lookup (regular overloading) would achieve the same effect, without the (implicit) namespaces? I'm not sure what you mean by intranamespcial parameter type lookup -- can you explain? ah, I meant regular overloading, i.e., have a function be identified not by its name, but by its whole signature, including the arity and parameter type(s) [yes, curry, curry...] There are a number of means by which the x in x.add can be communicated to the actual function: it's similar to the hidden 'self' or 'this' variable that's present when you invoke a method on an object in OO. Perhaps x is passed to the function as its first parameter, or maybe it could be its last parameter, or even an arbitrary parameter (where the parameter it's passed as could be defined in the type signature of the function). Perhaps 'self' or 'this' could be an implicit parameter. Any one of them will work just fine, I think. Again, I think you are confusing the runtime dispatching subtype polymorpism from overloading. Overloading would do what you want, while the subtype polymorphism could (still) be handled by class, and instances of classes, the Generic Programming way. I (think I) understand the difference between dynamic binding vs overloading: here, all I'm after is trying to use the type system to give us a very simple form of overloading (e.g. based on the first argument to a function), that gives us the same effect as a per-type name space. When I read my own response, I know realize that it sounds harsh. Sorry about that. That was not the intention. I also think you understand and appreciate the difference between the two forms of polymorphisms. You touch at one of the core problems of Haskell. Thanks, David
