April 2001 - Haskell - Haskell.org

tuple component functions
by trb＠eastpac.com.au 03 Jan '03

03 Jan '03

S.D.Mechveliani writes: > As Haskell has the standard functions fst, snd to decompose (a,b), > maybe, it worths to provide also > tuple31, tuple31, tuple31, > ... > tuple51, tuple52, tuple53, tuple54, tuple55 > > for the tuples of n = 3,4,5 ? I've found some of these useful, except I named them differently: > fst3 :: (a,b,c) -> a > fst3 (x,_,_) = x > snd3 :: (a,b,c) -> b > snd3 (_,x,_) = x > thd3 :: (a,b,c) -> c > thd3 (_,_,x) = x .... never got around to quadruples etc. I also defined (some of these may be untested): > tripl :: a -> (a,a,a) > tripl x = (x,x,x) > curry3 :: ((a, b, c) -> d) -> a -> b -> c -> d > curry3 f x y z = f (x, y, z) > uncurry3 :: (a -> b -> c -> d) -> ((a, b, c) -> d) > uncurry3 f t = f (fst3 t) (snd3 t) (thd3 t) > applyTriple :: (a -> b, a -> c, a -> d) -> a -> (b,c,d) > applyTriple (f,g,h) x = (f x, g x, h x) > cross3 :: (a -> b, c -> d, e -> f) -> (a,c,e) -> (b,d,f) > cross3 (f,g,h) (x,y,z) = (f x, g y, h z) > mapTriple :: (a -> b) -> (a, a, a) -> (b, b, b) > mapTriple = cross3 . tripl > applyFst3 :: (a -> b) -> (a, c, d) -> (b, c, d) > applyFst3 f = applyTriple (f . fst3, snd3, thd3) > applySnd3 :: (a -> b) -> (c, a, d) -> (c, b, d) > applySnd3 f = applyTriple (fst3, f . snd3, thd3) > applyThd3 :: (a -> b) -> (c, d, a) -> (c, d, b) > applyThd3 f = applyTriple (fst3, snd3, f . thd3) > applyArgs3 :: (a -> b) -> (c -> d) -> (e -> f) -> (b -> d -> f -> g) -> (a -> c -> e -> g) > applyArgs3 af1 af2 af3 f = \x y z -> f (af1 x) (af2 y) (af3 z) > rotl :: (a -> b -> c -> d) -> (b -> c -> a -> d) > rotl f y z x = f x y z > rotr :: (a -> b -> c -> d) -> (c -> a -> b -> d) > rotr f z x y = f x y z > rotl4 :: (a -> b -> c -> d -> e) -> (b -> c -> d -> a -> e) > rotl4 f y z t x = f x y z t > rotr4 :: (a -> b -> c -> d -> e) -> (d -> a -> b -> c -> e) > rotr4 f t x y z = f x y z t Some more combinators (only for pairs so far): > twin :: a -> (a,a) > twin x = (x,x) > swap :: (a,b) -> (b,a) > swap (x,y) = (y,x) -- apply a pair of functions to one argument > applyPair :: (a -> b, a -> c) -> a -> (b, c) > applyPair (f, g) x = (f x, g x) -- apply a pair of functions to a pair > cross :: (a -> b, c -> d) -> (a, c) -> (b, d) > cross (f, g) = applyPair (f . fst, g . snd) -- compose a pair of functions onto one function > dotPair :: (a -> b, a -> c) -> (d -> a) -> (d -> b, d -> c) > dotPair (f, g) h = (f . h, g . h) -- compose a pair of functions onto a pair of functions > dotCross :: (a -> b, c -> d) -> (e -> a, f -> c) -> (e -> b, f -> d) > dotCross (f, g) (h, i) = (f . h, g . i) > mapPair :: (a -> b) -> (a, a) -> (b, b) > mapPair = cross . twin > applyFst :: (a -> b) -> (a, c) -> (b, c) > applyFst f = applyPair (f . fst, snd) > applySnd :: (a -> b) -> (c, a) -> (c, b) > applySnd f = applyPair (fst, f . snd) > applyArgs :: (a -> b) -> (c -> d) -> (b -> d -> e) -> (a -> c -> e) > applyArgs af1 af2 f = \x y -> f (af1 x) (af2 y) > betweenFst :: (a -> b -> c) -> (a, d) -> (b, e) -> c > betweenFst = applyArgs fst fst > betweenSnd :: (a -> b -> c) -> (d, a) -> (e, b) -> c > betweenSnd = applyArgs snd snd I find these combinators useful, and probably other people have their own versions - it would be nice to get them standardised, so we all speak the same language. By standardised, I mean a prominent version that will be adopted by users, not necessarily a committee process. Tim

3 2

ICFP programming contest
by trb＠eastpac.com.au 03 Jan '03

03 Jan '03

Michael Hobbs writes: > Just took a look at the results for the ICFP contest. Am I correct in > assuming that "LA" stands for Lennart Augustsson and that "Si^3" stands > for Simon Marlow, Simon Peyton-Jones, Sigbjorn Finne? Is there a URL for the results ? Tim

2 1

CFP: JFP on SAIG
by Walid Taha 08 Jul '01

08 Jul '01

CALL FOR PAPERS A Special Issue of JFP on Semantics, Applications, and Implementation of Program Generation http://cs-www.cs.yale.edu/~taha/saig/jfp.html Program generation has the prospect of being an integral part of a wide range of software development processes. Recent studies investigate different aspects of program generation systems, including their semantics, their applications, and their implementation. Existing theories and systems address both high-level (source) language and low-level (machine) language generation. A number of programming languages now support program generation and manipulation. These languages can have different goals, use different different implementation techniques, and target different applications. In this context, a PLI workshop dedicated to this theme (SAIG'00) was held this year. Following on from this workshop, a special issue of the Journal of Functional Programming will be devoted to the same theme. Full-length, archival-quality submissions are solicited on topics including both theoretical and practical models and tools for building program generation systems, Examples include: * Semantics, type systems, and implementations for multi-stage languages. * Run-time specialization systems: e.g. compilers, operating systems. * High-level program generation (applications, foundations, environments). * Symbolic computation, linking and explicit substitution, in-lining and macros. Reports on applications of these techniques to real-world problems are especially encouraged, as are submissions that relate ideas and concepts from several of these topics, or bridge the gap between theory and practice. Contributors to SAIG'00 are encouraged to submit, but submission is open to everyone. Papers will be reviewed as regular JFP submissions, and acceptance in the special issue will be based on relevance to the theme. The special issue also welcomes high-quality survey and position papers that would benefit a wide audience. Accepted papers exceeding the space restrictions will be published as regular JFP papers. Submissions should be sent to the guest editor (address below), with a copy to Nasreen Ahmad (nasreen(a)dcs.gla.ac.uk) Submitted articles should be sent in postscript format, preferably gzipped and uuencoded. In addition, please send, as plain text, title, abstract, and contact information. The submission deadline is February 1st, 2001. For other submission details, please consult an issue of the Journal of Functional Programming or see the Journal's web page at http://www.dcs.gla.ac.uk/jfp/. Guest Editor Editor in Chief Walid Taha Department of Computer Science Philip Wadler Yale University Avaya Labs P.O. Box 208285 700 Mountain Ave, Room 2T-402, New Haven, CT 06520-8285, Murray Hill, NJ 07974-0636, USA. USA. Email: taha(a)cs.yale.edu Email: wadler(a)avaya.com Phone: +1 203 432 6496 Phone: +1 908 582 4004 Fax : +1 203 432 0593 Fax: +1 908 582 5857

1 5

ANNOUNCE: Happy 1.10 released
by Simon Marlow 13 May '01

13 May '01

ANNOUNCING Happy 1.10 - The LALR(1) Parser Generator for Haskell ----------------------------------------------------------------- I'm pleased to announce version 1.10 of Happy, the parser generator system for Haskell. Changes in this version, relative to version 1.10 (the previous full release): * bugfixes, and minor performance improvements, * most of the examples work again. Happy is available in source form, which can be compiled with GHC version 4.xx (4.08 or 5.00 recommended), and we also provide binaries for some architectures. The Happy homepage with links to the various distributions lives at: http://www.haskell.org/happy/ Please send any bug reports and comments to simonmar(a)microsoft.com.

4 4

proposal of true fuctional module loading
by S.D.Mechveliani 30 Apr '01

30 Apr '01

This may sound strange, but could Haskell think of supporting a true functional module loading? As the interactive systems exist, with interactive loading, and so on, maybe, it can be provided a library of Haskell functions: compile :: Env -> SrcModule -> (Interface, CodeModule) parse :: Env -> CodeModule -> String -> Expression load :: Env -> CodeModule -> Env evaluate :: Env -> CodeModule -> Expression -> Expression - something like this. Let all the code be interpreted (so far), env :: Env keep all the interface modules and the code modules, (parse env md str) returns the value of the type which the compiler would assign to the data read from str, under the given program scope (env,md). The idea is to enable a regular user's Haskell program to create a source program md :: SrcModule (not a file), compile it (lightly, as, for example, in Hugs-98) to interpreted code and load - under (and to) the accumulated total program env :: Env. env, md are the explicit variables in the user program, and no side effects happen. `parse', `evaluate' may use the built-in compiler and interpreter. This is something like Hugs interactive system given to the user in the form of the library functions, with the explicit variables and arguments to hold the values of environment and program code. This is not extending the language, only the library. The aim is to enable the user program to create at the run-time new algebraic domains in the form of types and instances contained in new source and code modules. The type resolution remains static, but becomes (I am sorry) dynamic at the new level. This is another alternative to the sample argument approach - disliked by many, dependent types language extension - concerning a language and to have problems of it own. Example: the user program can `load' the domains (modules with types and instances) P_1 .. P_n of integer polynomials in variables [x1], [x1,x2], [x1,x2,x3], ..., [x1..xn] respectively and compute the needed things, say, 5 minutes in each domain, while the compilation and loading of P_i will need a couple of seconds. Also the new loaded and interpreted code may refer to the compiled library, like it is done in ghc-5.00. Here n is a variable; it is not known statically how many P_i will suffice to solve a task. Also the domains P_i have different properties and even should have different instances, and it is not good to pile them in one type. This concerns the same old discussion thread about possibility to create dynamically, say, the domains of Integer modulo different m = 2,3,... Can the Haskell library take a step in this direction? In some term rewriting logical systems, like Maude, the `programs' have rich type system (types are called `sorts'), but still are the first class data (in meta-coding), can be created with the usual data constructors and then, meta-applied. But there, I suppose, there is no `loading'. Because Maude has a particular `import' notion, which is not likely to be supported by Haskellers. ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

RE: Implict parameters and monomorphism
by Simon Peyton-Jones 30 Apr '01

30 Apr '01

Jeff Thanks for your detailed reply. | In other words, the monomorphism restriction converts certain | let bindings to lambda bindings. But this approach pre-supposes that the monomorphism restriction takes priority over the "must generalise implicit parameters" rule. Once you make that supposition, then choice (B) follows. Note that choice (B) implies a loss of source-level beta reduction, which I regard as rather serious. But I rather think that the "must generalise implicit parameters" should take priority, and the monomorphism restriction should not. Then choice (C) follows. Indeed, many people think that the monomorphism restriction should go altogether, so (C) is a move in the right direction. So my take is still: let's adopt (C). Simon

1 0

Happy 1.10 Windows InstallShield available
by Reuben Thomas 30 Apr '01

30 Apr '01

An InstallShield distribution of Happy 1.10 for Windows is now available from the Happy page (www.haskell.org/happy/)

1 0

reminder -- early registration deadline for ICC, PADO, and MFPS
by Symposium on Program as Data Objects 30 Apr '01

30 Apr '01

Hello, This is just a reminder that the early registration deadline for ICC'01, PADO-II, and MFPS XVII is today. http://www.brics.dk/pado2/ Best, -- Olivier Danvy

1 0

factorizing a tree
by Jan Skibinski 29 Apr '01

29 Apr '01

I need some help with some optimization of certain trees: data Tree = Leaf Item | Product Tree Tree | Sum (Double, Tree) (Double, Tree) with this additional "collating" property: Sum (Double, Leaf Item) (Double, Leaf Item) ==> Leaf Item I have certain control over the shape of such trees. I love products, but sums are expensive and hence my goal is to avoid them at all cost. If this is unavoidable then I try to push the sums down the tree as deeply as possible. By doing that I am sometimes able to collate a sum of two leafs into one leaf, and that's great. But even without the collation effect a deeply set sum is still better than the top sum. One of the functions, f say, is given two indices i, j from the range (1, depth of the tree). It should modify the layer "j" based on the information contained in the layer "i" - producing new tree of the same depth. A naive solution looks like this: f :: Int -> Int -> Tree -> Tree f i j tree = Sum (1, g i j tree) (1, h i j tree) where g = ... h = ... but this is the most costly solution. One way of pushing the sums down the tree is to do something of this sort: f i j (Product t1 t2) | (i <= d) && (j <= d) = Product (f i j t1) t2 | (i > d) && (j > d) = Product t1 (f (i-d) (j-d) t2) | .... where d = depth t1 depth t = ... I wonder if there are some known practises for handling such problems. Or am I overlooking some very simple solution? If I did not clearly specify the problem it is probably because I did not want to post here too much of irrelevant information. I can clarify it if required. Jan

1 0

RE: help!!!!
by vortex 27 Apr '01

27 Apr '01

Gepost in fa.haskell in reactie op een mail met subject: help!!! --------------- Cadena Silva Andres wrote: > I need examples of trees please. No problem! Lemme see now... There's oak, scarlet oak, bur oak, pin oak, northern red oak, shingle oak, swamp white oak, pine, Scotch pine, Austrian pine, willow, white willow, birch, redwood, mulberry, apple, cherry, black cherry, Oriental cherry, yew, hazel, juniper, alder, ash, elm, holly, poplar, aspen, maple, hedge maple, trident maple, Arnur maple, shagbark maple, sugar maple, paperbark maple, Japanese maple, black maple, Norway maple, Crimson King Norway maple, Tatarian maple, red maple, autumn flame red maple, october glory red maple, silver maple, Beebee silver maple, Freeman maple, White Tigress maple, rowan, hemlock, larch, cedar, spruce, white fir, Nikko fir, Douglas fir, Nordmann fir, sequoia, yellow buckeye, Ohio buckeye, hickory, bitternut hickory, shagbark hickory, northern catalpa, filbert, dogwood, hawthorn, hornbeam, American hophornbeam, persimmon, silverbell, magnolia, Franklin, lacebark, pear, sassafras, lilac, corktree, Ohio buckeye, red buckeye, chestnut, horsechestnut, European horsechestnut, Brioti red horsechestnut, serviceberry, walnut, black walnut, sweetgum, crabapple, Japanese Zelkova, Japanese pagodatree, elder, boxelder, Mimosa, orange, Cockspur hawthorn, Washington hawthorn, tulip, sourwood, palm, forest pansy redbud, maidenhair, ginkgo, photinia, black locust, sunburst thornless honeylocust, cypress, weeping nootka false cypress, and, last but not least, the charmingly named American bladdernut. You need any more, just holler, y'hear? --- Frank Atanassow, Information & Computing Sciences, Utrecht University Padualaan 14, PO Box 80.089, 3508TB Utrecht, The Netherlands Tel +31 (0)30 253-3261 Fax +31 (0)30 251-3791 _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

1 0