March 2005 - Haskell - Haskell.org

CFP: Developments on Computational Models (satellite of ICALP 05)
by Maribel Fernandez 22 Mar '05

22 Mar '05

====================================================================== Call for Papers Developments in Computational Models http://www.dcs.kcl.ac.uk/events/DCM/index.html Lisbon, Portugal Sunday, 10 July 2005 A satellite event of ICALP 2005 ======================================================================= Several new models of computation have emerged in the last few years, and many developments of traditional computational models have been proposed with the aim of taking into account the new demands of computer systems users and the new capabilities of computation engines. A new computational model, or a new feature in a traditional one, usually is reflected in a new family of programming languages, and new paradigms of software development. The aim of this workshop is to bring together researchers who are currently developing new computational models or new features for traditional computational models, in order to foster their interaction, to provide a forum for presenting new ideas and work in progress, and to enable newcomers to learn about current activities in this area. DCM 2005 will be a one-day satellite event of ICALP 2005. Topics of interest include all abstract models of computation and their applications to the development of programming languages and systems. For instance: Functional calculi: lambda-calculus, rho-calculus, term and graph rewriting; Object calculi; Interaction-based systems: interaction nets, games; Concurrent models: process calculi, action graphs; Calculi expressing locality, mobility, and active data; Quantum computational models; Biological or chemical models of computation. Submissions and Publication: Please submit an abstract (max. 5 pages) in PDF/PostScript format by e-mail to dcm(a)dcs.kcl.ac.uk by 9 May, 2005. After the workshop authors will be invited to submit a full paper of their presentation. Accepted contributions will appear in a special issue of the international journal Mathematical Structures in Computer Science. Important Dates: Submission Deadline for Abstracts: 9 May 2005 Notification: 30 May 2005 Pre-proceedings version due: 27 June 2005 Submission Deadline for Special Issue of MSCS: 15 October 2005 Notification: 15 January 2006 Programme Committee: Vincent Danos, CNRS and University of Paris 7 (France) Mariangiola Dezani, University of Torino (Italy) Maribel Fernandez, King's College London (UK), co-chair Claude Kirchner, LORIA and INRIA (France) Cosimo Laneve, University of Bologna (Italy) Ian Mackie, King's College London (UK), co-chair Nobuko Yoshida, Imperial College London (UK) Local Organizer: Jorge Sousa Pinto, University of Minho (Portugal)

1 0

New Version of my Arrows GUI Library Based on GTK+
by Kevin Atkinson 22 Mar '05

22 Mar '05

I just posted a new version of FG, my Arrows GUI Library Based on GTK+. You can find it at http://kevin.atkinson.dhs.org/fg/. I reworked how Events are handled which decreases the number of times a loop is traversed form "2^d" to "d + 1" where d is the depth of the inner most loop. Furthermore only the loop which the event was fired in will need to be traversed multiple times. You can find it at http://kevin.atkinson.dhs.org/fg/. Feedback appreciated. Here are some interesting parts from the documentation: Description: This module is a first attempt of using Arrows to create a GUI Library based on GTK+. A good understanding of how Arrows work is required in order to understand the interface. For more information on Arrows see http://www.haskell.org/arrows/. It uses many ideas from Fruit (http://haskell.org/fruit/) However it is based on discrete events rather than a continuous signal. The interface is only updated during an Event. It also ideas from Fudgets (http://www.md.chalmers.se/Cs/Research/Functional/Fudgets/) some of which were also used by Fruit. ... Implementation Notes: Arrows essentially build up a huge tree like data structure representing the control flow between arrows. In the current implementation most of top-level structure has to be traversed when ever an event is fired -- even if absolutely no actions need to be taken. When a loop is used parts of this structure may be traversed multiple times. In particular the inner most loop where an event was fired from will be traversed "d + 1" times where d is the depth of the loop. If an event was not fired inside a loop (or any of the sub loops) than the loop will only be traversed once. Avoiding this problem of having to traverse most of tree for every event requires information that I'm not sure the compiler can give me. For example I need to know the difference between arr (x -> x) and arr (_ -> 10). The first passes the input to the output the second throws the value away. All I am able to know is that arr was used. What exactly the function does is a black box. -- http://kevin.atkinson.dhs.org

1 0

Type inference and principal typings for record concatenation and mixin modules
by unknown＠example.com 22 Mar '05

22 Mar '05

We would like to announce a technical report and a web-accessible software demonstration. The technical report is: Type Inference and Principal Typings for Symmetric Record Concatenation and Mixin Modules by Henning Makholm and J. B. Wells http://www.macs.hw.ac.uk/~makholm/papers/bowtini-long.pdf In this report we present a new type system, Bowtie, for a lambda calculus with records and a symmetric record concatenation operation. The system has been designed to allow feasible _type inference_ with a complexity of O(nm*alpha(n)) where n is the input size and m the number of different field labels in the program, as well as _compositional type inference_ and a notion of _principal typings_. (Because alpha(n) <= 4 for n < 10^(10^100) (a googolplex), one can think of this factor as a constant for practical purposes.) Most previous type systems for record concatenation have relied on subtyping polymorphism. Bowtie does not, and because subtyping is absent, we have been able to straightforwardly extend Bowtie to a type system, Martini, for _mixin modules_. Bowtie and Martini are both non-polymorphic type systems, but because both have principal typings it is straightforward to extend either with Milner's let-polymorphism, and we do so. Apart from the definition of Bowtie and Martini we also present some negative results ("things that don't work"). Most notable among these is a series of proofs that the straightforward typing rule for a record concatenation operator in an SML-like type system leads to an NP-hard typability problem --- *even for the let-free (non-polymorphic) fragment*, and *no matter whether the concatenation operator is symmetric or asymmetric/overwriting*. We have also made available a web-accessible type inference demo for Bowtie/Martini; it can be found at http://www.macs.hw.ac.uk/DART/software/Bowtini/ We hope you enjoy our paper and web demo and we welcome any feedback. -- Henning Makholm Joe Wells

1 0

RE: [Haskell] URLs in haskell module namespace
by Simon Marlow 22 Mar '05

22 Mar '05

On 22 March 2005 13:03, Lemmih wrote: > On Tue, 22 Mar 2005 06:40:02 -0500 (Eastern Standard Time), S. > Alexander Jacobson <alex(a)alexjacobson.com> wrote: >> I don't understand. Are you saying that there will be only one >> Hackage server ever and it will have all information about all >> packages everywhere and that the location of this hackage server will >> be hard coded into every cabal implementation? > > Hackage and (the soon to come) cabal-get are tools layered on the > Cabal but they are not a part of it. > Hard coded URLs are evil in almost every context, IMHO. But defaulting > to some server when the user hasn't specified otherwise would greatly > increase the ease of use. > >> If so, I find that vision incredibly unappealing. I believe there >> should/will be multiple hackage servers with carrying different >> hackages under control of different parties (e.g. a corporation might >> have one for its own private code). > > The idea with Hackage was to create a central place for people to put > software or links to software, so keeping only one server for free (as > in beer) packages would be desirable. However, this does in no way > limit how Hackage can be used for private code repositories. It might make sense in the future to be able to express package names as URLs, with the default being relative to http://www.haskell.org/packages (or wherever). eg. in your .cabal file you could say BuildDepends: http://example.org/haskell-packages/foo >= 1.0 Cheers, Simon

1 0

RE: [Haskell] Happy Error Token
by Simon Marlow 22 Mar '05

22 Mar '05

On 18 March 2005 20:20, Clemens Ley wrote: > I've had some trouble with the happy error token: What is it actually > there for (apart form implementing the Haskell layout rule). I've not > been able to find an example where it matters weather I include the > error token or not. Can someone help me? Happy's error token is a restricted version of the error token found in Yacc. It is sufficient to implement the Haskell layout rule, but not to do general error recovery. The reason I restricted it in this way is because I couldn't find a sensible semantics for Yacc's error token. Different Yacc implementations seem to do different things (I found differences between byacc and bison, for example), and using Yacc's error token to implement the Haskell layout rule was unreliable. It would be nice to have some kind of error recovery in Happy too, though. Cheers, Simon

1 0

Monadification as a refactoring
by S.J.Thompson 21 Mar '05

21 Mar '05

Dear Haskellers, We are interested in finding out from the Haskell community what sort of monadic programs people write, and in particular how they arrive at those programs. We have (Deling and Martin) developed a particular algorithm and tool for automatic monadification of Haskell programs, and (Claus, Huiqing and Simon) have built the HaRe tool for Haskell refactoring. We want to offer a monadification option within HaRe. There are various different, and apparently incompatible, styles of monadification, and we are therefore keen to find out what would be most effective for Haskell practitioners. As we have said, there are many different styles of monadification. On the web page http://www.cs.kent.ac.uk/projects/refactor-fp/Monadification.html you can find a small program together with five example monadifications. We have included these as examples, but we make no claim to have covered the whole space of possibilities. We are interested in finding out - which of the examples represent the monadification styles that are the most useful for your purposes, - which other styles of monadification you are using, and - which monadification(s) you would like to see implemented in a refactoring tool. We are happy to receive simple choices as well as more detailed responses. Could you please send your comments, thoughts, code examples and so on to refactor-fp(a)kent.ac.uk We'll post a summary of this to the Haskell mailing list. We'd also be happy to discuss these issues on Haskell Cafe, too, Claus Reinke, Deling Ren, Huiqing Li, Martin Erwig and Simon Thompson

1 0

Unicode Source / Keyboard Layout
by Sven Moritz Hallberg 21 Mar '05

21 Mar '05

Greetings GHC and Haskell folk, please excuse the cross-post. This is a coordinational message. :) I've been longing for Unicode (UTF-8) input support in GHC for a long time. I am currently customizing a keyboard layout to include many mathematical operators and special characters which would be very useful in writing even prettier (!) Haskell code. I'd be interested to complete the keyboard layout and make it public, to raise the value of Unicode input support. When will it happen? To make the fun complete, I think a few adjustments to the Haskell grammar would be in order, so, guessing the relevant people read these lists, may I suggest the following? 1. In addition to the backslash, accept "mathematical * small lamda" (U+1D6CC, U+1D706, U+1D740, U+1D77A, and U+1D7B4) for lambda abstractions. Leave "greek small letter lamda" as a regular letter, so the Greeks can write their native language. 2. In addition to "->", accept "rightwards arrow" U+2192 as the function arrow. 3. Accept "leftwards arrow" U+2190 in do and notation. 4. Accept "leftwards arrow-tail" U+2919 in arrow notation. 5. Accept "rightwards double arrow" U+21D2 in addition to "=>" for type contexts. 6. Accept "for all" U+2200 in addition to the forall keyword. 7. Remove the symbols for clearly prefix operators (n-ary summation and product, logical not, etc.) from the set of characters used to build binary operators. Leave them as identifier letters, so they can be bound to regular functions. Did I forget anything? Being a Macintosh user, I've assembled a Mac OS keylayout file. For anyone interested, the current version can be downloaded: http://www.scannedinavian.org/~pesco/distfiles/hallberg-dvorak.zip The base layout is Dvorak. Caps Lock switches to Greek mode, where 'a' changes to alpha, 'b' to beta, etc. Alt (Option) accesses the symbol map. Shift-Alt gives a second level of symbols. Currently, the symbol map contains german Umlaute for me. I'll most probably move them behind dead-keys soon, though. (A-e giving Ä etc.) I can produce an XKB map for X11 once I'm happy with the layout. It would be cool if someone could also port the thing to Windows around that time. Please get in touch if you're interested. Let me know what you think, Sven Moritz Hallberg

3 2

Coordination 2005: Grants
by Jean-Marie JACQUET 21 Mar '05

21 Mar '05

[ Our apologies for multiple copies. ] ====================================================================== Grant support for the participation to COORDINATION 2005 7th International Conference on Coordination Models and Languages Namur, Belgium, 20-23 April 2005 http://www.coordination2005.org ====================================================================== SCOPE OF THE CONFERENCE Modern information systems rely increasingly on combining concurrent, distributed, mobile, reconfigurable and heterogenous components. New models, architectures, languages, verification techniques are necessary to cope with the complexity induced by the demands of today's software development. Coordination languages have emerged as a successful approach, in that they provide abstractions that cleanly separate behavior from communication, therefore increasing modularity, simplifying reasoning, and ultimately enhancing software development. Building on the success of the previous editions, this conference provides a well-established forum for the growing community of researchers interested in models, languages, architectures, and implementation techniques for coordination. GRANTS Thanks to the sponsoring of MicroSoft Research Europe, several grants are offered in order to allow promising PhD students working on topics related to coordination models and languages to attend the conference. The grant will cover, on the basis of receipts, the registration to the conference, hotel accommodation in Namur, and travel to/from Namur. To apply for a grant, please 1) send an email to the conference chairs at chair(a)pc.coordination2005.org no later than April 6th 2005 with following information - a 2-page position paper on your research stressing its relation to the conference - a CV including your affiliation, age, studies, diplomas, and publications - a budget for your travel to/from Namur. 2) fax a letter of recommendation of your supervisor to Prof. J.-M. Jacquet Institute of Informatics University of Namur rue Grandgagnage 21 5000 Namur Belgium Fax +32 81 72 49 67

1 0

RTA'05: 2nd Call for Participation
by Ralf Treinen 21 Mar '05

21 Mar '05

****************************************** * * * RTA'05 SECOND CALL FOR PARTICIPATION * * * ****************************************** The 16th International Conference on REWRITING TECHNIQUES AND APPLICATIONS http://www-i2.informatik.rwth-aachen.de/RTA05/ co-located with * TLCA 7th International Conference on Typed Lambda Calculi and Applications and the workshops * RULE 6th International Workshop on Rule-Based Programming * UNIF 19th International Workshop on Unification * WRS 5th International Workshop on Reduction Strategies in Rewriting and Programming * WG 1.6 IFIP Working Group 1.6 on Term Rewriting together form the Federated Conference on Rewriting, Deduction and Programming (RDP'05). RDP'05 takes place in Nara (Japan) http://www.pref.nara.jp/nara_e/index.html in the period April 18 - April 23, 2005. Registration for RTA, TLCA and the workshops is now open ! The deadline for early registration is MARCH 31, 2005. Please visit the RTA'05 or RDP'05 website below for further information: RDP'05 http://www.kurims.kyoto-u.ac.jp/rdp05/ RTA'05 http://www-i2.informatik.rwth-aachen.de/RTA05/ INVITED TALKS of RTA 2005: * Amy Felty (Ottawa) joint with TLCA'05 * Yoshihito Toyama (Sendai) * Philip Wadler (Edinburgh) INVITED TALKS of the Anniversary Session to celebrate 20 years of RTA: * Nachum Dershowitz (Tel Aviv) * Gerard Huet (Rocquencourt) * Jean-Pierre Jouannaud (Palaiseau) For further questions please contact the conference chair: RTA'05 CONFERENCE CHAIR: Hitoshi Ohsaki AIST, Japan rta05(a)m.aist.go.jp http://staff.aist.go.jp/hitoshi.ohsaki/

1 0

Dynamic Loading?
by Ashley Yakeley 21 Mar '05

21 Mar '05

Is it possible to do dynamic loading in Haskell? Let us say you want to have plug-in loadable widgets. You create a widget API, which is in fact a data-type W (which you make an instance of Typeable). You then write an application that loads widgets, using something like this: loadDynamic :: FilePath -> IO Dynamic Someone else could then use your widget API to write code that provides a value of type W (or a Dynamic), and compile and link it as a widget that can then be loaded. Is this possible? -- Ashley Yakeley, Seattle WA

4 4