February 2001 - Haskell

Re: Revamping the numeric classes
by Ketil Malde 08 Feb '01

08 Feb '01

Bjorn Lisper <lisper(a)it.kth.se> writes: >> Two interpretations of a code are "correct", but one is "more correct" >> than the other. > It is quite similar in spirit to the concept of principal type in > Hindley-Milner type systems. An expression can have many types but > only one "best" (most general) type in that system. Now, I'm not any kind of expert on this, but isn't the most general HM type one that encompasses the others, and *not* one out of a set of ambigous (and mutually exclusive) types? -kzm -- If I haven't seen further, it is by standing in the footprints of giants

2 1

Re: Fundeps and quantified constructors
by anatoli 08 Feb '01

08 Feb '01

--- Tom Pledger <Tom.Pledger(a)peace.com> wrote: > anatoli writes: > : > | The same error message is given for > | > | > data Foo a = (Eq b) => MkFoo b > > Since the type variable a is orphaned, how about reducing it to this? > > > data Foo = forall b . Eq b => MkFoo b This is possible (the semantics is different of course). What I want to do is, given a multi-parameter context, orphan one type variable leaving the other intact, and that's not possible now. I can only orphan all or preserve all. > > so that MkFoo :: Eq b => b -> Foo > > | I don't know whether this is intended behaviour; IMHO > | it should be treated identically to > | > | > data Foo a = MkFoo (Eq a => a) > > Isn't the Foo-ed a hidden by the Eq-ed a in this example too? i.e. > > > data Foo = MkFoo (forall a . Eq a => a) It appears that both examples are wrong, or at least Hugs thinks so. The first MkFoo happily accepts any type, not just of class Eq: Main> :t MkFoo head MkFoo head :: Foo ([a] -> a) The second accepts nothing of interest: Main> :t MkFoo 'a' ERROR: Inferred type is not general enough *** Expression : 'a' *** Expected type : Eq a => a *** Inferred type : Eq Char => Char Hm... The more I experiment with this, the less I understand. It seems that the only correct place to put the quantifier is before the data constructor, and the context may go either before the type constructor or after the quantifier. This is very unfortunate. How can I correctly write something to this effect: > data Quick a = Eq a => Unsorted [a] > | Ord a => Sorted (Tree a) ??? Regards -- anatoli __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/

1 0

FME 2001--Register Now!
by Pamela Zave 08 Feb '01

08 Feb '01

*************************************************************************** * FORMAL METHODS EUROPE 2001 * * "Formal Methods for Increasing Software Productivity" * * * * 12-16 March, Berlin, Germany * * * * Come to the world's leading conference on application of formal methods * * in the software industry! * *************************************************************************** The programme of tutorials, workshops, invited lectures, papers, and tool exhibitions is available on the symposium website: www.informatik.hu-berlin.de/top/fme2001 Please hurry -- 9 February is the deadline for early registration and guaranteed reservations at the conference hotel! Registration and hotel reservation forms are also available on the symposium website. *************************************************************************** * Early Registration Deadline is 9 February * ***************************************************************************

3 2

'Convertible' class?
by Dylan Thurston 08 Feb '01

08 Feb '01

In thinking about various issues with the numeric classes, I came up with the following question: Is there a problem with having a class 'Convertible' as follows? class Convertible a b where convert :: a -> b So, e.g., fromInteger and fromRational could be replaced with convert. (But if you did the same thing with toInteger and toRational as well, you run into problems of overlapping instances. I think there are good semantic reasons for this: fromInteger and fromRational can be defined in terms of the basic +,*,zero,one, while toInteger and toRational rely on details of the representation.) What do people think of this idea in general? Perhaps a better name would be 'Subtype'? Note that "convert . convert" would be up there with "show . read" as an ambiguous term. Best, Dylan Thurston

3 4

Re: Fundeps and quantified constructors
by nubie nubie 07 Feb '01

07 Feb '01

--- Tom Pledger <Tom.Pledger(a)peace.com> wrote: > That line of reasoning establishes that e is constrained on the right > hand side of the "=". However, it's still bound (by an implicit > "forall e") on the left hand side of the "=". The problem is that e > can leak details about c to parts of the program outside the "forall > c". It's still a problem if you remove the "| c -> e" fundep. (1) How can it leak? (2) Why is this a problem? > A more common use of a "Collection c e | c -> e" class is: > > data SomeCollection e = --some data structure involving e > > instance SomeContext e => Collection (SomeCollection e) e where > --implementations of empty and put, for the aforementioned > --data structure, and entitled to assume SomeContext > > Is that collection type polymorphic enough for your purposes? You mean, like instance Collection [a] a where empty = [] put = flip (:) ? Yes, of course this usage is intended. But then I want a type that can hold any collection of a, for given a. Collection is a class, not a type, and I need a type. -- anatoli __________________________________________________ Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/

4 3

GHC 4.08.2: the release dribbles on
by Reuben Thomas 07 Feb '01

07 Feb '01

As of now, several things have been corrected: 1. Sparc HC files are available. 2. The Windows link actually points to the 4.08.2 release, not the 4.08.1 release. 3. RedHat 6 i386 RPMs are available. -- http://sc3d.org/rrt/ | computation, n. automated pedantry

1 0

New PhD Positions in Computing Science, Gothenburg, Sweden
by Reiner Haehnle 07 Feb '01

07 Feb '01

Please pass on to interested students. Apologies for multiple copies. --------------------------------------------------------------------- New PhD Positions (DEADLINE 1 March 2001! See "How to apply" below.) Department of Computing Science, Chalmers University of Technology & University of Gothenburg Sweden The Department has about 70 researchers, half being faculty members and half PhD students. Our focus is on programming logic, type theory, functional programming, formal methods, distributed and concurrent systems, security, algorithms, bioinformatics, human computer interaction, and computational linguistics, but research is not restricted to these topics. For more information, see http://www.cs.chalmers.se/Cs/Research. PhD positions are for 5 years. There is no tuition fee. A PhD position is a regular job with social benefits; the salary amounts currently to about 16700 SEK per month in the first year (the exact amount depends on teaching duties, usually 20% of your time). Knowledge of Swedish is not a prerequisite for application. English is our working language for research. Both Swedish and English are used in undergraduate courses. Half of our researchers and PhD students are native Swedes; the rest come from more than 20 different countries. Applicants must have a very good undergraduate degree in Computing Science or in a related subject with a strong Computing Science component. They must also have a strong interest in doing research. You may also apply if you have not yet completed your degree, but expect to do so by September 2001. You are also invited to apply for our new International Master's Programme in Dependable Computer Systems, which can help you to obtain the necessary qualification (see http://www.cs.chalmers.se/Cs/Education/dcs/) The School especially welcomes female applicants. How to apply ------------ First, immediately register your intention to apply using the electronic application form on the WWW via http://www.md.chalmers.se/Jobs/PhD/phd-01-en.thtml The full application should contain 1 A letter of application, listing specific research interests 2 A curriculum vitae 3 Attested copies of degrees and other certificates 4 Copies of relevant work, for example dissertations or articles, that you have authored or co-authored 5 A description of: a previous teaching experience, documented, if any b previous PhD studies, also in other subjects. State financial support for these, if any c previous work experience 6 Letters of recommendation from your teachers or employers If you have financial support of your own (industry job, grant, etc.), please state this fact clearly. It will increase your chances to be accepted considerably, because you need not compete for the limited number of fully financed positions. Send your application (paper mail) to Section for Mathematics and Computer Science Chalmers University of Technology 412 96 Gothenburg Sweden to arrive by 1 March 2000. You will know the result of your application by 1 May 2000.

1 0

RE: GHC Core Language
by Andrew Tolmach 07 Feb '01

07 Feb '01

[moving to haskell-cafe] > From: matt hellige [mailto:matt@immute.net] > a quick question re: ghc's Core language... is it still very similar > to the abstract syntax given in, for example, santos' "compilation by > transformation..." (i think it was his dissertation?) and > elsewhere, or > has it changed significantly in the last couple of years? i only ask > because i know the language used in that paper is somewhat > different from > the Core language given in peyton jones and lester's > "implementing functional > languages" from 92, and includes type annotations and so on. > > m > The current Core language is still quite similar to what is described in Santos' work; see SL Peyton Jones and A Santos, "A transformation-based optimiser for Haskell," Science of Computer Programming 32(1-3), pp3-47, September 1998. http://research.microsoft.com/Users/simonpj/papers/comp-by-trans-scp.ps.gz But there have been some noticeable changes; for example, function arguments are no longer required to be atomic. A more recent version of Core is partially described (omitting types) in SL Peyton Jones & S Marlowe, "Secrets of the Glasgow Haskell Compiler Inliner," IDL'99. http://research.microsoft.com/Users/simonpj/papers/inline.ps.gz

1 0

Re: Revamping the numeric classes
by Ketil Malde 07 Feb '01

07 Feb '01

Brian Boutel <brian(a)boutel.co.nz> writes: > * most usage of (+), (-), (*) is on numbers which support all of them. Yes, but the problem is that the way this is implemented is a nuisance and a hindrance to those who wants to apply these operators to different data types. Also, it means functions become less general than they need to be (or that they need to be parametrized by the necessary operators) E.g. way back, I wrote a simple differential equation solver. Now, the same function *could* have been applied to vector functions, except that I'd have to decide on how to implement all the "Num" stuff that really didn't fit well. Ideally, a nice class design would infer, or at least allow me to specify, the mathematical constraints inherent in an algorithm, and let my implementation work with any data satisfying those constraints. Obviously, a good and elegant, yet simple design of type classes is quite hard. I think it can be done, though. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

2 1

Implementing the Show class for a Hash
by Shlomi Fish 07 Feb '01

07 Feb '01

Hi! I've written a hash implementation in pure Haskell. The hash is more of a collection of elements organized in a table of linked lists, and it can serve as a dictionary by having each one be a key-value pair. However, I ran into problems when implementing the show function and hugs keeps reporting errors. Can anybody implement it for me based on the hash implementation, and the function which I have commented out? The URL for the code is : http://techst02.technion.ac.il/~shlomif/haskell/Hash/Hash.hs Regards, Shlomi Fish ---------------------------------------------------------------------- Shlomi Fish shlomif(a)vipe.technion.ac.il Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: shlomif(a)techie.com The prefix "God Said" has the extraordinary logical property of converting any statement that follows it into a true one.

1 0