- Haskell - Haskell.org

Keyword arguments
by oleg＠pobox.com 13 Aug '04

13 Aug '04

We show the Haskell implementation of keyword arguments, which goes well beyond records (e.g., in permitting the re-use of labels). Keyword arguments indeed look just like regular, positional arguments. However, keyword arguments may appear in any order. Furthermore, one may associate defaults with some keywords; the corresponding arguments may then be omitted. It is a type error to omit a required keyword argument. The latter property is in stark contrast with the conventional way of emulating keyword arguments via records. Also in marked contrast with records, keyword labels may be reused throughout the code with no restriction; the same label may be associated with arguments of different types in different functions. Labels of Haskell records may not be re-used. Our solution is essentially equivalent to keyword arguments of DSSSL Scheme or labels of OCaml. Keyword argument functions are naturally polyvariadic: Haskell does support varargs! Keyword argument functions may be polymorphic. As usual, functions with keyword arguments may be partially applied. On the downside, sometimes one has to specify the type of the return value of the function (if the keyword argument function has no signature -- the latter is the norm, see below) -- provided that the compiler cannot figure the return type out on its own. This is usually only the case when we use keyword functions at the top level (GHCi prompt). Our solution requires no special extensions to Haskell and works with the existing Haskell compilers; it is tested on GHC 6.0.1. The overlapping instances extension is not necessary (albeit it is convenient). The gist of our implementation is the realization that the type of a function is a polymorphic collection of its argument types -- a collection that we can traverse. This message thus illustrates a limited form of the reflection on a function. Our implementation is a trivial extension of the strongly-typed polymorphic open records described in http://homepages.cwi.nl/~ralf/HList/ In fact, the implementation relies on the HList library. To run the code (which this message is), one needs to download the HList library from the above site. The HList paper discusses the issue of labels in some detail. The paper gives three different representations. One of them needs no overlapping instances and is very portable. In this message, we chose a representation that relies on generic type equality and therefore needs overlapping instances as implemented in GHC. Again, this is merely an outcome of our non-deterministic choice. It should be emphasized that other choices are possible, which do not depend on overlapping instances at all. Please see the HList paper for details. > {-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-} > {-# OPTIONS -fallow-overlapping-instances #-} > > module KW where > > import FakePrelude hiding (TypeEq,typeEq,proxyEq,TypeCast,typeCast) > import TypeEqGeneric2 > import TypeCastGeneric2 > import HListPrelude We will be using an example inspired by a graphics toolkit -- the area which really benefits from keyword arguments. We first define our labels and useful datatypes > data Color = Color > data Size = Size > data Origin = Origin > data RaisedBorder = RaisedBorder > > data CommonColor = Red | Green | Blue deriving Show > data RGBColor = RGBColor Int Int Int deriving Show and two functions: > make_square Size n Origin (x0,y0) Color (color::CommonColor) = > unwords ["Square:", show n, "at", show (x0,y0), show color] ++ "\n" > > make_rect Size (nx,ny) Origin (x0,y0) Color (color::RGBColor) > RaisedBorder border = > unwords ["Rectangle:", show (nx,ny), "at", show (x0,y0), > show color, if border then "raised border" else ""] ++ "\n" We are not interested in really drawing squares and rectangles here. Therefore, make_square and make_rect return a String, which we can regard as a ``command'' to be passed to a low-level graphics library. The functions make_square and make_rect are genuine functions and can be used as such. They are not keyword argument functions, yet, but they set the stage. These functions can be considered an `interface' for the keyword argument functions. We should note that the functions are polymorphic: for example, `Size' can be any showable. We must also emphasize the re-use of the labels: The Color of a square is the value of the enumerated type CommonColor. OTH, the color of the rectangle is given as an RGB triple. The sizes of the square and of the rectangle are specified differently too, the same label notwithstanding. Once the user wrote the functions such as make_square and make_rect, he can _automatically_ convert them to their keyword alternatives. This transformation is done by a function 'kw'. The user should pass the positional-argument function (`labeled' as above), and an HList of default values for some of the labels. The latter may be HNil if all keyword arguments are required. The first example (no defaults) > tests1 :: String = > kw make_square HNil Size (1::Int) Origin (0::Int,10::Int) Color Red we can permute the arguments at wish > tests2 :: String = > kw make_square HNil Color Red Size (1::Int) Origin (0::Int,10::Int) we can also assign a name to a keyword function, or partially apply it: > tests3 = let f x = kw make_square HNil Color Red x > in "here: " ++ f Origin (0::Int,10::Int) Size (1::Int) The dummy argument 'x' is merely to avoid the monomorphic restriction. The following is a more interesting example, with the defaults: > tests4 = let defaults = Origin .*. (0::Int,10::Int) .*. > RaisedBorder .*. True .*. > HNil > in kw make_square defaults Size (1::Int) Color Red ++ > kw make_rect defaults Color (RGBColor 0 10 255) > Size (1.0::Float, 2.0::Float) The argument RaisedBorder is not given, and so the default value is used. Of course, we can override the default: > tests5 = let defaults = Origin .*. (0::Int,10::Int) .*. > RaisedBorder .*. True .*. > HNil > sq x = kw make_square defaults Color x > re x = kw make_rect defaults x > in sq Red Size (1::Int) ++ > re Color (RGBColor 0 10 255) > RaisedBorder False > Size (1.0::Float, 2.0::Float) We have reshuffled a few arguments, just for fun. As you can see, the function `kw make_rect defaults' is polyvariadic indeed. We chose to partially apply 'Color' to the function `kw make_square defaults' -- so that the function `sq' is positional in its first argument, and keyword in the rest. If we omit a required argument, we get a type error: ] testse1 = let f x = kw make_square HNil Color Red x ] in "here: " ++ f Origin (0::Int,10::Int) Couldn't match `ErrReqdArgNotFound Size' against `[Char]' Expected type: ErrReqdArgNotFound Size Inferred type: [Char] ... The error message seems reasonably clear. Likewise we get an error message if we pass to a keyword function an argument it does not expect: ] testse2 = let f x = kw make_square HNil Color Red x ] in "here: " ++ f Origin (0::Int,10::Int) Size (1::Int) ] RaisedBorder False No instances for (Fail (ErrUnexpectedKW RaisedBorder), KWApply [Char] (HCons RaisedBorder (:*: Bool HNil)) [Char]) arising from use of `f' at ... In the second argument of `(++)', namely `f Origin (0 :: Int, 10 :: Int) Size (1 :: Int) RaisedBorder False' The function 'kw' receives the appropriately labeled function (such as make_square) and the HList with default values. The function 'kw' is polymorphic; the overloading is resolved based on the type of the user function *and* on the type of its continuation. The continuation indicates if a keyword argument is forthcoming, or not. In the latter case, 'kw' checks to see if the supplied defaults can provide the values of the still missing arguments. We see therefore that a function type is more than it may appear -- the type of a function is truly a heterogeneous, type level collection! The function 'kw' traverses that collection, thus performing a limited form of reflection on Haskell functions. Implementation Outline One of the key tools of the implementation is 'kwapply', which applies a function to a polymorphic collection of that function's arguments. The order of the arguments in the collection is irrelevant. The contraption kwapply can handle polymorphic functions with arbitrary number of labeled arguments. For example, if we define > f1 Size n = show n > f2 Size n Color m = unwords ["size:", show n, "color:", show m] > f3 Origin x Color m Size n = > unwords ["origin:", show x, "size:", show n, "color:",show m] then we can run > katest1 = kwapply f1 (Size .*. () .*. HNil) > katest11 = kwapply f1 (Size .*. "Large" .*. HNil) > > katest2 = kwapply f2 (Size .*. (1::Int) .*. Color .*. Red .*. HNil) > katest21 = kwapply f2 (Color .*. Red .*. Size .*. (1::Int) .*. HNil) > > katest3 = kwapply f3 (Size .*. (1::Int) .*. Origin .*. (2.0::Float) .*. > Color .*. Red .*. HNil) Another key contraption is > reflect_fk:: (ReflectFK fn kws) => fn -> Arg kws HNil > reflect_fk _ = Arg HNil that reflects on a user-supplied function. It converts the *type* of a user function to a collection of keywords required by that function. This and the previous contraptions may be used to define an `extended' version of some user function that takes more arguments -- without the need to enumerate all arguments of the original function. We thus infringe on the area of object and module systems. The rest of the implementation is just to convert `kw fn defaults' into the application of kwapply. The rest of the implementation We should note that all implementation is written in the continuation-passing style (CPS) -- at the term level and especially at the _typeclass level_. One of the reasons is to avoid relying on overlapping instances: we compare types with a predicate `TypeEq x y hbool', obtain the type-level boolean, and dispatch to two non-overlapping instances of an auxiliary, continuation class. One instance handles HTrue, and the other the HFalse alternative. Please see the HList paper for more discussion of this technique. The other, equally important reason for the thorough CPS of the typeclasses is to control the order of evaluation of constraints and their functional dependencies. The sole reason is to produce informative error messages. The order of constraints is irrelevant when all the constraints are satisfied. However, if the user omitted a required keyword, many of the constraints below will fail. If a 'wrong' constraint fails first, we get a totally off-the-wall error message that gives us no clue whatsoever about the problem. By tightly constraining the order via CPS, we are able to force the typechecker to give informative error messages. Preliminaries > -- A bit of syntax sugar for HLists > infixr 1 :*: > infixr 1 .*. > type e :*: l = HCons e l > (.*.) = HCons Errors > data ErrReqdArgNotFound x > data ErrUnexpectedKW x > data Trace x All our keywords must be registered > class IsKeyFN t flag | t-> flag > instance IsKeyFN (Color->a->b) HTrue > instance IsKeyFN (Size->a->b) HTrue > instance IsKeyFN (Origin->a->b) HTrue > instance IsKeyFN (RaisedBorder->a->b) HTrue > instance TypeCast HFalse flag => IsKeyFN t flag The implementation of KWApply > class KWApply f arg_values r | f arg_values -> r where > kwapply:: f -> arg_values -> r > > instance KWApply r HNil r where > kwapply f _ = f > > instance (TypeEq kw kw' flag, > KWApply' flag (kw->a->f') (kw' :*: a' :*: tail) r) > => KWApply (kw->a->f') (kw' :*: a' :*: tail) r where > kwapply = kwapply' (undefined::flag) > > class KWApply' flag f arg_values r | flag f arg_values -> r where > kwapply':: flag -> f -> arg_values -> r > > instance (TypeCast v' v, KWApply f' tail r) > => KWApply' HTrue (kw->v->f') (kw :*: v' :*: tail) r where > kwapply' _ f (HCons kw (HCons v' tail)) = > kwapply (f kw (typeCast v')) tail > > -- Rotate the arg list ... > instance (HAppend tail (kw :*: v :*: HNil) l', > KWApply f l' r) > => KWApply' HFalse f (kw :*: v :*: tail) r where > kwapply' _ f (HCons kw (HCons v tail)) = > kwapply f (hAppend tail (kw .*. v .*. HNil)) The datatype Arg below is to maintain the state of keyword accumulation: which keywords we need, and which keyword and values we have already got. arg_types is the phantom HList of keywords that are yet to be satisfied. arg_values is the HList (kw .*. kw_value .*. etc) of already found keywords and their values. > newtype Arg arg_types arg_values = Arg arg_values deriving Show Reflection on a function: Given a function, return the type list of its keywords > class ReflectFK f kws | f -> kws > instance (IsKeyFN f flag, ReflectFK' flag f kws) => ReflectFK f kws > class ReflectFK' flag f kws | flag f -> kws > instance ReflectFK rest kws => ReflectFK' HTrue (kw->a->rest) (HCons kw kws) > instance ReflectFK' HFalse f HNil -- :t reflect_fk (undefined::Size->Int->Color->CommonColor->String) -- :t reflect_fk (undefined::Size->Int->()->Int) The main class: collect and apply the keyword arguments > class KW f arg_desc arg_def r where > kwdo :: f -> arg_desc -> arg_def -> r > > instance (IsKeyFN r rflag, -- Fail (Trace (arg_desc,r)), > KW' rflag f arg_desc arg_def r) > => KW f arg_desc arg_def r where > kwdo = kw' (undefined::rflag) > > class KW' rflag f arg_desc arg_def r where > kw' :: rflag -> f -> arg_desc -> arg_def -> r If the continuation r does not promise any more keyword arguments, apply the defaults > instance KWMerge arg_needed arg_values arg_def f r > => KW' HFalse f (Arg arg_needed arg_values) arg_def r where > kw' _ f args_given arg_def = kwmerge args_given arg_def f Otherwise, collect the supplied keyword and its value, and recurse for more: > instance KWAcc arg_desc kw a f arg_def r > => KW' HTrue f arg_desc arg_def (kw->a->r) where > kw' _ f arg_desc arg_def kw a = kwaccum arg_desc kw a f arg_def Add the needed arguments from arg_def to arg_values and continue with kwapply. That is, we try to satisfy the missing arguments from the defaults. It will be a type error if some required arguments are missing > class KWMerge arg_needed arg_values arg_def f r | > arg_needed arg_values arg_def f -> r where > kwmerge:: Arg arg_needed arg_values -> arg_def -> f -> r > > instance KWApply f arg_values r > => KWMerge HNil arg_values arg_def f r where > kwmerge (Arg arg_values) _ f = kwapply f arg_values > > instance KWMerge' kw arg_def atail arg_values arg_def f r > => KWMerge (HCons kw atail) arg_values arg_def f r where > kwmerge (Arg arg_values) arg_def = > kwmerge' (undefined::kw) arg_def > ((Arg arg_values)::Arg atail arg_values) arg_def > > class KWMerge' kw list atail arg_values arg_def f r | > kw list atail arg_values arg_def f -> r where > kwmerge':: kw -> list -> (Arg atail arg_values) -> arg_def -> f -> r > > instance Fail (ErrReqdArgNotFound kw) > => KWMerge' kw HNil atail arg_values arg_def f > (ErrReqdArgNotFound kw) where > kwmerge' = undefined > instance (TypeEq kw kw' flag, > KWMerge'' flag kw (kw' :*: etc) atail arg_values arg_def f r) > => KWMerge' kw (kw' :*: etc) atail arg_values arg_def f r where > kwmerge' = kwmerge'' (undefined::flag) > > class KWMerge'' flag kw list atail arg_values arg_def f r | > flag kw list atail arg_values arg_def f -> r where > kwmerge'':: flag -> kw -> list -> (Arg atail arg_values) -> arg_def > -> f -> r > instance KWMerge atail (kw :*: v :*: arg_values) arg_def f r > => KWMerge'' HTrue kw (kw :*: v :*: tail) > atail arg_values arg_def f r where > kwmerge'' _ _ (HCons kw (HCons v _)) (Arg arg_values) = > kwmerge ((Arg (kw .*. v .*. arg_values)):: > (Arg atail (kw :*: v :*: arg_values))) > instance KWMerge' kw tail atail arg_values arg_def f r > => KWMerge'' HFalse kw (kw' :*: v' :*: tail) > atail arg_values arg_def f r where > kwmerge'' _ kw (HCons _ (HCons _ tail)) = kwmerge' kw tail Add the real argument to the Arg structure, and continue > class KWAcc arg_desc kw a f arg_def r where > kwaccum:: arg_desc -> kw -> a -> f -> arg_def -> r > > instance (HDelete kw arg_types arg_types', > KW f (Arg arg_types' (kw :*: a :*: arg_values)) arg_def r) > => KWAcc (Arg arg_types arg_values) kw a f arg_def r where > kwaccum (Arg arg_values) kw a f = > kwdo f (Arg (kw .*. a .*. arg_values):: > Arg arg_types' (kw :*: a :*: arg_values)) Delete e from l to yield l' The element e must occur in l > class HDelete e l l' | e l -> l' > instance Fail (ErrUnexpectedKW e) => HDelete e HNil HNil > instance (TypeEq e e' flag, HDelete' flag e (HCons e' tail) l') > => HDelete e (HCons e' tail) l' > class HDelete' flag e l l' | flag e l -> l' > instance HDelete' HTrue e (HCons e tail) tail > instance HDelete e tail tail' > => HDelete' HFalse e (HCons e' tail) (HCons e' tail') Finally, > kw f = kwdo f (reflect_fk f)

1 0

Re: [Haskell] Dependent Types in Haskell [was: Eliminating Array Bound Checking through Non-dependent] types
by MR K P SCHUPKE 11 Aug '04

11 Aug '04

>This will only work for terminating programs! Interesting point, but thats because all the operations are at the type level - therefore if a type is unknown at compile time we cannot produce a program. With this type class stuff values can depend on types, but not the other way around. You can sort of do reification (types depend on values) for limited finite cases where it ends up getting implemented as dictionary passing. an example of reification is: class (NotNegative m,NotNegative n) => ReifyNotNegative m t i n w where reifyNotNegative :: Integral i => m -> t -> i -> n -> w instance NotNegative n => ReifyNotNegative Zero t i n w where reifyNotNegative _ _ _ _ = error "Number to be reified exceeds maximum range." instance (NotNegative n,ReifyNotNegative m t i (Suc n) w,Ctrl.Apply t n w) => ReifyNotNegative (Suc m) t i n w where reifyNotNegative (Suc m) t i n | i>0 = reifyNotNegative m t (i-1) (Suc n) | otherwise = Ctrl.apply t n (The apply in the above is a 'prolog' like apply, where 't' is a unique type used to identify the 'function' to apply) Anyway in this way the whole types depending on values issue is sidestepped. Keean.

1 0

Re: [Haskell] Dependent Types in Haskell [was: Eliminating Array Bound Checking through Non-dependent] types
by MR K P SCHUPKE 11 Aug '04

11 Aug '04

Just a couple of quick points... Why store the length along with the list, the length is stored using type level naturals (Succ | Zero) but these are identical to the recursion pattern in a List (Cons | Nil) - therefore it is no less work than having a length function which converts from one to the other (Cons x -> Succ, Nil -> Zero), so it is really redundant having both. Second you can express append in a much simpler and readable way in Haskell using type classes: ------------------------------------------------------------- data Nil deriving Show data List a = Cons a (List a) deriving Show class Append l l' l'' | l l' -> l'' where append :: l -> l' -> l'' instance List l' => Append Nil l' l' where append _ l' = l' instance Append l l' l'' => Append (Cons a l) l' (Cons a l'') where append (Cons a l) l' = Cons a (append l l') ------------------------------------------------------------- Thats the complete definition, no need for extra stuff or complex exqualities or casts... Doesn't look too bad to me. Keean.

2 1

Re: [Haskell] Dependent Types in Haskell [was: Eliminating Array Bound Checking through Non-dependent] types
by MR K P SCHUPKE 11 Aug '04

11 Aug '04

Actually the data statement wasnt quite right: data Cons a b = Cons a b Would work, but now there is nothing keeping each element in the list as the same type, I guess we could add a class to constrain to a normal list,,, class List l x instance List Nil x instance List l x => List (Cons x l) x Erm, which is of course what I meant in the first place Keean.

1 0

constraint track @ SAC2005 CFP
by stefano Bistarelli 10 Aug '04

10 Aug '04

********************************************************************* proposed title: --------------- Constraint Solving and Programming Aims and topics: ---------------- Constraints have emerged as the basis of a representational and computational paradigm that draws from many disciplines and can be brought to bear on many problem domains. The track is concerned with all aspects of computing with constraints including algorithms, applications, environments, languages, models, and systems. Contributions are welcome from any discipline concerned with constraints, including artificial intelligence, combinatorial algorithms, computational logic, concurrent computation, databases, discrete mathematics, operations research, programming languages, and symbolic computation. We also solicit papers from any domain employing constraints, including computational linguistics, configuration, decision support, design, diagnosis, graphics, hardware verification, molecular biology, planning, qualitative reasoning, real-time systems, resource allocation, robotics, scheduling, software engineering, temporal reasoning, vision, visualization, and user interfaces. Papers that bridge disciplines or combine theory and practice or discuss novel reasoning methods are especially welcome. A special attention is focused around the use of constraint technologies in the networking, wireless and internet fields. Rationale for having such a track in SAC: ----------------------------------------- The constraint solving and programming area deal with a specific way to model and solve a large number of problems in many fields. This peculiarity made constraint solving and programming techniques neither too general nor overly specialized, but also enough wide to be able to attract a wide audience of people sharing constraint interests. Moreover, many emerging areas (mobility, networking, protocols, security, web) are starting to use constraint techniques and formalism to express problems and solve them. In addition to this motivation, the main conference dealing with such techniques (CP) is helt each year around the month of october, and a track in SAC in march will be welcomed by the CP researchers. In this sense the track on CP will complement the CP conference. The community of constraints usually participates also to IJCAI and to PACT, but these two conferences are too general and the second one focuses too much on industrail application. Organizers -------------------- - Stefano Bistarelli Dipartimento di Scienze, Universita' degli Studi "G. D'Annunzio" di Chieti-Pescara, Italy bista(a)sci.unich.it http://www.sci.unich.it/~bista/ and Istituto per l'Informatica e la Telematica, C.N.R. Pisa, Italy stefano.Bistarelli(a)iit.cnr.it - Eric Monfroy LINA University of Nantes Eric.Monfroy(a)lina.univ-nantes.fr http://www.sciences.univ-nantes.fr/info/perso/permanents/monfroy/ - Barry O'Sullivan Barry O'Sullivan Cork Constraint Computation Centre Department of Computer Science University College Cork, Ireland Email: b.osullivan(a)cs.ucc.ie Tel: +353 21 4903085 Fax: +353 21 4903113 Web: http://www.cs.ucc.ie/~osullb/ Activities: ----------- To disseminate the call-for-papers we will use a set of mailing lists we already used for many CP related conferences and workshops. A web page describing the track will be publicized by such a list and inserted in the search engines and in the conferences' specialized web sites. Moreover, in October we will give call for participation to all the people attending the CP conference. To manage the review process we will sent papers to the most influential and knowledgeable peoples of the Constraint technologies area we are already in contact with. The possibility for the publication of a selected number of papers in a special issue of some Journal will be considered. Experience of the organizers ------------------------------ - Stefano Bistarelli CP98: Publicity Chair SAC2002--2004: AI and computational logic Track co-chair AGP2002: PC member CP2002: RCORP workshop PC member CP2002--2003: Soft workshop co-chair FLAIR2003--2004 - constraint solving and programming track co-chair FLAIR2004 - Secure Multiparty Computations and Distributed Constraint Reasoning track PC member - Eric Monfroy Conference PC member: AISC'02, AISC'04, ADVIS'02, ADVIS'04, PPAM'01, PPAM'03, JFPLC'01, JFPLC'03, JFPLC'04 Workshops: (co-)organization, (co-)chair, or pc member CoSolv at CP'2001, CP'2002, CP'2003 RCorrp at CP'2000, CP'2001, CP'2002 and 2003 PU'03 TRICS at CP'2000, CP'2002 ERCIM workshop on COnstraint: 1997, 1998, 1999, 2000, 2001 ATAI'03 - Barry O'Sullivan Conference PC/OC member (Recent): AI-2004 - The Twenty-fourth SGAI International Conference on Innovative Techniques and Applications of AI CP-2004 - Principles and Practice of Constraint Programming AAAI-2004 - National Conference on Artificial Intelligence DCC-2004 - International Conference on Design Computing and Cognition FLAIRS 2004 - Special Track on Constraint Solving and Programming FLAIRS 2004 - Special Track on Secure Multiparty Computations and Distributed Constraint Reasoning Workshops PC/OC member (Recent): Workshop on Configuration at ECAI-04, IJCAI-03, ECAI-02 User-Interaction in Constraint Satisfaction at CP-01, CP-02, CP-03 ERCIM/CologNet Workshop on Constraints 2002 Stefano Bistarelli's CV: ------------------------ check http://www.sci.unich.it/~bista/ Barry O'Sullivan's CV: ------------------------ check http://www.cs.ucc.ie/~osullb/ Eric Monfroy's CV: ------------------------ check http://www.sciences.univ-nantes.fr/info/perso/permanents/monfroy/

1 0

image writing library
by Ketil Malde 06 Aug '04

06 Aug '04

Hi, I would like to write an (Array (Int,Int) Int) to a file in some kind of image format. I implemented (quick and very dirty) XBM output, but it would be nice to have some colors, and anyway, I can't seem to show the XBMs as grayscale. I've searched around a bit, but the only stuff I could find was defunct references to GIF writer, Jeroen Fokker's JPEG stuff (which may still work, but I don't want JPEG compression), and the PPM support in Andrew Cooke's Pancito. Ripping out the latter currently seems to be the best bet, not sure how closely tied it is to the rest of the code. So, before I start, does anybody know any other libraries or programs that could be used? -kzm -- If I haven't seen further, it is by standing in the footprints of giants

7 8

ANNOUNCE: The Succ Zero International Obfuscated Haskell Code Contest!
by Shae Matijs Erisson 05 Aug '04

05 Aug '04

In the spirit of http://ioccc.org/ .... bring us your poor, weary, downtrodden, and unreadable source code. Come to the Succ Zeroth INTERNATIONAL OBFUSCATED HASKELL CODE CONTEST! This contest is meant to be fun, short, and not terribly serious. * submission deadline: August 31st, 2004 * judging deadline: September 15th, 2004 (expect results at that point) * send your code (complaints/comments) to: iohcc(a)lists.ScannedInAvian.org submission must have source and some sort of description file so that the jurors won't be totally mystified. rules: * LICENSE: your code must be an original work, all submitted programs are thereby put in the public domain. All explicitly copyrighted programs will be rejected. (see the IOCCC rules) * max source size: 5k * entry must include shell script or makefile to perform the build * build must not require human intervention * doing something interesting and/or useful is a plus * we particularly like games * limited abuse of the rules is acceptible if the specific abuses are documented, and the judges think it's cool * judges aren't allowed to enter (not this time) portability: * latest public release versions of hugs, ghc, nhc, hbc, helium acceptable (any we missed?) * may use common Haskell tools such as hmake, happy etc. * program need not be portable across Haskell implementations * must be relatively portable across platforms (i.e. no Linux-specificisms) * use of ANSI/VTxxx codes which are not limited to a specific brand of terminal and work in a standard xterm are portable * FFI is discouraged, we want real Haskell source. five person jury: * BjornBringert (bringert) * AndrewBromage (Pseudonym) * ShaeErisson (shapr) * JeremyShaw (stepcut) * MartinSjögren (Marvin--) Awards will depend on the specific entries, but may include: * best one-liner - less than 80 chars not counting imports? * best .signature sized - 4x80 or 4x76 or whatever * best game * best H98-only program * best exploit of a compiler bug * most useful program * most creative layout * best abuse of implementation-specific extensions * best abuse of the type system * best abuse of category theory * worst abuse of the rules spirit, point, reason: * to seek out new lifeforms and new civilizations * to boldly go where no Haskell programmer has ever wanted to be! Semi-seriously, though, obfuscated code shows neat and unusual ways of structuring a program, cool tricks, dark nooks and crannies you've never thought of, and is generally a good way to shake off all that software discipline and stomp around in the muddy world of spaghetti code for a quick vacation. -- Shae Matijs Erisson - Programmer - http://www.ScannedInAvian.org/ "I will, as we say in rock 'n' roll, run until the wheels come off, because I love what I do." -- David Crosby

3 2

Ternary operators in Haskell, an observation (was: [Haskell] Do the libraries define S' ?)
by hjgtuyl＠chello.nl 03 Aug '04

03 Aug '04

On Wed, Jul 07, 2004 at 01:18:54PM +0100, Graham Klyne wrote: > There's a pattern of higher-order function usage I find myself repeatedly > wanting to use, exemplified by the following: > [[ > -- combineTest :: (Bool->Bool->Bool) -> (a->Bool) -> (a->Bool) -> > (a->Bool) > combineTest :: (b->c->d) -> (a->b) -> (a->c) -> a -> d > combineTest c t1 t2 = \a -> c (t1 a) (t2 a) > (.&.) :: (a->Bool) -> (a->Bool) -> (a->Bool) > (.&.) = combineTest (&&) > > (.|.) :: (a->Bool) -> (a->Bool) -> (a->Bool) > (.|.) = combineTest (||) The operators can be also defined as follows: (.&.) f g x = (f x) && (g x) (.|.) f g x = (f x) || (g x) It is clear from these definitions, that the operators are ternary operators. As operators are essentially the same as functions, in Haskell, any number of parameters can be given in an operator definition. Henk-Jan van Tuyl -------------------------------------------------------------------- Festina Lente Hasten Slowly Haast U langzaam Eile langsam Skynd dig langsomt Affrettati lentamente Spěchej pomalu Skynda långsamt Desiderius Erasmus -------------------------------------------------------------------- -- Met vriendelijke groet, Herzliche Grüße, Best regards, Henk-Jan van Tuyl -------------------------------------------------------------------- Festina Lente Hasten Slowly Haast U langzaam Eile langsam Skynd dig langsomt Affrettati lentamente Spěchej pomalu Skynda långsamt Desiderius Erasmus --------------------------------------------------------------------

3 2

RE: [Haskell] confusing language in report and a bug in (ghc|hugs)
by Simon Peyton-Jones 02 Aug '04

02 Aug '04

I'm inclined to think John is right, thought the Report could be clearer. I'll open a GHC sourceforge bug for this. Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of John Peterson | Sent: 29 July 2004 03:36 | To: haskell(a)haskell.org | Subject: Re: [Haskell] confusing language in report and a bug in (ghc|hugs) | | The intention in the report was to match in the order listed in the | pattern - you need not consult the data declaration to understand the | ordering. I think the report is clear enough - it's just a bug in | ghc. | | John | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

5 4

hmake question
by Tom Hofte 02 Aug '04

02 Aug '04

Hi, I want to use hmake to debug my haskell-program. I have installed hmake succesfully, but whem I want to compile my program, I'm getting the following error message: Fail: Can't find module IOExts in user directories . Or in installed libraries/packages at /home/hofte/local/lib/ghc-6.2.1/imports /home/hofte/local//lib/ghc-6.2.1/uust /home/hofte/local//lib/ghc-6.2.1/imports/HaXml Asked for by: KoalaMain.hs Fix using the -I, -P, or -package flags. It seems that hmake can't find the IOExts module. I have tried to fix this by using the -I, -P or -package options with the absolute path of IOExts module. All of the options don't fix the problem. Does any one know how I can hmake tell where it can find the IOExts module.?? Thanks in advance, Tom Hofte

2 1