- Haskell - Haskell.org

CFP
by 24th FSTTCS Conference 2004 20 Oct '04

20 Oct '04

Dear List coordinator, Please post the following Call for Participation. Any queries may be sent to fsttcs(a)imsc.res.in. Thanks and best regards, R. Ramanujam for FST&TCS 2004 ---------------------------------------------------------------- CALL FOR PARTICIPATION The 24th Conference on Foundations of Software Technology and Theoretical Computer Science - FST&TCS 2004 December 16--18, 2004, Institute of Mathematical Sciences, Chennai, INDIA * Invited Speakers: Javier Esparza, Piotr Indyk, Pavel Pevzner, John C. Reynolds and Denis The'rien. * Satellite Workshops: December 13--15, 2004. Algorithms for dynamic data, coordinated by S. Muthukrishnan and Pankaj Agarwal. Logic for dynamic data, coordinated by Uday Reddy. * Deadline for Early Registration: 13th November 2004 * For details see: http://www.fsttcs.org/ http://www.imsc.res.in/~fsttcs/ ----------------------------------------------------------------

1 0

remove from your mailing list
by Alvaro Sebastian Miranda Forero 19 Oct '04

19 Oct '04

1 0

RTA'05: 3rd and last Call for Papers
by Ralf Treinen 18 Oct '04

18 Oct '04

****************************** * * * RTA'05 CALL FOR PAPERS * * * ****************************** http://www-i2.informatik.rwth-aachen.de/RTA05/ April 19--21, 2005 Nara, Japan The 16th Int. Conf. on Rewriting Techniques and Applications (RTA'05) will collocate with the 7th International Conference on Typed Lambda Calculi and Applications (TLCA'05) as part of the Federated Conference on Rewriting, Deduction and Programming (RDP'05). IMPORTANT DATES: Nov 12, 2004: Deadline for electronic submission of title and abstract Nov 19, 2004: Deadline for electronic submission of papers Jan 14, 2005: Notification of acceptance of papers Feb 4, 2005: Deadline for final versions of accepted papers Apr 19-21, 2005: Conference The deadlines are strict. RTA is the major forum for the presentation of research on all aspects of rewriting. Typical areas of interest include (but are not limited to): * APPLICATIONS: case studies; rule-based (functional and logic) programming; symbolic and algebraic computation; theorem proving; system synthesis and verification; proof checking. * FOUNDATIONS: matching and unification; narrowing; completion techniques; strategies; constraint solving; explicit substitutions; tree automata. * FRAMEWORKS: string, term, and graph rewriting; lambda-calculus and higher-order rewriting; proof nets; constrained rewriting/deduction; categorical and infinitary rewriting. * IMPLEMENTATION: compilation techniques; parallel execution; rewriting tools. * SEMANTICS: equational logic; rewriting logic. INVITED TALKS will be given at RTA'05 by: * Amy Felty (Ottawa) * Yoshihito Toyama (Sendai) * Philip Wadler (Edinburgh) BEST PAPER AWARDS AND TRAVEL GRANTS: An award of 100,000 Yen will be given to the best paper or papers as decided by the PC. A limited number of student travel grants is available. Preference will be given to students whose papers are accepted at RTA and who do not have alternative funding. Students applying for travel support should indicate this by sending an e-mail to the PC chair (giesl(a)informatik.rwth-aachen.de) together with their submission. RTA'04 PROGRAM COMMITTEE: * Franz Baader (Dresden) * Mariangiola Dezani (Torino) * Juergen Giesl (Aachen, Chair) * Bernhard Gramlich (Vienna) * Florent Jacquemard (Cachan) * Claude Kirchner (Nancy) * Pierre Lescanne (Lyon) * Aart Middeldorp (Innsbruck) * Hitoshi Ohsaki (Amagasaki) * Vincent van Oostrom (Utrecht) * Christine Paulin-Mohring (Orsay) * Frank Pfenning (Pittsburgh) * Femke van Raamsdonk (Amsterdam) * Mark-Oliver Stehr (Urbana) * Rakesh Verma (Houston) * Andrei Voronkov (Manchester) RTA'05 SUBMISSIONS: Submissions must be original and not submitted for publication elsewhere. Submission categories include regular research papers and system descriptions. Also problem sets and submissions describing interesting applications of rewriting techniques will be very welcome. The page limit is 15 pages (10 pages for system descriptions). As usual, accepted papers will appear in the Springer-Verlag Lecture Notes in Computer Science series. More information about paper submission is available at the RTA'05 web page. http://www-i2.informatik.rwth-aachen.de/RTA05/ LOCATION, TRAVEL, ACCOMMODATION, AND REGISTRATION The conference takes place in Nara park, which is one of the most important cultural sights of Japan with some of the oldest and most impressive temples and shrines. Airfares from Europe or the US to Japan are not expensive in mid-April and the conference will offer reasonably priced accommodation and low registration fees. RTA'05 PROGRAM CHAIR: Juergen Giesl LuFG Informatik II RWTH Aachen Ahornstr. 55 52074 Aachen Germany giesl(a)informatik.rwth-aachen.de RTA'05 CONFERENCE CHAIR: Hitoshi Ohsaki AIST Japan ohsaki(a)ni.aist.go.jp

1 0

Question about Infix/Postfix Operators in Haskell
by Peter Theissen 18 Oct '04

18 Oct '04

Hi, is there any possibility of defining Infix-/Postfixoperators in Haskell? Example: Plus :: Int, Int -> Int Plus x y = x + y an now I´m want to use Plus in another function as an infix: Times2:: x = x Plus x Is this possible anyway? If this feature doesnt exist, could you please give some reasons for this? with kind regards, Peter Theissen

5 4

Re: [Haskell] Question about Infix/Postfix Operators in Haskell
by Janis Voigtlaender 18 Oct '04

18 Oct '04

One easy way: > plus :: Int -> Int -> Int > plus x y = x + y > times2 x = x `plus` x -- Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de

1 0

Re: Module Initialisation? (was Re: [Haskell] (no subject))
by Wolfgang Thaller 17 Oct '04

17 Oct '04

Adrian Hey wrote: > I'm puzzled about this idea of "module init action" in a declarative > language. Perhaps, if it's desirable to have some module initialisation > applied to a module if anything from it is used, the way to do this > would > be to have a reserved identifier specially for the purpose, like > "main", but at the module level. (Though this idea still seems a > bit strange to me). I don't see what's so strange about that. At least, it's not any stranger than on-demand execution of IO actions in a pure functional language. And the toplevel "<-" is definitely a natural syntax for that. > I've interpreted this correctly this means that someAction will always > get executed, whether or not foo (or anything dependent on foo) is used > elsewhere? This seems like a bad thing to me. It's a feature. I'd actually _want_ to use that one independently. > It may be harmless enough > if all it does is create a few IORefs which are then promptly garbage > collected, but in some situations it could involve quite complex > and expensive initialisation operations on foreign libraries > (for example). Well if you want those IO operations to be lazily interleaved with the rest of the program (or not executed at all), you can use valueToBeInitedLazily <- unsafeInterleaveIO $ do blah ... which explicitly says what you are doing that might be slightly unsafe. > Since a lot of the concerns expressed about this seem to centre > around possible abuse of arbitrary IO operations in these top > level constructions, maybe the problem could be addressed by > insisting that a restricted monad was used, call it SafeIO say. You're taking away a feature I want to use. 1) Initialising global IORefs is a good thing, no matter when it's actually done. 2) Being able to initialize things at program startup is a good thing, even if they're not explicitly referred to. 3) Lazy, on-demand initialization of things is a good thing, if you know what you're doing. 4) Lazy, on-demand initialization of things (with potential side effects) is a bad thing, if you don't know what you're doing. If we define toplevel IO bindings to be just like the unsafePerformIO hack, we get 1,3 and 4 (and 4 is actually a bad thing). If we define toplevel IO bindings as mdo-style module initialisation, we get 1 and 2 directly, and 3 with an obvious use of unsafeInterleaveIO. We don't get 4, because obviously, when you use unsafeInterleaveIO, you're already claiming to know what you're doing. Also note that if useless initialization of IORefs ever becomes a problem, we can still use lots of nasty hacks inside the compiler to optimize for those common functions. But I don't think we'll ever have to do this. Cheers, Wolfgang

4 7

RE: [Haskell] Global Variables and IO initializers: A proposal andsemantics
by Erkok, Levent 16 Oct '04

16 Oct '04

>> I wondered if something like that could work, but I wasn't sure that >> mdo allowed recursion in its let-bindings... > >The mdo implementation in ghc does not actually... I think there's a misunderstanding there. let expressions inside an mdo can of course be recursive; both Hugs and ghc support this: ----------------------------- import Control.Monad.Fix main = mdo x <- return y let y = 1:y z <- return y print (take 1 x, take 2 y, take 3 z) ------------------------------ will happily print ([1],[1,1],[1,1,1]); no problems there. Note that the let defined variable 'y' is used both before and after its definition; and it's also defined recursively. May be you are thinking of polymorphism problem. The restriction is this: let bound variables in an mdo cannot be use polymorphically if they are referred to before their definition. (It's also OK to use them polymorphically after their definition.) This is merely there to ensure that the translation will be a well-typed Haskell-98 expression; nothing more than that. If we choose, we can make it polymorphic everywhere, by typing mdo-expressions separately. As John pointed out, there're no technical difficulties there. The only thing we lose is that the translation may fail to type-check. This was a compromise we had to do, and we chose the light-weight view that mdo is only syntactic-sugar. -Levent.

2 1

[bctcs05-info] BCTCS 2005 Announcement
by Graham Hutton 15 Oct '04

15 Oct '04

+--------------------------------------------------------------------+ ANNOUNCEMENT (REGISTRATION NOW OPEN) 21st British Colloquium for Theoretical Computer Science BCTCS 2005 22-24 March 2005 University of Nottingham, UK The purpose of BCTCS is to provide a forum for researchers in theoretical computer science to meet, present research findings, and discuss developments in the field. It also aims to provide an environment for PhD students to gain experience in presenting their work, and benefit from contact with established researchers. SCOPE The scope includes all aspects of theoretical computer science, such as algorithms, complexity, semantics, formal methods, concurrency, types, languages and logics. Computer scientists, mathematicians and researchers from outside of the UK are all welcome to attend. PROGRAMME The programme will consist of 2.5 days of invited talks, tutorials, and contributed talks. The invited speakers are as follows: Games for Algorithmic Problem Solving Prof Roland Backhouse, University of Nottingham The Soft Machines: Computing with the Code of Life Prof Alan Gibbons, King's College London Dr Martyn Amos, University of Exeter Samoa: Formal Tools for Securing Web Services Dr Andrew Gordon, Microsoft Research, Cambridge Number Systems and Data Structures Dr Ralf Hinze, University of Bonn Dependently Typed Programming: An Epigram Induction Dr Conor McBride, Royal Holloway, University of London Succinctness Prof Rajeev Raman, University of Leicester LOCATION The colloquium will be held on the Jubilee Campus of the University of Nottingham, which has won many awards for its design and environmental features. Nottingham is centrally located in the UK, and is easily reachable by road, rail and air (Nottingham East Midlands Airport.) REGISTRATION The deadline for registration and submission of proposed talks is 7 February 2005. The registration fee is 275 UK pounds, including accomodation and all meals. Two dozen funded places for UK-based PhD students have been applied for. Registration is now open. SPONSOR The colloquium is sponsored by the London Mathematical Society. FURTHER DETAILS Google search - BCTCS 2005 Web page - http://www.cs.nott.ac.uk/~gmh/bctcs05.html +--------------------------------------------------------------------+ _______________________________________________ bctcs05-info mailing list bctcs05-info(a)cs.nott.ac.uk http://www.cs.nott.ac.uk/mailman/listinfo/bctcs05-info This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

1 0

(no subject)
by Wolfgang Thaller 15 Oct '04

15 Oct '04

> b) Some predetermined order, with semantics like mdo: Hmm, I just realized that this also means we can execute moduke intialisation code that returns no result using: _ <- do ... I like that, I desperately need that for my Objective-C binding... So the extension with the specified order actually allows one to do more things than the unsafePerformIO hack. I wouldn't care about specifying the order otherwise. If the default order is wrong, people can still use unsafeInterleaveIO. > GHC already has an initialisation procedure for each module in the > program which could be adapted to run the initialisation-time IO > actions, with a little effort. Hmm, doesn't the initialisation procedure run before the Stg machine is properly set up? I guess all the GHC init code could do is to register IO actions to be executed later (but before main is run). We probably want all the GHC module init procedures to be run before we execute any IO actions. > I'm more worried about what other changes we have to make to the > compiler: if we can avoid having to flag top-level bindings as > monadic/non-monadic all the way through the compiler, then we could > avoid a pervasive change to the compiler. At the moment I can't see an > obvious way to do that. We could get away with "desugaring" them to some very "unsafe" non-IO- bindings and having the "module init action" do something evil to make the IO happen in the right order... should be possible to make that look exactly like mdo from the outside. We'll end up using the unsafePerformIO hack inside the implementation again, so that people end up with two IORefs instead of one, but that should be cheap enough: foo <- someAction ... could be transformed into ... foo_var = unsafePerformIO $ newIORef (throw NonTermination) foo_action = someAction >>= writeIORef foo_var foo = unsafePerformIO $ readIORef foo ... with the appropriate NOINLINEs. The module init action would then make sure that foo_action gets invoked. So we'd only need to annotate modules with a list of init actions and extend the RTS appropriately for that... Cheers, Wolfgang -- GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail +++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++

3 2

Announce: Flippi v0.02
by Philippa Cowderoy 14 Oct '04

14 Oct '04

I'm writing to announce the release of Flippi, a simple and lightweight Wiki clone written in plain Haskell 98 using the hierarchical libraries. Flippi can be found at http://www.flippac.org/projects/flippi/ , with a running copy at http://www.scannedinavian.org/cgi-bin/flippi/flippi where I hope things such as user modifications will be linked to once they're available. The code's all available under the BSD license, and is known to compile under GHC6 (but not GHC 5). -- flippa(a)flippac.org

2 1