Re: Monomorphism, monomorphism...

Wed, 24 Oct 2001 10:36:22 +0200, Hannah Schroeter <[EMAIL PROTECTED]> pisze: > Why not create a dictionary record while compiling the associated > instance (which may, by the H'98 definition, occur only once in > the program)? Instances with contexts are commonly represented as functions which m

Re: Monomorphism, monomorphism...

Hannah Schroeter wrote: > I don't think so. Why not create a dictionary record while compiling > the associated instance (which may, by the H'98 definition, occur > only once in the program)? One problem is that certain Haskell programs need an unbounded number of instances. -- Lennart

Re: Monomorphism, monomorphism...

Hello! On Mon, Oct 08, 2001 at 07:38:09PM +, Marcin 'Qrczak' Kowalczyk wrote: > Mon, 8 Oct 2001 11:35:48 +0200, Hannah Schroeter <[EMAIL PROTECTED]> pisze: > > Now, with the typical dictionary implementation of type classes, > > this wouldn't really be too difficult. > Dictionaries would ha

Re: Monomorphism, monomorphism...

At 2001-10-10 03:59, Marcin 'Qrczak' Kowalczyk wrote: >We need some type T such that it's possible to define a family of >functions for arbitrary choices of A: >upA :: A -> T >downA :: T -> Maybe A >satisfying downA (upA a) = Just a. We want to choose the type for T >before deciding the

Re: Monomorphism, monomorphism...

"Marcin 'Qrczak' Kowalczyk" <[EMAIL PROTECTED]> writes: > 09 Oct 2001 13:55:04 -0700, Carl R. Witty <[EMAIL PROTECTED]> pisze: > > > The TREX paper from Mark Jones and Benedict Gaster (I hope I > > have the names right) had both extensible records and extensible > > variants (extensible variants

Re: Monomorphism, monomorphism...

09 Oct 2001 13:55:04 -0700, Carl R. Witty <[EMAIL PROTECTED]> pisze: > The TREX paper from Mark Jones and Benedict Gaster (I hope I > have the names right) had both extensible records and extensible > variants (extensible variants being what you would need to implement > downcasts), I don't thin

Re: Monomorphism, monomorphism...

"Marcin 'Qrczak' Kowalczyk" <[EMAIL PROTECTED]> writes: > Since OO languages often use subtypes to emulate constructors of > algebraic types, they need downcasts. In Haskell it's perhaps less > needed but it's a pity that it's impossible to translate an OO scheme > which makes use of downcasts in

Re: Extensible downcasts impossible in Haskell? (was Re: Monomorphism, monomorphism...)

Tue, 9 Oct 2001 10:50:19 +1300, Tom Pledger <[EMAIL PROTECTED]> pisze: > I'm curious about this impossibility. > > - Is it well known? If so, would someone please refer me to a paper > or posting which explains it? I don't know. I'm not even sure if some clever encoding couldn't express

Extensible downcasts impossible in Haskell? (was Re: Monomorphism, monomorphism...)

Marcin 'Qrczak' Kowalczyk writes: : | Since OO languages often use subtypes to emulate constructors of | algebraic types, they need downcasts. In Haskell it's perhaps less | needed but it's a pity that it's impossible to translate an OO | scheme which makes use of downcasts into Haskell in an

Re: Monomorphism, monomorphism...

Mon, 8 Oct 2001 11:35:48 +0200, Hannah Schroeter <[EMAIL PROTECTED]> pisze: > Now, with the typical dictionary implementation of type classes, > this wouldn't really be too difficult. Dictionaries would have to be make hashable and comparable. For a sane semantics you can't compare their identit

Re: Monomorphism, monomorphism...

Hello! On Sun, Oct 07, 2001 at 11:29:09AM +, Marcin 'Qrczak' Kowalczyk wrote: > [...] > >Shouldn't the compiler be able to limit the recomputations to > >one per instance of the class? > It would require very unusual implementation. Currently the compiler > doesn't need to build dic

Re: Monomorphism, monomorphism...

Sat, 6 Oct 2001 22:22:24 -0700, Juan Carlos Arévalo Baeza <[EMAIL PROTECTED]> pisze: >>A pattern which is something other than an identifier. > >Like defining a function, as opposed to defining a constant? No: a pattern, e.g. (x,y), Just y, (x:_) etc. A function definition looks like an ide

Re: Monomorphism, monomorphism...

On 6 Oct 2001 09:31:54 GMT, Marcin 'Qrczak' Kowalczyk wrote: First of all, thanks a lot for the detailed response. >Yes, ... yes ... yes Well, I'm glad I got some of it right. Gives me hope :) >>>"contains a pattern binding with a nonvariable pattern" >> >>  Meaning... what exactly? > >A

Re: Monomorphism, monomorphism...

Hi! Marcin wrote: > Juan Carlos Arévalo Baeza wrote: >> Karl-Filip wrote: >>>- a -> Bool (without quantification and with "IsNil a" among the >>> predicates). >> >>This is something I didn't understand either. Which predicates? > >I think "isNil a" goes to the context of the whole expressio

Re: Monomorphism, monomorphism...

Fri, 5 Oct 2001 19:02:50 -0700, Juan Carlos Arévalo Baeza <[EMAIL PROTECTED]> pisze: >>"If a declaration group" > >Meaning something like "let g = isNil" up there? Yes, a group of mutually recursive bindings or a single non-recursive binding (equations inside let or where or at module tople

re: Monomorphism Restriction

Ashley Yakeley, Seattle WA, writes: > Is there a point to the "monomorphism restriction" in GHC and Hugs? In > practice, all it seems to mean is "occasionally require unnecessary > explicit type signatures". I think the point is made clearly enough in section 4.5.5 of the Haskell 98 language r

Re: monomorphism ...

John Hughes : > > Everybody agrees the monomorphism restriction is a pain: ... > So, let's make it visible, in the simplest possible way. Let there be TWO > forms of binding: x = e, and x := e (say). A binding of the form `x = e' is > interpreted using call-by-name, and may of course be overloa

Re: Monomorphism

On 24-Feb-1999, John C. Peterson <[EMAIL PROTECTED]> wrote: > You can't nuke monomorphism without addressing the ambiguity problem. If you've got the time, would you mind giving an example of the kind of ambiguity you're talking about? I think I know roughly the kind of problem you're talking ab

Re: monomorphism etc.

On 12-Nov-1998, Lennart Augustsson <[EMAIL PROTECTED]> wrote: > > [...] if you dislike tuples you can use nested pairs At the cost of losing a little type-safety. -- Fergus Henderson <[EMAIL PROTECTED]> | "Binaries may die WWW: | but source code lives forever

Re: nested pairs (was Re: monomorphism etc.)

>PS. I've got a length function for ``heterogeneous lists'', as >they appear in nested pairs, in Hugs. However, it uses the >type system extensions available in 1.3c or in 1.4 [98 BETA]. >How much can you do in plain Haskell??? in Cayenne?-) oops. On second thought, this length

nested pairs (was Re: monomorphism etc.)

>But if you dislike tuples you can use nested pairs, like > > infixr 0 :. > data T a b = a :. b > >Now you can write > > 'a' :. True :. "Hello" :. () > >which has type > > T Char (T Bool (T String ())) > >But I guess that's not what you were after? > >-- Lennart Fergus replied: > > [...]

Re: monomorphism etc.

> > > > [...] if you dislike tuples you can use nested pairs > > At the cost of losing a little type-safety. That's really a very minimal loss. (And it's not really a loss of type safety, just the possibilty of confusing a part of a "tuple" with another "tuple"). I'd be more worried about the

Re: monomorphism etc.

> I think it would be > really nice if it were possible to create a container capable of > containing any number of objects of any number of types It would That's not possible in Haskell. Since you want an any number of different types in this new type it would need to have a variable numbe

RE: Re: Monomorphism

st tried to write above in Haskell as is or proposed? -- From: simonpj Sent: 21 July 1998 13:51 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Monomorphism To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Monomorphism From: Simon L Peyton Jones <[EMAIL PROT

Re: Monomorphism

> > I'm going to ask a very stupid question. > > Why on earth is len computed twice in this example? I really don't > understand this! I have to confess that I mischievously hoped that someone would say this: it demonstates the point nicely that lifting the monomorphism restriction would ca

RE: Monomorphism

On 21 Jul, [EMAIL PROTECTED] wrote: > > I'm going to ask a very stupid question. not stupid, actually quite subtle! > Why on earth is len computed twice in this example? I really don't > understand this! I think the confusion arises from the use of the terms poly- and mono- morphism to ref

Re: Monomorphism

One of the original motivations for questioning the DMR steems from the fact that function definitions expressed as simple pattern bindings are sometimes rejected. The definition sum as = foldr (+) 0 as is accepted but sum = foldr (+) 0 is not which is admittingly irritating. C

RE: Monomorphism

:03 To: Olaf Chitil <[EMAIL PROTECTED]>; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Monomorphism To: Olaf Chitil <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: Monomorphism From: Simon L Peyton Jones <[EMAIL PROTECTED]> Olaf suggests > Hence I suggest

Re: Monomorphism

Olaf suggests > Hence I suggest that part (b) of rule 1 of the MR should > be deleted, i.e. simple > pattern bindings are just treated as function bindings. As I have said in a > previous email, the recomputation issue could be handled by warnings from the > compiler. That would indeed not fall

Re: Monomorphism

Simon L Peyton Jones wrote: > What worries me is that a programmer might write this: > > read2 :: (Read a, Read b) => String -> (a,b) > read2 2 = let [(r1,s1)] = read s > [(r2,s2)] = read s1 > in > (r1,r2) The examples of

Re: Monomorphism

> > read :: Read a => String -> a > > read s = let [(r,s')] = reads s in r > > > > This *won't compile* if you don't treat the let binding definition > > monomorphicly. Without monomorphism, the types of r and s' are > > > > r :: Read a => a > > s' :: Read a => String > > > > This leads to an a

Re: Monomorphism

John Peterson defends the DMR: > read :: Read a => String -> a > read s = let [(r,s')] = reads s in r > This *won't compile* if you don't treat the let binding definition > monomorphicly. Without monomorphism, the types of r and s' are > r :: Read a => a > s' :: Read a => String > This leads

Re: Monomorphism

John C. Peterson wrote: > While some may argue that avoiding re-evaluation is the justification > for the monomorphism restriction, the real issue is ambiguity. > Without some form of monomorphism (or scoped type variables?? Someone > needs to convince me that scoped type variables fix everythin