- Haskell - Haskell.org

List of words
by lynn yeong 02 May '01

02 May '01

Hi, I'm fairly new to Haskell, and recently I came upon a question which asks to capitalise all words in a given list. I haveno idea how to do it, can you help? Thanks! --------------------------------- Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices

2 1

Interesting: "Lisp as a competitive advantage"
by Sengan 02 May '01

02 May '01

http://www.paulgraham.com/paulgraham/avg.html I wonder how Haskell compares in this regard. Any comment from Haskell startups? (eg Galois Connections) Sengan

2 1

2001 Haskell Workshop: final call for papers
by Ralf Hinze 01 May '01

01 May '01

============================================================================ FINAL CALL FOR PAPERS [Deadline for submission: 1st June 2001] 2001 Haskell Workshop Firenze, Italy, 2nd September 2001 The Haskell Workshop forms part of the PLI 2001 colloquium on Principles, Logics, and Implementations of high-level programming languages, which comprises the ICFP/PPDP conferences and associated workshops. Previous Haskell Workshops have been held in La Jolla (1995), Amsterdam (1997), Paris (1999), and Montreal (2000). http://www.cs.uu.nl/people/ralf/hw2001.{html,pdf,ps,txt} ============================================================================ Scope ----- The purpose of the Haskell Workshop is to discuss experience with Haskell, and possible future developments for the language. The scope of the workshop includes all aspects of the design, semantics, theory, application, implementation, and teaching of Haskell. Submissions that discuss limitations of Haskell at present and/or propose new ideas for future versions of Haskell are particularly encouraged. Adopting an idea from ICFP 2000, the workshop also solicits two special classes of submissions, application letters and functional pearls, described below. Application Letters ------------------- An application letter describes experience using Haskell to solve real-world problems. Such a paper might typically be about six pages, and may be judged by interest of the application and novel use of Haskell. Functional Pearls ----------------- A functional pearl presents - using Haskell as a vehicle - an idea that is small, rounded, and glows with its own light. Such a paper might typically be about six pages, and may be judged by elegance of development and clarity of expression. Submission details ------------------ Deadline for submission: 1st June 2001 Notification of acceptance: 12th July 2001 Final submission due: 1st August 2001 Haskell Workshop: 2nd September 2001 Authors should submit papers in postscript format, formatted for A4 paper, to Ralf Hinze (ralf(a)cs.uu.nl) by 1st June 2001. Use of the ENTCS style files is strongly recommended. The length should be restricted to the equivalent of 5000 words (which is approximately 24 pages in ENTCS format, or 12 pages in ACM format). Note that this word limit represents a change from the first call for papers. Application letters and functional pearls should be labeled as such on the first page; they may be any length up to the above limit, though shorter submissions are welcome. The accepted papers will initially appear as a University of Utrecht technical report, and subsequently be published as an issue of Electronic Notes in Theoretical Computer Science. Programme committee ------------------- Manuel Chakravarty University of New South Wales Jeremy Gibbons University of Oxford Ralf Hinze (chair) University of Utrecht Patrik Jansson Chalmers University Mark Jones Oregon Graduate Institute Ross Paterson City University, London Simon Peyton Jones Microsoft Research Stephanie Weirich Cornell University ============================================================================

1 0

RE: The Haskell kernel
by Simon Peyton-Jones 01 May '01

01 May '01

I'm afraid the "Haskell kernel" isn't formally defined. The Report describes how to translate complex constructs into simpler ones, but neither specifies *exactly* what these simpler ones are, nor gives their meaning in a formal way. Simon | -----Original Message----- | From: ml_dk(a)sol.dk [mailto:ml_dk@sol.dk] | Sent: 01 May 2001 13:31 | To: Haskell mailinglist | Subject: The Haskell kernel | | | | In the report on the Haskell programming language | (http://www.haskell.org/onlinereport/) | the Haskell kernel is mentionen in several places. It says in | section 1.2 that the Haskell kernel is a slightly sugared | form of lambda calculus. Futhermore most expression should be | possible to translate to the Haskell kernel. | | But where is this kernel defined (I cannot find it in the report) ? | | Actually the case-expression(section 3.13) seems more | fundamental than the lambda-expression in Haskell. Several | construct translate to the case-expression instead of | lambda-expression as the if-expression(section 3.6). It is | also shown howto translate the lambda-expression into the | case-expression in section 3.3. Am I missing something here ? | | Grateful for any hint. | | Mads | | | | ________________________________________ | Få din egen webmail på http://mail.sol.dk - gratis og med dig overalt! | | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

1 0

The Haskell kernel
by ml_dk＠sol.dk 01 May '01

01 May '01

In the report on the Haskell programming language (http://www.haskell.org/onlinereport/) the Haskell kernel is mentionen in several places. It says in section 1.2 that the Haskell kernel is a slightly sugared form of lambda calculus. Futhermore most expression should be possible to translate to the Haskell kernel. But where is this kernel defined (I cannot find it in the report) ? Actually the case-expression(section 3.13) seems more fundamental than the lambda-expression in Haskell. Several construct translate to the case-expression instead of lambda-expression as the if-expression(section 3.6). It is also shown howto translate the lambda-expression into the case-expression in section 3.3. Am I missing something here ? Grateful for any hint. Mads ________________________________________ Få din egen webmail på http://mail.sol.dk - gratis og med dig overalt!

1 0

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