April 2004 - Haskell - Haskell.org

CICLOPS 2004: Second CFP
by Manuel Carro 09 Apr '04

09 Apr '04

[Please accept our apologies if you receive this message several times] --------------------------------------------------------------------------- C A L L F O R P A P E R S CICLOPS 2004 Colloquium on Implementation of Constraint and LOgic Programming Systems to be held at Saint-Malo (France) at the occasion of ICLP'04 September, 2004 http://clip.dia.fi.upm.es/Conferences/CICLOPS-2004 --------------------------------------------------------------------------- Topics of interest ------------------ This workshop aims at discussing and exchanging experience on the design, implementation, and optimization of logic, constraint (logic) programming systems, and systems intimately related to logic as a means to express computations. Experience backed up by real implementations and their evaluation will be given preference, as well as descriptions of work in progress in that direction. Topics include, but are not limited to: * Standard and alternative sequential implementation schemes (e.g., generalization / modification of the WAM, translation to lower-level and/or general-purpose languages, etc.) * Interaction between high-level optimizations / transformations / specialization and low-level issues. * Compile-time analysis and its application to code generation. * Low-level cost models to guide high-level optimizations. * Memory management, indexing, and garbage collection issues. * Balance between compile-time effort and run-time machinery. * Implementation of parallel and concurrent logic and constraint programming systems. * Implementation techniques for declarative programming paradigms with basis on, or extending, logic and constraint programming, such as non-monotonic reasoning, inductive logic programming, etc. * Implementation of systems closely related to, or based on, logic, such as theorem provers and natural language processing systems. * Performance evaluation of logic and constraint programming systems. * User oriented tools for performance evaluation and profiling. * Software design with and for LP/CP systems: components, patterns, etc. * Design and implementation of programming environments. * Experiences from using systems in real-life applications. Important dates --------------- * submission deadline: April 26 * notification of acceptance: May 24 * final version due: June 14 * workshop dates: still to be decided (they depend on the organization of ICLP 2004) Workshop Goals -------------- Our intent is to bring together, in an informal setting, people involved in research on sequential and parallel implementation technologies for logic and constraint programming languages and systems, in order to promote the exchange of ideas and feedback on recent developments. We hope that the workshop will provide a meeting point for people working on implementation technology for different aspects of logic and constraint-based languages and systems. Rationale and History --------------------- The last years have witnessed continuous progress in the technology available both for academic and commercial computing environments. Examples include more processor performance, increased memory capacity and bandwidth, faster networking technology, and operating system support for cluster computing. These improvements, combined with recent advances in compilation and implementation technologies, are causing high-level languages to be regarded as good candidates for programming complex, real world applications. Techniques aiming at achieving flexibility in the language design make powerful extensions easier to implement; on the other hand, implementations which reach good performance in terms of speed and memory consumption make declarative languages and systems amenable to develop non-trivial applications. Logic Programming and Constraint Programming, in particular, seem to offer one of the best options, as they couple a high level of abstraction and a declarative nature with an extreme flexibility in the design of their implementations and extensions and of their execution model. This adaptability is key to, for example, the implicit exploitation of alternative execution strategies tailored for different applications (e.g., for domain-specific languages) without jeopardizing efficiency unnecessarily. This workshop continues a tradition of successful workshops on Implementations of Logic Programming Systems, previously held with in Budapest (1993) and Ithaca (1994), the Compulog Net workshops on Parallelism and Implementation Technologies held in Madrid (1993 and 1994), Utrecht (1995) and Bonn (1996), the Workshop on Parallelism and Implementation Technology for (Constraint) Logic Programming Languages held in Port Jefferson (1997), Manchester (1998), Las Cruces (1999), and London (2000), and more recently the Colloquium on Implementation of Constraint and LOgic Programming Systems in Paphos (Cyprus, 2001), Copenhagen (2002), and Mumbai (2003), and the CoLogNet Workshops on Implementation Technology for Computational Logic Systems held in Madrid (2002) and Pisa (2003). Submission Information ---------------------- Authors are invited to submit papers written in English and not exceeding 12 pages. To speed up the process of refereeing, authors are requested to submit their paper in Postscript or PDF form. Hard copies may be sent to the contact address below only if access to electronic media is not available; please contact the organizers beforehand if that is the case. Submissions should contain full return mail and email address (if applicable) and FAX number (if applicable) of the contact author. Prospective authors are kindly requested to first send an indication of interest together with a paper title and abstract, in plain text format, to the organizers at the e-mail address at the bottom of the page. LaTeX style files are available via WWW at the Workshop web site. We strongly encourage their use, both in the preparation of submissions and, specially, for the final version. In order to obtain homogeneous workshop proceedings, authors of accepted papers will be requested to send the sources to the organizers. Authors who wish to prepare papers in formats other than LaTeX are kindly requested to contact the organization beforehand in order to make sure that we have available the right tools to process the files (if needed), or in order to receive detailed format instructions otherwise. Organization ------------ Program Committee: * Manuel Carro (Spain) * Ricardo Lopes (Portugal) * José F. Morales (Spain) * Enrico Pontelli (USA) * Vítor Santos (Brazil) * Tom Schrijvers (Belgium) * Christian Schulte (Sweden) * Paul Tarau (USA) * Neng-Fa Zhou (USA) Workshop Coordinators: Manuel Carro (contact person) José F. Morales http://lml.ls.fi.upm.es/~mcarro http://clip.dia.fi.upm.es/~jfran Phone: +34-91-3367455 Phone: +34-91-3367448 Fax: +34-91-3366595 Fax: +34-91-3366595 Invited Speaker: To be announced Contact Please address any question regarding the workshop organization to the address ciclops-org(a)clip.dia.fi.upm.es -- +---------------------------------------------------------------------------+ |Manuel Carro --- Facultad de Informática -- U. Politécnica de Madrid (UPM) | |mcarro_at_fi_dot_upm_dot_es --- Ph: +34-91336-7455 --- FAX: +34-91336-7412 | |http://lml.ls.fi.upm.es/~mcarro --- http://clip.dia.fi.upm.es/Software/Ciao|

1 0

Re: sequences
by Robert Will 09 Apr '04

09 Apr '04

Apologies, I sent this to the wrong list. It should go to Libraries... Robert ---------- Forwarded message ---------- hi Ross and others, On Wed, 7 Apr 2004, Robert Will wrote: > > On Mon, 5 Apr 2004 ross(a)soi.city.ac.uk wrote: > > > To have something concrete to discuss, I've placed a structure based on > > Edison at > > docs: http://www.soi.city.ac.uk/~ross/seq/ > > code: http://www.soi.city.ac.uk/~ross/seq.tar.gz Really, since you have read the comparison of my Abstract Collections with Edison, you should have said one word, why you choose Edison as a basis and not mine. Well, I gues the reason is just that you don't want MPTC and that you're perhaps afraid of all my new terminology while Edisons names sound so familiar. So here is a short argument in favour of my choices: 1. The class "OperationalSequence" in the Abstract Collections is an MPTC that makes no restrictions on the element type. I dubbed it "Operational", because without an equality over Sequences we can't give executable algebraic specifications. It uses MPTC for a debatable reason: to be part of the framework of Abstract Collections. (The source file explains why we can't mix SPTC and MPTC code.) But is that really so bad? MPTC work on all major compilers and no-one doubts they will be in a future standard. Furthermore, since it uses Constructor Classes (just like Edison) there are no ambiguity problems that would involve FunDeps! 2. Also the names are choosen not to be compatible with the past, but to be combatible with the future: the names of the Sequence operations fit well with those of all other Collections. Many names are shared and have the same semantics on all Collections. > PS: Dessy also started with (list-compatible) Sequences and than added the > rest. We should certainly not make that detour on the large scale. with "list-compatible" I mean starting with class members (cons head tail foldr foldl...) and then add many more. Really one should be looking for the common base of all sequence implementations and what's more all sequence applications. The absurdness of the "list-compatible" approach shows in the ridiculous default running times for 'cons' O(1) and 'snoc' O(n), really what's the big difference between those operations? The names alone are a nightmare: (cons snoc init tail head last left right) (as in lview, rview) and many functions that only work from the front. How many different names should we have for the front (with the first element) and the back (with the last element)? My proposal shows that those four terms (first last front back) suffice to name all useful functions on lists. Surely the naming approach taken for my Abstract Collections is no fundamental breaking with conventions: all the names and operators are either tradition in Haskell or tradition in Scheme or some consistent extension of this (e.g. (<:) and (>:) for 'add_first' and 'add_last'). Clearly my new names are easier to learn for novices, but I also claim that learning the whole library (i.e. the "compatible" functions and the new ones) is easier for the Abstract Collections than for Edison. Just because the names are more consistent, and still many names are like in standard Haskell. So I'd suggest, that a standard Sequence class should be based on the Abstract Collections. (And by the way, why not also think about Sets and Maps, you can use them now: "import Prelude (); import Collections" is not so hard to write!) By the way I think that the documentation for the Sequence instances in Ross' proposal is too redundant. The only thing we should need is a specification of the performance and of additional operations. I would propose the following time bounds: Defaults for Sequences: O(logN) for all operations, except O(1) for "atomic queries" (is_empty, first, last, size (or length)) This is the simplest to remember and a "democratic" implementation will just have those bounds. (And balanced tree does, Dessy has five of them.) Next thing needed are Deques: O(1) for (empty single <: >: first last but_first but_last is_empty) O(N) for the rest (JoinLists are like that with additional O(1) (++), so they're perhaps better called 'AppendableDeques'. Likewise CatenableLists are really AppendableStacks.) Write-only Sequences: (OrdList) O(1) for (empty single <: >: ++) O(N) for the rest One-side flexible Arrays or Random Access lists: are another very "algorithmic" structure, which support efficient 'update', a function that my Sequences don't even specify. This reminds me, that I haven't really seen any applications of Sequence data structures and that I decided anyway to get some examples before fixing the details of the class. By the way, there are already some examples of Maps and Sets at work: http://www.stud.tu-ilmenau.de/~robertw/dessy/fun/examples/ The only examples for Sequences is Okasakis Tree Enumeration using Deques and that doesn't look nice without views :-( Robert _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

1 0

Re: sequences
by Robert Will 09 Apr '04

09 Apr '04

hi Ross and others, On Wed, 7 Apr 2004, Robert Will wrote: > > On Mon, 5 Apr 2004 ross(a)soi.city.ac.uk wrote: > > > To have something concrete to discuss, I've placed a structure based on > > Edison at > > docs: http://www.soi.city.ac.uk/~ross/seq/ > > code: http://www.soi.city.ac.uk/~ross/seq.tar.gz Really, since you have read the comparison of my Abstract Collections with Edison, you should have said one word, why you choose Edison as a basis and not mine. Well, I gues the reason is just that you don't want MPTC and that you're perhaps afraid of all my new terminology while Edisons names sound so familiar. So here is a short argument in favour of my choices: 1. The class "OperationalSequence" in the Abstract Collections is an MPTC that makes no restrictions on the element type. I dubbed it "Operational", because without an equality over Sequences we can't give executable algebraic specifications. It uses MPTC for a debatable reason: to be part of the framework of Abstract Collections. (The source file explains why we can't mix SPTC and MPTC code.) But is that really so bad? MPTC work on all major compilers and no-one doubts they will be in a future standard. Furthermore, since it uses Constructor Classes (just like Edison) there are no ambiguity problems that would involve FunDeps! 2. Also the names are choosen not to be compatible with the past, but to be combatible with the future: the names of the Sequence operations fit well with those of all other Collections. Many names are shared and have the same semantics on all Collections. > PS: Dessy also started with (list-compatible) Sequences and than added the > rest. We should certainly not make that detour on the large scale. with "list-compatible" I mean starting with class members (cons head tail foldr foldl...) and then add many more. Really one should be looking for the common base of all sequence implementations and what's more all sequence applications. The absurdness of the "list-compatible" approach shows in the ridiculous default running times for 'cons' O(1) and 'snoc' O(n), really what's the big difference between those operations? The names alone are a nightmare: (cons snoc init tail head last left right) (as in lview, rview) and many functions that only work from the front. How many different names should we have for the front (with the first element) and the back (with the last element)? My proposal shows that those four terms (first last front back) suffice to name all useful functions on lists. Surely the naming approach taken for my Abstract Collections is no fundamental breaking with conventions: all the names and operators are either tradition in Haskell or tradition in Scheme or some consistent extension of this (e.g. (<:) and (>:) for 'add_first' and 'add_last'). Clearly my new names are easier to learn for novices, but I also claim that learning the whole library (i.e. the "compatible" functions and the new ones) is easier for the Abstract Collections than for Edison. Just because the names are more consistent, and still many names are like in standard Haskell. So I'd suggest, that a standard Sequence class should be based on the Abstract Collections. (And by the way, why not also think about Sets and Maps, you can use them now: "import Prelude (); import Collections" is not so hard to write!) By the way I think that the documentation for the Sequence instances in Ross' proposal is too redundant. The only thing we should need is a specification of the performance and of additional operations. I would propose the following time bounds: Defaults for Sequences: O(logN) for all operations, except O(1) for "atomic queries" (is_empty, first, last, size (or length)) This is the simplest to remember and a "democratic" implementation will just have those bounds. (And balanced tree does, Dessy has five of them.) Next thing needed are Deques: O(1) for (empty single <: >: first last but_first but_last is_empty) O(N) for the rest (JoinLists are like that with additional O(1) (++), so they're perhaps better called 'AppendableDeques'. Likewise CatenableLists are really AppendableStacks.) Write-only Sequences: (OrdList) O(1) for (empty single <: >: ++) O(N) for the rest One-side flexible Arrays or Random Access lists: are another very "algorithmic" structure, which support efficient 'update', a function that my Sequences don't even specify. This reminds me, that I haven't really seen any applications of Sequence data structures and that I decided anyway to get some examples before fixing the details of the class. By the way, there are already some examples of Maps and Sets at work: http://www.stud.tu-ilmenau.de/~robertw/dessy/fun/examples/ The only examples for Sequences is Okasakis Tree Enumeration using Deques and that doesn't look nice without views :-( Robert

1 0

RE: [Haskell] overuse of maybe and [] in prelude and libs
by Simon Peyton-Jones 09 Apr '04

09 Apr '04

Alex You've become a very sophisticated Haskell programmer! We did at one stage do something like this, by making list comprehensions into monad comprehensions. So [ x*x | x <- xs, pred x] meant the same as do { x <- xs; if pred x then mzero else return (); return (x*x)} But in the next iteration of the language we undid the change, a controversial decision that some still regret. Because naïve users were getting too many perplexing error messages about monads and functors when they thought they were just manipulating lists. Haskell is pretty good about letting you install a different Prelude, so you could try it yourself. Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of S. Alexander | Jacobson | Sent: 08 April 2004 04:42 | To: Haskell Mailing List | Subject: [Haskell] overuse of maybe and [] in prelude and libs | | It feels like the Prelude insists on using [] and | Maybe too much. I keep writing things like this: | | foo = foldl union emptySet $ maybe mzero return $ lookup pairs key | goo = maybe emptySet toSomething $ lookup pairs key | | which really should look like this: | | foo = concat $ lookup pairs key | goo = fmap toSomething $ lookup pairs key | | But, even if we don't have a Monadic/Functor Set, | foo should at least be: | | foo = foldl union emptySet $ lookup key | | In other words, shouldn't Prelude define concat | and lookup as: | | concat = foldr mplus mzero -- (Also, see PS) | | lookup key [] = mzero | lookup key ((x,y):xyz) | | key == x = return y | | otherwise = lookup key xyz | | And if it is a fundamental problem adding | constraints to instances, why not add all | automatically derivable classes as constraints to | all the Prelude classes (esp. Monad and Functor!) | and automatically derive instances of all | derivable classes unless the programmer defines | his/own methods. | | -Alex- | | PS Shouldn't concat be defined with foldl and not | foldr? Doesn't foldr imply that you can't concat | infinite lists? (I know this is a FAQ, but | where?) | | _________________________________________________________________ | S. Alexander Jacobson mailto:me@alexjacobson.com | tel:917-770-6565 http://alexjacobson.com | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

3 3

RE: [Haskell] overuse of maybe and [] in prelude and libs
by Simon Peyton-Jones 08 Apr '04

08 Apr '04

| > Haskell is pretty good about letting you install a different Prelude, so you could try it yourself. | | Hmm. That's interesting! How does this work? It's very simple. Write your own Prelude as a Haskell module MyPrelude. Then to use it, say module Foo where import Prelude () import MyPrelude (GHC lets you omit the 'import Prelude ()' by saying -fno-implicit-prelude.) No, there is no auto-magic; you are simply getting a different library, that is all. And you have to write that library. No problem with some modules using MyPrelude and some using Prelude. (Any more than there's a problem when some modules import module A and some import module B.) Actually Haskell doesn't let you redefine *everything*, but GHC does: read section 7.3.5 of the GHC manual http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.htm l#REBINDABLE-SYNTAX Simon

2 1

RE: Coginitive Dimensions and Haskell (was RE: [Haskell] overuse of maybe and [] in prelude and libs)
by Simon Peyton-Jones 08 Apr '04

08 Apr '04

Alas, no. Simon | -----Original Message----- | From: S. Alexander Jacobson [mailto:alex@alexjacobson.com] | Sent: 08 April 2004 17:25 | To: Simon Peyton-Jones | Cc: Haskell Mailing List | Subject: Coginitive Dimensions and Haskell (was RE: [Haskell] overuse of maybe and [] in prelude and | libs) | | Also, out of curiosity (since you are at MSFT) are | you using any formal Cognitive Dimension stuff in | the design of Haskell or its libraries? | | http://www.gotdotnet.com/team/brada/describingandevaluatingapiusabilityatmi… | | Your Excel paper is mentioned in the end-notes. | http://research.microsoft.com/Users/simonpj/papers/excel/excel.pdf | | If so, is there a publicly available CD analysis | of Haskell and its libs available? | | -Alex- | | _________________________________________________________________ | S. Alexander Jacobson mailto:me@alexjacobson.com | tel:917-770-6565 http://alexjacobson.com | | | On Thu, 8 Apr 2004, Simon Peyton-Jones wrote: | | > Alex | > | > You've become a very sophisticated Haskell programmer! | > | > We did at one stage do something like this, by making list comprehensions into monad | comprehensions. So | > [ x*x | x <- xs, pred x] | > meant the same as | > do { x <- xs; if pred x then mzero else return (); return (x*x)} | > | > But in the next iteration of the language we undid the change, a controversial decision that some | still regret. Because naïve users were getting too many perplexing error messages about monads and | functors when they thought they were just manipulating lists. | > | > Haskell is pretty good about letting you install a different Prelude, so you could try it yourself. | > | > Simon | > | > | -----Original Message----- | > | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of S. | Alexander | > | Jacobson | > | Sent: 08 April 2004 04:42 | > | To: Haskell Mailing List | > | Subject: [Haskell] overuse of maybe and [] in prelude and libs | > | | > | It feels like the Prelude insists on using [] and | > | Maybe too much. I keep writing things like this: | > | | > | foo = foldl union emptySet $ maybe mzero return $ lookup pairs key | > | goo = maybe emptySet toSomething $ lookup pairs key | > | | > | which really should look like this: | > | | > | foo = concat $ lookup pairs key | > | goo = fmap toSomething $ lookup pairs key | > | | > | But, even if we don't have a Monadic/Functor Set, | > | foo should at least be: | > | | > | foo = foldl union emptySet $ lookup key | > | | > | In other words, shouldn't Prelude define concat | > | and lookup as: | > | | > | concat = foldr mplus mzero -- (Also, see PS) | > | | > | lookup key [] = mzero | > | lookup key ((x,y):xyz) | > | | key == x = return y | > | | otherwise = lookup key xyz | > | | > | And if it is a fundamental problem adding | > | constraints to instances, why not add all | > | automatically derivable classes as constraints to | > | all the Prelude classes (esp. Monad and Functor!) | > | and automatically derive instances of all | > | derivable classes unless the programmer defines | > | his/own methods. | > | | > | -Alex- | > | | > | PS Shouldn't concat be defined with foldl and not | > | foldr? Doesn't foldr imply that you can't concat | > | infinite lists? (I know this is a FAQ, but | > | where?) | > | | > | _________________________________________________________________ | > | S. Alexander Jacobson mailto:me@alexjacobson.com | > | tel:917-770-6565 http://alexjacobson.com | > | _______________________________________________ | > | Haskell mailing list | > | Haskell(a)haskell.org | > | http://www.haskell.org/mailman/listinfo/haskell | >

1 0

hirarchical module system qualifiers
by Iavor S. Diatchki 08 Apr '04

08 Apr '04

hello, i have been using the hirarchical module system quite a bit lately, and i often find myself writing things like: import Syntax.Core.Struct as Struct import Utils.Set as Set etc. this is not a big bother, but it leads to clutter, and a few times i got errors, becasue i forgot to add the "as" clause. i would like to propose that by default, the qualified names introduced by an import are just the last part of the module name, and not the entire module name. the downside of this proposal is that it makes the "." in the module name mean something, but i am not sure that this is a bad thing. i think such a change should not break many programs, as i suspect not many people use qualified names, where the qualifiers are more than one "word" long. i also speculate that such a change should be relatively easy to implement. another benefit of such a change is that it makes export lists shorter. for example, currently one needs to write the following: module Syntax.Core.Struct (module Syntax.Core.Struct, module Names) where import Syntax.Core.Names as Names there doesn't seem to be a work around this, as we cannot give an alternative qualifier for the module we are defining. if the qualifier however was just the last part of the name, we would have shorter exports (and also shorter qualifiers for locally defined names). i am curious to hear what people think about that. bye iavor

2 1

Re: overuse of maybe and [] in prelude and libs, PS
by Janis Voigtlaender 08 Apr '04

08 Apr '04

> Subject: [Haskell] overuse of maybe and [] in prelude and libs > Date: Wed, 7 Apr 2004 23:41:55 -0400 (Eastern Standard Time) > From: "S. Alexander Jacobson" <alex(a)alexjacobson.com> > To: Haskell Mailing List <haskell(a)CS.YALE.EDU> > > ... > > PS Shouldn't concat be defined with foldl and not > foldr? Doesn't foldr imply that you can't concat > infinite lists? (I know this is a FAQ, but > where?) Quite in contrary: foldl (++) [] [[i] | i <- [1..]] fails to terminate, whereas foldr (++) [] [[i] | i <- [1..]] happily produces output. Ciao, Janis. -- Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de

2 1

overuse of maybe and [] in prelude and libs
by S. Alexander Jacobson 08 Apr '04

08 Apr '04

It feels like the Prelude insists on using [] and Maybe too much. I keep writing things like this: foo = foldl union emptySet $ maybe mzero return $ lookup pairs key goo = maybe emptySet toSomething $ lookup pairs key which really should look like this: foo = concat $ lookup pairs key goo = fmap toSomething $ lookup pairs key But, even if we don't have a Monadic/Functor Set, foo should at least be: foo = foldl union emptySet $ lookup key In other words, shouldn't Prelude define concat and lookup as: concat = foldr mplus mzero -- (Also, see PS) lookup key [] = mzero lookup key ((x,y):xyz) | key == x = return y | otherwise = lookup key xyz And if it is a fundamental problem adding constraints to instances, why not add all automatically derivable classes as constraints to all the Prelude classes (esp. Monad and Functor!) and automatically derive instances of all derivable classes unless the programmer defines his/own methods. -Alex- PS Shouldn't concat be defined with foldl and not foldr? Doesn't foldr imply that you can't concat infinite lists? (I know this is a FAQ, but where?) _________________________________________________________________ S. Alexander Jacobson mailto:me@alexjacobson.com tel:917-770-6565 http://alexjacobson.com

1 0

RE: [Haskell] deriving with newtypes
by Simon Peyton-Jones 07 Apr '04

07 Apr '04

| It looks like this lets you use partially applied type classes in a | deriving clause, always apllying that class to the new type last. This | looks nice, but wouldn't work so well if your newtype was supposed to go | first | | class C a b | instance Char [a] | newtype T = T Char deriving C ?? | | Maybe a deriving clause should allow full instance heads instead as well | as class names, so you could write "deriving C T [a]". (Maybe with | some restrictions, like ensuring the new type appears, or is one of the | class arguments). | | It seems more regular to allow you to derive an instance of a | multi-paramater typeclass with your class in any position rather than just | the last. Maybe so, but the Haskell 98 deriving( Num ) already has a class that is "missing" its last parameter. That's why it is the way it is currently. Furthermore, Haskell already has many places in which the order of type parameters matters. For example, if you want to declare instance Monad (ST s) where... that only works because ST's type params are in the right order. So what you say makes sense, but I think it'd be best to await more people who actually need the extra expressive power before elaborating this feature. For one thing, I have absolutely no idea how many people use GHC's newtype-deriving feature. Let me know! Simon

1 0