AW: AW: simulating dynamic dispatch

2003-03-24 Thread Markus . Schnell
Thanks! These examples and counterexamples help a lot in understanding. Markus > The reason is that sum only works on integer lists, whereas the given > type for fun requires that the first argument be a function that works > on lists of any type, such as length. > If sum were allowed as argumen

Re: AW: simulating dynamic dispatch

2003-03-24 Thread Janis Voigtlaender
[EMAIL PROTECTED] wrote: > > I think I get it. But to be sure: > The forall means: The type for a may not be the same > throughout the whole function. It just has to follow > the pattern specified inside the braces. Not exactly. In: > > fun::(forall a.[a]->Int)->[b]->[c]->Int > > fun f x y = f x

Re: AW: simulating dynamic dispatch

2003-03-24 Thread Steffen Mazanek
> Interestingly, when I want hugs to show me the type > of > > fun::(forall a.[a]->Int)->[b]->[c]->Int > it tells me: ERROR - Use of fun requires at least 1 argument > Why that? At least I have explicitely specified the type. Hmm, ghci behaves properly. But using hugs I get the same error :-(. N

AW: simulating dynamic dispatch

2003-03-24 Thread Markus . Schnell
I think I get it. But to be sure: The forall means: The type for a may not be the same throughout the whole function. It just has to follow the pattern specified inside the braces. Interestingly, when I want hugs to show me the type of > fun::(forall a.[a]->Int)->[b]->[c]->Int it tells me: ERROR -

Re: AW: simulating dynamic dispatch

2003-03-24 Thread Steffen Mazanek
> concrete: What is the difference between > (forall b. Term b => b -> b) -> a -> a > and > (Term b) => (b -> b) -> a -> a > ? One may want: fun f x y = f x + f y for instance: fun length [True, False] [1,2] Therefore, I would say, you need typing a la fun::(forall a.[a]->Int)->[b]->[c]->

AW: simulating dynamic dispatch

2003-03-24 Thread Markus . Schnell
> http://research.microsoft.com/~simonpj/papers/hmap/ The technique you describe in that paper is exactly what I was wanting for many times. I often stopped using algebraic data types because of the immense amount of boilerplate I had to introduce. Thanks! But now I have a question regarding th

RE: simulating dynamic dispatch

2003-03-23 Thread oleg
Hal Daume wrote: > -- *Main> test $ MkFoo (0::Int) > -- Just True > -- *Main> test $ MkBar 'a' > -- Just True > i forgot to mention the constraint > that i don't want the user to have to use the MkFoo/MkBar > constructors. if i could use them internally to 'test', that would be > great, bu

RE: simulating dynamic dispatch

2003-03-21 Thread Hal Daume III
TECTED] > | Sent: 21 March 2003 04:19 > | To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > | Subject: Re: simulating dynamic dispatch > | > | > | > i'm hoping to be able to simulate a sort of dynamic dispatch based > on > | > class instances. > | > | It se

simulating dynamic dispatch

2003-03-21 Thread Markus . Schnell
I think you are looking like something done in the HTML-Combinator-libraries. I tried something like that some time ago, but didn't finish. But perhaps you can get an idea from that. See the files with this mail. (The code is in unknown condition.) Markus > ah, yes. i was aware that would work.

RE: simulating dynamic dispatch

2003-03-21 Thread Simon Peyton-Jones
| Sent: 21 March 2003 04:19 | To: [EMAIL PROTECTED]; [EMAIL PROTECTED] | Subject: Re: simulating dynamic dispatch | | | > i'm hoping to be able to simulate a sort of dynamic dispatch based on | > class instances. | | It seems you want to dispatch based not on a type but on the |

Re: simulating dynamic dispatch

2003-03-20 Thread Fergus Henderson
On 20-Mar-2003, Hal Daume III <[EMAIL PROTECTED]> wrote: > i'm hoping to be able to simulate a sort of dynamic dispatch based on > class instances. basically a function which takes a value and depending > on what classes it is an instance of, does something. I call this feature "dynamic type clas

Re: simulating dynamic dispatch

2003-03-20 Thread Hal Daume III
> -- *Main> test $ MkFoo (0::Int) > -- Just True > -- *Main> test $ MkFoo (10::Int) > -- Just False > -- *Main> test $ MkBar 'a' > -- Just True > -- *Main> test $ MkBar 'b' > -- Just False ah, yes. i was aware that would work. i forgot to mention the constraint that i don't want the user t

Re: simulating dynamic dispatch

2003-03-20 Thread oleg
> i'm hoping to be able to simulate a sort of dynamic dispatch based on > class instances. It seems you want to dispatch based not on a type but on the constraint of a type. You code almost worked. Here's the a bit updated and working version. class Foo a where { foo :: a -> Bool } class Bar a

simulating dynamic dispatch

2003-03-20 Thread Hal Daume III
hi all, i'm hoping to be able to simulate a sort of dynamic dispatch based on class instances. basically a function which takes a value and depending on what classes it is an instance of, does something. a simple example might be a 'maybeShow' function which sematically looks like: > maybeShow