:t (#) gives parse error
In GHC 6.0.1, using GHCi: Prelude let x # f = f x Prelude :t (#) interactive:1: parse error on input `)' Prelude :t ( #) interactive:1: parse error on input `#)' Prelude :t (# ) interactive:1: parse error on input `)' Prelude :t ( # ) ( # ) :: forall t t1. t1 - (t1 - t) - t Prelude zipWith (#) [1] [(+1)] interactive:1: parse error on input `)' Prelude zipWith ( # ) [1] [(+1)] [2] Prelude Juanma ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: :t (#) gives parse error
In GHC 6.0.1, using GHCi: Prelude let x # f = f x Prelude :t (#) interactive:1: parse error on input `)' Prelude :t ( #) interactive:1: parse error on input `#)' Prelude :t (# ) interactive:1: parse error on input `)' Prelude :t ( # ) ( # ) :: forall t t1. t1 - (t1 - t) - t Prelude zipWith (#) [1] [(+1)] interactive:1: parse error on input `)' Prelude zipWith ( # ) [1] [(+1)] [2] Prelude This is because '(#' and '#)' have special meanings when -fglasgow-exts is on: they are the brackets of an unboxed tuple, eg. (# x, y #). Either add spaces, or turn off -fglasgow-exts. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Real world example needed for ...
Hello, I am looking for a real world example of a type constructor, that expects another type constructor as an argument in the context of subtyping, e.g., one could define --not Haskell98 data T a b c = F (a b c) a::T (-) Pt Pt a = F id b::T (-) CPt CPt b = F id l = [a,b] Thereby CPt is assumed to be a subtype of Pt. From my expectations l should be typable [T (-) CPt Pt], because of contravariance of (-). Using c::T (Either) Pt Pt and d::T (Either) CPt CPt one would gain [c,d]::T (Either) Pt Pt. I need this real world example for the sake of motivation, that variance can be expressed by Haskell kinds, e.g., in a kind system the kind of T could be (a-b-*)-a-b-*. Thereby the kind variables a and b can be instantiated by special kinds + and -, that represent co- and contravariance, respectively. So one would have T (-)::- - + - * and T (Either)::+ - + - * and so on... Any ideas are very appreciated. Ciao, Steffen ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: lexer puzzle
A... should be split into A.. and . I found a compromise: let's make it a lexing error! :-) At least that agrees with what some Haskell compilers implement. No current Haskell compiler/interpreter agrees with what the report seems to say, that is that A... should be lexed as the two tokens A.. and ., and similarly, A.where should be lexed as A.wher followed by e. Hi. I'm really new to Haskell, just learning it, and I must say I'm pretty overwhelmed by the large variety of constructs. (=, -, \ to name a few) But I'm just writing this to let you guys know (surely you know this already) that anyone from a C/C++/Java/Delphi background is going to completely misunderstand the meaning of A.anything in Haskell... it's completely nonintuitive to people with my background. I kinda like dot notation because it ties together the symbols visually, for instance myrec.myfield is more of a unit than myrec myfield. It stays together better when surrounded by other code, and would result in fewer parenthesis necessary. Haskell to me seems to be a great language with a syntax problem, and a bad case of too many ways to do the same thing; thus every programmer does things their own way and it's difficult to grasp the language by looking at various programs, since they're all so very different. As a small example, there's 'let' vs. 'where'. Maybe a bit of pruning would be in order. That said, I still think it looks more promising than any other language I've looked at that actually is being actively used and maintained and has a decent installed base and good cross platform support. So I will learn it. I just wish the transition was easier and that it took less time to learn. ;) Sean ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: lexer puzzle
Hi, But I'm just writing this to let you guys know (surely you know this already) that anyone from a C/C++/Java/Delphi background is going to completely misunderstand the meaning of A.anything in Haskell... it's completely nonintuitive to people with my background. Surely this is no worse than misunderstanding '=', as in: f n = n + 1 is it? I'd say of all the hurdles going from C++-esque to Haskell, the A.foo is one of the least troubling (I could be wrong and would like to know if I am). Haskell to me seems to be a great language with a syntax problem, and a bad case of too many ways to do the same thing; thus every programmer does I've always thought it the opposite :). Let vs. where can be somewhat confusing, and it is largely a matter of style, but they're not completely interchangable, esp. in the presence of, say guards, ie.: f x | x 0 = foo x | x 0 = foo (-x) where foo y = ... could not be done with a let. My 2 cents... - Hal ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: learning to love laziness
Haskell has lazy/lifted products and not true products. This feature is considered by many to be an unfortunate aspect of Haskell. A 2-tuple is just syntactic sugar for data Tuple2 a b = Tuple2 a b Maybe from seeing this, it's clearer why laws such as x = (fst x,snd x) do not hold. Neither does the following law hold (uncurry . curry) f = f which is unfortunate (for a language named after Haskell *Curry*). To see why it doesn't hold, compare t1 and t2 in this program: f (_,_) = 1 t1 = f undefined t2 = (uncurry . curry) f undefined - Mark On Wednesday, September 24, 2003, at 02:07 PM, Norman Ramsey wrote: Consider the following Haskell function: asPair x = (fst x, snd x) This function has type forall a b. (a, b) - (a, b) and is almost equivalent to the identity function, except it can be used to make programs terminate that might otherwise fall into a black hole. My students are extremely mystified by such functions---and I can hardly blame them! Is there a good place to read about programming with lazy evaluation that will cover such functions and when to use them? Norman ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: lexer puzzle
Hi, Haskell to me seems to be a great language with a syntax problem, and a bad case of too many ways to do the same thing; thus every programmer does things their own way and it's difficult to grasp the language by looking at examples. int fact(int x){int t=1; while(x) t*=x--;} int fact(int x){int t=1; for(int i=1;i=x;i++) t=t*i;} int fact(int x){if(x=0) return 1; else return x * fact(x-1);} int fact(int x){return aux(x,1);} int aux(int x, int t){ return x ? t : aux(x-1,t*x);} int fact(int x){int t=1; while(x (t*=x--)); return t;} #define TRUE 1 #define FALSE 0 int fact(int x) { if((x==0)==TRUE) return 1; else { t = fact(x-1); return(t*x); } } x = x + 1; x += 1; x++; #include stdio.h main(t,_,a) char *a; { return!0t?t3?main(-79,-13,a+main(-87,1-_,main(-86,0,a+1)+a)): 1,t_?main(t+1,_,a):3,main(-94,-27+t,a)t==2?_13? main(2,_+1,%s %d %d\n):9:16:t0?t-72?main(_,t, @n'+,#'/*{}w+/w#cdnr/+,{}r/*de}+,/*{*+,/w{%+,/w#q#n+,/#{l+,/n{n+,/+#n+,/#\ ;#q#n+,/+k#;*+,/'r :'d*'3,}{w+K w'K:'+}e#';dq#'l \ q#'+d'K#!/+k#;q#'r}eKK#}w'r}eKK{nl]'/#;#q#n'){)#}w'){){nl]'/+#n';d}rw' i;# \ ){nl]!/n{n#'; r{#w'r nc{nl]'/#{l,+'K {rw' iK{;[{nl]'/w#q#n'wk nw' \ iwk{KK{nl]!/w{%'l##w#' i; :{nl]'/*{q#'ld;r'}{nlwb!/*de}'c \ ;;{nl'-{}rw]'/+,}##'*}#nc,',#nw]'/+kd'+e}+;#'rdq#w! nr'/ ') }+}{rl#'{n' ')# \ }'+}##(!!/) :t-50?_==*a?putchar(31[a]):main(-65,_,a+1):main((*a=='/')+t,_,a+1) :0t?main(2,2,%s):*a=='/'||main(0,main(-61,*a, !ek;dc [EMAIL PROTECTED]'(q)-[w]*%n+r3#l,{}:\nuwloca-O;m .vpbks,fxntdCeghiry),a+1); } I'm not being facetious here, but deadly serious. Your average language that is worth anything allows programmers to program in more than one way. If the language truely constrained everyone to produce a given program looking exactly the same way, then it is probably a nightmare to program in. Speaking as someone who comes from a C/C++/Java/Scheme/Assembler/Algebra background, I don't find Haskell syntax to be any more annoying than any other typical syntax. And I did not find any particular clash with `.' It's like the the game of Go, the rules (syntax) you learn in one sitting, but the strategy can take a life time. Any programmer should be able to pick up a new syntax in a week. (not that you want to do that every week, because you want to get down to playing the game). Regards, Bruce. Institute for Information and Mathematical Sciences Massey University at Albany, email: [EMAIL PROTECTED] web: http://www.massey.ac.nz/~bimills ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Modeling multiple inheritance
When Mark Shields and I tackled this problem we came up with Object-Oriented Style Overloading for Haskell http://research.microsoft.com/~simonpj/Papers/oo-haskell/index.htm It describes an (unimplemented) extension to Haskell, rather than modelling it in Haskell itself, but you may find it interesting none the less. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of | Brandon Michael Moore | Sent: 24 September 2003 22:22 | To: [EMAIL PROTECTED] | Subject: Modeling multiple inheritance | | I'm trying to build a nicer interface over the one generated by | jvm-bridge. I'm using fancy type classes to remove the need to mangle | method names. I would like methods to be automatcially inherited, | following an inheritance hierarcy defined with another set of type | classes. | | My basic classes look like this | class HasFooMethod cls args result | cls args - result where | foo :: cls - args - result | | If I have classes A and B with foo methods like | foo_JA_Jint :: ClassA - Jint - Bool | foo_JB_Jboolean :: ClassB - Bool - Jint | then I can make instances | instance HasFooMethod ClassA Jint Bool | instance HasFooMethod ClassB Bool Jint | | Now I can just use foo everywhere. I would like to avoid declaring an | instance for every class though. In java methods are inherited from a | superclass, and I would like to inherit methods automatically as well. In | the bindings jvm-bridge generates a method is invoked with a function | mangled after the highest ancestor that defined that particular | overloading, so the implementation of HasFooMethod at a particular | overloading is the same for any descendant. | | So I defined a class to model the inheritance relationships | | class SubType super sub | sub - super where | upCast :: sub - super | | Now I can define a default instance of HasFooMethod: | instance (HasFooMethod super args result, | SubClass super sub) = | HasFooMethod sub args result where | foo sub args = foo (upCast sub) args | | This will propagate foo methods down the inheritance hierarcy. If a new | class C is derived from A, I just need to say | | instance SubClass ClassA ClassC | | and ClassC gets a foo method. (In the actually code I piggy-back on a | transitive subclass relation jvm-bridge defines that already includes an | upcast method, so upCast has a default that should always be acceptable). | | The problem comes when interfaces are added to the mix. Interfaces are | treated just like classes by jvm-bridge, and even though no implementation | is inherited from instances in Java, the method accessors generated by | jvm-bridge should be inherited. | | One problem is that the subclass relationship needs the functional | dependency so that the default instance of HasFooMethod will respects the | functional dependencies of HasFooMethod, so I can't declare subclass | instances for multiple inheritance. On the other hand, if I don't use the | functional dependency on HasFooMethod I end up needing to annotate most of | the return values in a program. I run into similar problems trying to use | numeric literals as arguments, because they are also overloaded. | | Does anyone know of clever solutions that would model multiple inheritance | while preserving the functional dependencies (unsafe compiler flags are | fine too), or ways to reduce the pain of overloading resolution without | the functional dependency? | | One alternative is generating seperate HasFooMethod instances for every | class in the system. The problem is that this would require alterating the | bit of jvm-bridge that uses JNI to find information on classes, which | currently only reports newly defined methods. JNI is black magic to me. | | Thanks | Brandon | | ___ | Haskell-Cafe mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Generating setMember functions for record structures
Peter Gammie writes: Haskell Report, Sec 3.15.3 Great, that's exactly what I need. Thanks a lot to all who replied! Peter ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: Database interface - would like advice on oracle library binding
The following code illustrates a _generic_ interface to low-level database code. The left-fold iterator doQuery is completely generic over any possible iterator -- no matter how many columns the query returns, what are the types of these columns and what is the type of the seed (accumulator). The code for doQuery remains the same. The iterator allocates buffers for columns at the beginning and frees the buffers at the very end. Again, this buffer handling is generic. There is no longer need to write extraction/unmarshalling function for specific types of rows. We only need fetching functions for specific datatypes (not columns!). Again, the query and the row buffer management code is completely generic. I guess I'm repeating myself. The tests: -- Query returns one column of type String -- Never mind undefined: we return some static data in the buffers, -- we don't have any oracle to bind to test1 = doQuery undefined undefined iter1 ([]::[String]) where iter1:: String - [String] - Either [String] [String] iter1 s acc = Right $ s:acc -- Query returns two columns of types String and Int test2 = doQuery undefined undefined iter2 ([]::[(String,Int)]) where iter2:: String - Int - [(String,Int)] - Either [(String,Int)] [(String,Int)] iter2 s i acc = Right $ (s,i):acc -- Query returns three columns of types Int, String and Int test3 = doQuery undefined undefined iter3 ([]::[(Int,String,Int)]) where iter3:: Int - String - Int - [(Int,String,Int)] - Either [(Int,String,Int)] [(Int,String,Int)] iter3 i1 s i2 acc = Right $ (i1,s,i2):acc Use the function runtests to run either of these tests. The code follows. Compiler flags: -fglasgow-exts -fallow-overlapping-instances -- DB column buffers type BufferSize = Int data BufferType = ORA_char | ORA_int type Position = Int -- column number of the result table data Buffer = Buffer { bufptr :: String -- for this stub, just use String , nullindptr :: String -- likewise , retsizeptr :: String -- likewise , size:: BufferSize , pos:: Position , ora_type:: BufferType } -- understandably, below is just a stub ... alloc_buffer (siz, typ) ps = return $ Buffer { bufptr = show ps, pos = ps, size = siz, ora_type = typ} -- In this stub, don't do anything free ptr = return () -- DB Column types class DBType a where alloc_buffer_hints:: a - (BufferSize, BufferType) col_fetch:: Buffer - IO a instance DBType String where alloc_buffer_hints _ = (2000, ORA_char) col_fetch buffer = return (bufptr buffer) instance DBType Int where alloc_buffer_hints _ = (4, ORA_int) col_fetch buffer = return (read $ bufptr buffer) -- need to add more ... -- Row iteratees. Note, the folowing two instances cover ALL possible -- iteratees. No other instances are needed class SQLIteratee iter seed where iter_apply:: [Buffer] - seed - iter - IO (Either seed seed) alloc_buffers:: Position - iter - seed - IO [Buffer] instance (DBType a) = SQLIteratee (a-seed-Either seed seed) seed where iter_apply [buf] seed fn = col_fetch buf = (\v - return$ fn v seed) alloc_buffers n _ _ = sequence [alloc_buffer (alloc_buffer_hints (undefined::a)) n] instance (SQLIteratee iter' seed, DBType a) = SQLIteratee (a-iter') seed where iter_apply (buf:others) seed fn = col_fetch buf = (\v - iter_apply others seed (fn v)) alloc_buffers n fn seed = do this_buffer - alloc_buffer (alloc_buffer_hints (undefined::a)) n other_buffers - alloc_buffers (n+1) (fn (undefined::a)) seed return (this_buffer:other_buffers) free_buffers = mapM_ free -- The left fold iterator -- the query executor data Session -- not relevant for this example data SQLStmt db_execute session query = return () db_fetch_row buffers = return () -- use static data doQuery:: (SQLIteratee iter seed) = Session - SQLStmt - iter - seed - IO seed -- In this example, we just allocate buffers, fetch two rows and terminate -- with a clean-up doQuery session query iteratee seed = do buffers - alloc_buffers 0 iteratee seed db_execute session query db_fetch_row buffers (Right seed) - iter_apply buffers seed iteratee db_fetch_row buffers (Right seed) - iter_apply buffers seed iteratee free_buffers buffers return seed -- Tests -- Query returns one column of type String test1 = doQuery undefined undefined iter1 ([]::[String]) where iter1:: String - [String] - Either [String] [String] iter1 s acc = Right $ s:acc -- Query returns two columns of types String and Int test2 = doQuery undefined undefined iter2 ([]::[(String,Int)]) where iter2:: String - Int - [(String,Int)] - Either [(String,Int)] [(String,Int)] iter2 s i acc = Right $ (s,i):acc -- Query returns three columns of types Int, String and Int test3 = doQuery
Haskell as specification language
out of curiosity, is haskell already been used as a specification language ? i was thinking in a business term, rather than mathematical one. (i.e. one than normal mortal can read, even with a bit of training ;-) I.e. one would specifiy a model, an application ( possibly run it on samples), and hand it over to developper, typically in other languages/environment... I am aware of the contracts paper of SPJ, for instance... others you may think of ? does a spec. always leads to a DSL , for instance ? I imagine a specification for an application resulting in a DSL for the data model/ process model part, (which is the generic/ reusabel part, IMH) plus something more specific to the effective application targeted... (I cannot resist explaining my long term view : if IT outsourcing really takes off one day, one key factor will be proper specification, which is in a dear state in the current practice nowadays in the field) ref: http://search.ft.com/search/article.html?id=030923007625 ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: lexer puzzle
Note I've replied to haskell-cafe. This post is a bit chatty and low on solid answers. On Thu, 25 Sep 2003, Sean L. Palmer wrote: A... should be split into A.. and . I found a compromise: let's make it a lexing error! :-) At least that agrees with what some Haskell compilers implement. No current Haskell compiler/interpreter agrees with what the report seems to say, that is that A... should be lexed as the two tokens A.. and ., and similarly, A.where should be lexed as A.wher followed by e. Hi. I'm really new to Haskell, just learning it, and I must say I'm pretty overwhelmed by the large variety of constructs. (=, -, \ to name a few) Would that be \ as in TREX row variable polymorphism? Just remember most operators are just library functions. It's only =, -, =, -, :: that are really part of the language, and {,},; for grouping. Did I miss any? But I'm just writing this to let you guys know (surely you know this already) that anyone from a C/C++/Java/Delphi background is going to completely misunderstand the meaning of A.anything in Haskell... it's completely nonintuitive to people with my background. I kinda like dot notation because it ties together the symbols visually, for instance myrec.myfield is more of a unit than myrec myfield. It stays together better when surrounded by other code, and would result in fewer parenthesis necessary. A Python programmer would understand instantly: Python uses exactly the same syntax for module access, though Python modules are usually in lowercase. It also seems to be very much in the spirit of access a member of this object of an OO language. Or was that supposed to be composition of a constructor with a function, A . f? Function composition, and higher order functions in general are likely to confuse an imperative programmer, but I think there isn't much syntax can do there. Or are you talking about the field access syntax? Maybe the problem is that dot has two to five different meanings, function composition, naming module members, building hierarchial module names, being a decimal point, and making elipses, and is commonly used for yet another purpose in OO languages. Haskell to me seems to be a great language with a syntax problem, and a bad case of too many ways to do the same thing; thus every programmer does things their own way and it's difficult to grasp the language by looking at various programs, since they're all so very different. As a small example, there's 'let' vs. 'where'. Maybe a bit of pruning would be in order. Do you mean the syntax is bad in places? Haskell is the cleanest language I know of, but I'm sure it has some grungy bits. I've had problems with unary minus (can't slice binary minus), and precedence of with irrefuatble patterns and type ascription. I would be happy for any confusing syntax to be improved. Any good ideas? Syntax change is a possibility: do notation is a relatively recent addition, and arrow syntax is in the works. I think you might instead mean the syntax cuts down our market share because it isn't like common (C derived) languages. I don't think Haskell could borrow any more syntax from C without actually making the language worse. It's a problem, but not with the syntax. If someone is so solidly into a C++/Java/OO mindset that the syntax would be a problem, the semantics would probably be even more of a problem. I would suggest Python if Haskell was too much of a jump for someone. It's still OO, but it encourages more flexible and interesting programs, and you don't have to live in a Java type system. Plus, it has more libraries, bindings, and PR, so it's easier to get permission to use it in a company. If someone is used to Python's layout rule and lack of type signatures, and gets their head around some of the fun you can have dynamically picking which members of an object to access, assigning to __dict__ and so on, then Haskell should be much less of a jump in syntax, and less imposing in semantics. That said, I still think it looks more promising than any other language I've looked at that actually is being actively used and maintained and has a decent installed base and good cross platform support. So I will learn it. I just wish the transition was easier and that it took less time to learn. ;) Sean I learned Haskell from the gentle introduction. It seemed gentle enough to me but others disagree, so I'm probably not the best for advice for the raw beginner. If you are interested in learning about monads though, Jeff Newbern's monad tutorial seems accessible and as complete as anything this side of Phil Wadler's paper. I hope learning Haskell goes well. Brandon ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Modeling multiple inheritance
Brandon Michael Moore wrote: So I defined a class to model the inheritance relationships class SubType super sub | sub - super where upCast :: sub - super Now I can define a default instance of HasFooMethod: instance (HasFooMethod super args result, SubClass super sub) = HasFooMethod sub args result where foo sub args = foo (upCast sub) args This will propagate foo methods down the inheritance hierarcy. If a new class C is derived from A, I just need to say One problem is that the subclass relationship needs the functional dependency Does anyone know of clever solutions that would model multiple inheritance while preserving the functional dependencies (unsafe compiler flags are fine too), or ways to reduce the pain of overloading resolution without the functional dependency? Yes. The code included. The solution is trivial: in case of a multiple inheritance, a class has a _sequence_ of superclasses rather than a single superclass. Like instance SubClass (Object,()) ClassA instance SubClass (Object,()) ClassB -- Multiple inheritance (including the diamond!) instance SubClass (ClassA,(ClassB,())) ClassC instance SubClass (ClassA,(ClassB,(ClassC,( ClassD And we need some intelligence to traverse the sequence. But even a computer can do that. I would like to propose a different solution: a dual of typeclasses in the value domain. Function foo is just a regular function foo:: Object - Int - Int foo x y = y We then need a class MApplicable fn args result with a method mapply. The trick is that the method should take any object of a type castable and cast it to the type of the first argument of fn. The cast can be made safe and statically checkable, using the type heap. Actually, we can use the type heap to model the dispatch table (whose rows are functions and columns are object/classes). Given a function and an object, we can search in many way for the applicable combination. And now, the code for the solution that works. Compiler flags: -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances data Object = Object data ClassA = ClassA data ClassB = ClassB data ClassC = ClassC data ClassD = ClassD class SubClass super sub | sub - super where upCast :: sub - super instance SubClass (Object,()) ClassA instance SubClass (Object,()) ClassB -- Multiple inheritance (including the diamond!) instance SubClass (ClassA,(ClassB,())) ClassC instance SubClass (ClassA,(ClassB,(ClassC,( ClassD class HasFooMethod cls args result where foo :: cls - args - result instance (SubClass supers sub, HasFooMethod supers args result) = HasFooMethod sub args result where foo obj args = foo (upCast obj) args instance (HasFooMethod cls args result) = HasFooMethod (cls,()) args result where foo (x,()) = foo x instance (HasFooMethod cls args result) = HasFooMethod (x,cls) args result where foo (x,y) = foo y instance HasFooMethod Object Int Int where foo _ x = x test1::Int = foo Object (1::Int) test2::Int = foo ClassA (2::Int) test3::Int = foo ClassD (3::Int) -- Likewise for another method: class HasBarMethod cls args result where bar :: cls - args - result instance (SubClass supers sub, HasBarMethod supers args result) = HasBarMethod sub args result where bar obj args = bar (upCast obj) args instance (HasBarMethod cls args result) = HasBarMethod (cls,()) args result where bar (x,()) = bar x instance (HasBarMethod cls args result) = HasBarMethod (x,cls) args result where bar (x,y) = bar y instance HasBarMethod ClassB Bool Bool where bar _ x = x test4::Bool = bar ClassB True test5::Bool = bar ClassC True test6::Bool = bar ClassD True ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe