- Haskell - Haskell.org

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

dependent types, type class contexts
by John D. Barnett 07 Apr '04

07 Apr '04

Hello- I'm interested in simulating dependent types in haskell, with the aim of operating on (as Oleg put it) "stanamically" sized lists: types reflect size constraints, but ultimately need to be resolved from dynamic input. I have a good handle on how to do this (read on), but I keep running into the same problems related to managing type class contexts. Ultimately, I think what I might want is a way of _excluding_ types from classes, or declaring classes closed. Much of this is a rehash of what others have presented; sorry if I don't give appropriate credit (Oleg, Okasaki, Hallgren, ...) Here's what I want to cover: - types/classes parallel algebraic data types - rank-2 polymorphic continuation to simulate dependent types - stanamically sized lists - (ditto) as a numeric type - contexts ?#$%#!!! - exclusion as a possible solution? The first part is familiar, and is exemplified in "Fun with Functional Dependencies"; this is the parallel between types/classes and algebraic data types. Just as we can define a type with values (and an example function on that type): > data Nat = Zero | Succ Nat > toInt :: Nat -> Int > toInt Zero = 0 > toInt (Succ x) = 1 + toInt x We can have a corresponding definition for a class and types: > class NatT a where > toIntT :: a -> Int > data ZeroT > instance NatT ZeroT where > toIntT ZeroT = 0 > data SuccT a > instance (NatT a) => NatT (SuccT a) where > toIntT (SuccT x) = 1 + toIntT x (Although functional dependencies can be used to essentially define functions/relations at the type level, I don't make use of that here.) So far so good. But what if I want to dynamically convert from Nat to NatT? I'd like a function defined as: < convert Zero = ZeroT < convert (Succ x) = SuccT (convert x) But this isn't legitmate; the return type depends on the input value. So first, we need an existential type to capture the return value: > data Nat' = forall a . NatT a > convert :: Nat -> Nat' A dependent return value isn't allowed, but we can use a rank-2 polymorphic continuation to simulate it: > convert x = convert_ x Nat' > convert_ :: Nat -> (forall a . NatT a => a -> b) -> b > convert_ Zero k = k ZeroT > convert_ (Succ x) k = convert_ x (\x' -> k (SuccT x')) By the way, although I've seen a few of you use this trick, is there proven theory to back this up-- that rank-2 polymorphism can simulate any function with a dependent type by using CPS? This brings me to lists; I'm actually playing around with nested datatypes (a la Okasaki's square matrices), but this suffices to make the connection: > class ListT a where > map0 :: b -> a b > map1 :: (b -> c) -> a b -> a c > map2 :: (b -> c -> d) -> a b -> a c -> a d > toList :: a b -> [b] > data NilT b = NilT > instance ListT NilT where > map0 _ = NilT > map1 _ _ = NilT > map2 _ _ _ = NilT > toList _ = [] > data ConsT a b = ConsT b (a b) > instance (ListT a) => ListT (ConsT a) where > map0 x = ConsT x (map0 x) > map1 f (ConsT x xs) = ConsT (f x) (map1 f xs) > map2 f (ConsT x xs) (ConsT y ys) = ConsT (f x y) (map2 f xs ys) > toList (ConsT x xs) = x:(toList xs) So, for instance, we can have a list (ConsT 1 (ConsT 2 (ConsT 3 NilT)))::((ConsT (ConsT (ConsT NilT))) Int) i.e., a list of length 3. Again, dynamic conversion can be supported by an existential type and polymorphic recursion (CPS): > data List' b = forall a . ListT a => List' (a b) > fromList' :: [b] -> List' b > fromList' l = fromList_ l List' > fromList_ :: [b] -> (forall a . ListT a => a b -> c) -> c > fromList_ [] k = k (NilT) > fromList_ (x:xs) k = fromList_ xs (\xs' -> ConsT x xs') Thus, (fromList' [1,2,3]) should yield the existential version of the list above. It's probably worth mentioning that I define another class method, fromList:: (ListT a) => [b] -> Maybe (a b), which only succeeds if the input is the correct length. This allows me to write two versions of a function: static and dynamic, as: > myZip :: (ListT a) => (a b) -> (a c) -> (a (b,c)) > myZip = map2 (,) > myZip' :: [b] -> [c] -> Maybe (List' (b,c)) > myZip' x y = do (List' x') <- return $ fromList' x -- convert, unwrap > y' <- fromList y > result <- myZip x' y' > return (List' result) Type inference forces x' and y' to have the same type; this determines at which type fromList is applied, which succeeds or fails depending on the size of the input. I've swept some details under the rug-- see what you need to do to make appropriate instances of Show, Eq. This becomes more relevant in trying to make a Num instance, so I can have automagically derived vector operations. Here's my goal: > instance (ListT a, Num b) => Num (a b) where > (+) = map2 (+) > (-) = map2 (-) > (*) = map2 (*) > negate = map1 negate > abs = map1 abs > signum = map1 signum > fromInteger = map0 . fromInteger This is where things start to get tricky. In order for the above to type-check (in ghc 6.2; I understand handling contexts may vary), I need to add (Show (a b), Eq (a b)) to the context. What I've elided is that I have already provided declarations > instance (ListT a, Eq b) => Eq (a b) > instance (ListT a, Show b) => Show (a b) which requires -fallow-overlapping-instances, as e.g., Eq (a b) overlaps with [b]. As I get deeper into the numeric type heirarchy, the contexts required become increasingly cumbersome; these ultimately make the existential type List' useless for any numeric types, and instead require me to use (IMHO) overly specified existential types. This gets at the crux of my questions: - Why can't the compiler tell that (ListT a, Num b) is enough to figure out the additional context it seems to need? - Would it be possible to _exclude_ a type from a class, to aviod overlapping instances? Perhaps what I want is negation in a type class declaration: < forall a . a /= [] => class ListT a Alternatively, I'd like to state that the _only_ instances of ListT are NilT and ConsT. Are there definitive references on context resolution (aside from the compiler source, which I have not looked at)? Has anyone grappled with these problems and come up with satisfactory solutions? Thanks for your help, and I'm happy to go into more detail. I tried to be brief, but, well, I didn't succeed. -John Barnett

2 1

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

06 Apr '04

Your word is my command. 'Tis done. Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Wolfgang | Jeltsch | Sent: 21 March 2004 17:55 | To: The Haskell Mailing List | Subject: [Haskell] deriving with newtypes | | Hello, | | I'm trying to use GHC's deriving mechanism for newtypes in the following way: | class C a b | instance C [a] Char | newtype T = T Char deriving C [a] | Unfortunately, this isn't possible. Is there a reason for this? Can I | circumvent this restriction? | | Wolfgang | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

3 2

Foclasa: Last Call for Papers
by Jean-Marie JACQUET 06 Apr '04

06 Apr '04

[ Our apologies for multiple copies. ] ====================================================================== 3nd International Workshop on Foundations of Coordination Languages and Software Architectures (Foclasa 2004) August 30, 2004, London, United Kingdom Workshop affiliated to CONCUR'2004, August 30 - September 3 2004. ====================================================================== SCOPE AND TOPICS Modern information systems rely more and more on combining concurrent, distributed, mobile and heterogenous components. This move from old systems, typically conceived in isolation, induces the need for new languages and software architectures. In particular, coordination languages have been proposed to cleanly separate computational aspects and communication. On the other hand, software architects face the problem of specifying and reasoning on non-functional requirements. All these issues are widely perceived as fundamental to improve software productivity, enhance maintainability, advocate modularity, promote reusability, and lead to systems more tractable and more amenable to verification and global analysis. The aim of the workshop is to bring together researchers working on the foundations of component-based computing, coordination, and software architectures. Topics of interest include (but are not limited to): o Theoretical models for coordination (component composition, concurrency, dynamic aspects of coordination, semantics, expressiveness); o Specification, refinement, and analysis of software archi- tectures (patterns and styles, verification of functional and non-functional properties); o Coordination, architectural, and interface description languages (implementation, interoperability, heterogeneity); o Agent-oriented languages (formal models for interacting agents); o Dynamic software architectures (mobile agents, configuration, reconfiguration); o Modeling of information systems (groupware, internet and the web, workflow management, CSCW and multimedia applications) o Coordination patterns (mobile computing, internet computing); o Tools and environments for the development of coordinated applications o Methodologies for validating and certifying software compositions SUBMISSION GUIDELINES Papers describing original work are solicited as contributions to Foclasa. Submitted papers should be limited to 6 000 words, preferrably formatted according to the Electronical Notes in Theoretical Computer Science. They should be emailed as PostScript (PS) or Portable Document Format (PDF) files to jmj(a)info.fundp.ac.be. PUBLICATION Following the previous edition, the proceedings will be published as a volume of the Electronical Notes in Theoretical Computer Science. IMPORTANT DATES: o June 5, 2004: Submission deadline. o July 15, 2004: Notification of acceptance. o August 15, 2004: Final version. o August 30, 2004: Meeting Date. LOCATION The workshop will be held in London in August 30 2004. It is a satellite workshop of CONCUR 2004. For venue and registration, see the CONCUR web page at http://www.doc.ic.ac.uk/concur2004/. WORKSHOP ORGANIZERS o Antonio Brogi (University of Pisa, Italy) o Jean-Marie Jacquet (University of Namur, Belgium) o Ernesto Pimentel (University of Malaga, Spain) PROGRAMME COMITTEE (provisional): o Farhad Arbab (CWI, The Netherlands) o Antonio Brogi (University of Pisa, Italy) - Co-chair o Manfred Broy (University of Munich, Germany) o Jean-Marie Jacquet (University of Namur, Belgium) - Co-chair o Joost Kok (University of Leiden, The Netherlands) o Antonia Lopes (University of Lisbon, Portugal) o Ronaldo Menezes (Florida Institute of Technology, USA) o Ernesto Pimentel (University of Malaga, Spain) - Co-chair o Sebastian Uchitel (Imperial College, United Kingdom) o Mirko Viroli (University of Bologna, Italy) o Jan Vitek (Purdue University, USA)

1 0

ANNOUNCE: Haskell XML Toolbox Version 4.00
by Uwe Schmidt 06 Apr '04

06 Apr '04

Haskell XML Toolbox 4.00 I would like to announce a new version of the Haskell XML Toolbox for processing XML including a validating parser and a new XPath module. new features: * compiles with ghc version 6.2 * new module structure for input modules to ease porting to other OS/compilers * new example programs More information and download: http://www.fh-wedel.de/~si/HXmlToolbox/index.html Please email comments, bugs, etc. to hxmltoolbox(a)fh-wedel.de Uwe Schmidt <uwe(a)fh-wedel.de> -- University of Applied Sciences, Wedel, Germany http://www.fh-wedel.de/~si/index.html

1 0