- Haskell - Haskell.org

RE: Anomalous Class Fundep Inference
by Ashley Yakeley 03 May '01

03 May '01

At 2001-05-03 01:42, Simon Peyton-Jones wrote: >| In Hugs 98 Feb2001 (as hugs -98), this piece of code gives an error: >| >| class X a b | a -> b where x :: a; >| class (X a b) => Y a b | a -> b where y :: a; >| instance (X a b) => Y a b where y = x; >| instance (Num a) => X a a where x = 0; -- line A > >Quite right too! The final instance declaration says that the two >arguments of X must always be the same: Hmm... > * the class says a->b Yes. > * the instance matches any first arg I was rather hoping that the instance would match only (Num a => a) rather than (a). > and says that the second must be equal. Yes. -- Ashley Yakeley, Seattle WA

1 0

RE: Anomalous Class Fundep Inference
by Simon Peyton-Jones 03 May '01

03 May '01

| In Hugs 98 Feb2001 (as hugs -98), this piece of code gives an error: | | class X a b | a -> b where x :: a; | class (X a b) => Y a b | a -> b where y :: a; | instance (X a b) => Y a b where y = x; | instance (Num a) => X a a where x = 0; -- line A Quite right too! The final instance declaration says that the two arguments of X must always be the same: * the class says a->b * the instance matches any first arg and says that the second must be equal. So when typechecking the instance for Y a b, a and b are forced to be equal, and that's less general than the instance claims to be. Simon

1 0

RE: Implict parameters and monomorphism
by John Hughes 03 May '01

03 May '01

John: just to check, you do realise that (B) means a) That adding a type signature can change the dynamic semantics of the program. This would be the first and only occurrence of such behaviour. At present, adding a type signature changes both the static semantics and the cost of running a program -- one should already understand that a type signature with a non-empty context means the expression is evaluated at its uses rather than at its definition. Given that one understands that, and that an expression which uses an implicit parameter will have a type signature which explicitly indicates that, I don't think this is really such a big deal. b) That whether or not a definition is unconditionally inlinable at the source-language level cannot be determined by looking at the expression. You have to do something rather like effects analysis: look to see if it calls any function (transitively) that uses an implicit parameter. These seem like pretty dire properties. Are you sure it's worth it? Simon Are you sure this second one really holds? I claim the effects analysis is just type inference! If the expression has a context referring to an implicit parameter, then it cannot be unconditionally inlined -- it's as simple as that, isn't it? Admittedly, this really only solves the problem for the compiler -- the poor programmer may have more trouble doing type inference in his head. (How much easier life would be with = for call-by-name, := for call-by-need...) So maybe not so dire as you made out! John

1 0

Existential Type Declarations in Hugs
by Critterrathman＠aol.com 03 May '01

03 May '01

I know just enuf about existential types in Haskell to be dangerous. While trying to learn a little more about how to use them, I keep running into problem. The existential types work great for code that I constructed if the functions take a single argument. However, if the function takes more than one argument, I can't seem to figure out how to get them to work. In the test code below, everything compiles in Hugs (hugs98-Feb2001) except the last line in the instance declaration (setx). Is there something fundamental that I'm missing about how to create an existential instance and/or data declaration - given the listed class definition? module Test where class Shape a where getx :: a -> Int setx :: a -> Int -> a data ExistentialShape = forall a. Shape a => MakeExistentialShape a instance Shape ExistentialShape where getx (MakeExistentialShape a) = getx a setx (MakeExistentialShape a) newx = setx a newx -- here's the error message I get when I try to :load the module ERROR test.hs:14 - Type error in instance member binding *** Term : setx *** Type : ExistentialShape -> Int -> _12 *** Does not match : ExistentialShape -> Int -> ExistentialShape *** Because : cannot instantiate Skolem constant Thanks, Chris Rathman

2 1

Re: Implict parameters and monomorphism
by John Hughes 03 May '01

03 May '01

But a term with an "implicit" argument is a function no matter how you turn it, you just don't write the argument explicitely. I don't buy that. You could equally well say a term with a free variable is a "function" (of the environment): sure it is, but if it's bound with a let then the function is called only once. John

1 0

Re: List of words
by Ashley Yakeley 02 May '01

02 May '01

At 2001-05-02 01:34, Hannah Schroeter wrote: >How about this: > >import Char(toUpper) > >capitalize :: String -> String >capitalize [] = [] >capitalize (c:cs) = toUpper c : cs > >capitalizeList :: [String] -> [String] >capitalizeList = map capitalize ...or if you prefer... capitalizeList :: [String] -> [String] capitalizeList = map (map toUpper) -- Ashley Yakeley, Seattle WA

4 3

Re: List of words
by Keith Wansbrough 02 May '01

02 May '01

> >Ah, but (i) not all the solutions are correct (sorry Ashley); > > That rather depends on what you mean by CAPITALISE, does it not? > > capitalise, -ize to print or write with capital letters [Chambers] I guess so. Maybe someone at Monash University (Australia) would care to enlighten us? >;-> --KW 8-) -- Keith Wansbrough <kw217(a)cl.cam.ac.uk> http://www.cl.cam.ac.uk/users/kw217/ Cambridge University Computer Laboratory.

1 0

Re: List of words
by Ashley Yakeley 02 May '01

02 May '01

At 2001-05-02 04:54, Keith Wansbrough wrote: >Ah, but (i) not all the solutions are correct (sorry Ashley); That rather depends on what you mean by CAPITALISE, does it not? capitalise, -ize to print or write with capital letters [Chambers] -- Ashley Yakeley, Seattle WA

1 0

Re: List of words
by Keith Wansbrough 02 May '01

02 May '01

> I am relatively new to Haskell. > > Somebody told me that it is a very good language, because all the > people on its mailing list are so nice that they solve all > homeworks, even quite silly, of all students around, provided they > ask for a solution in Haskell. > > Is that true, or a little exaggerated? Ah, but (i) not all the solutions are correct (sorry Ashley); and (ii) some of the solutions should be recognisable by markers as not the work of a newbie (explicit import lists, map, ...). Essentially, though, your friend is correct. --KW 8-)

1 0

Erlang workshop
by John Hughes 02 May '01

02 May '01

(apologies if you receive more than one copy of this). Call for abstracts to the Erlang Workshop Firenze, September 2, 2001, in connection with PLI2001 (Principles, Logics, and Implementations of high-level programming languages). Scope Contributions are invited on experience with and applications of Erlang, critiques and proposals for extensions, design methods and structuring principles for large functional systems, implementation techniques, programming tools, verification methods, etc. Submitted abstracts should be 2-12 pages, and will be judged on the potential for an interesting presentation. Abstracts should in text, postscript or PDF format and sent to workshop(a)erix.ericsson.se by May 15, 2001. Authors will be notified of acceptance by June 15, 2001. Authors of accepted abstracts are welcome to submit full papers or additional accompanying materials for inclusion in the informal proceedings by August 15, 2001. Home page of the Erlang workshop http://www.erlang.se/workshop/ Home page of PLI2001 http://music.dsi.unifi.it/pli01/ We are looking forward to an exciting workshop in the environment of PLI2001. Welcome Joe Armstrong, Alteon Websystems Bjarne Däcker, Ericsson Utvecklings AB John Hughes, Chalmers University of Technology Gunilla Hugosson, Ericsson Utvecklings AB (Programme committee)

1 0