- Haskell - Haskell.org

post-doc job in functional programming
by Colin Runciman 13 Aug '05

13 Aug '05

Research Associate Position Available -- Post-Doc, Functional Programming (Second Posting -- application deadline 31 August) Applications are invited for a fixed-term research position at the Department of Computer Science, University of York, UK. This position is for a post-doctoral researcher to investigate the use of functional programming systems in grid computing. Specifically, the post is available in connection with a recently awarded EPSRC grant: "A Lazy Polytypic Grid: Generic Data Visualization Methods That Adapt to Resources Available". The project is a collaboration between the University of Leeds (grant holder: David Duke) and the University of York (grant holder: Colin Runciman). A post-doctoral researcher is being appointed at each site. The researcher at Leeds is expected to specialise in data visualisation and the researcher at York in functional programming systems, but the intention is that work will be genuinely collaborative. Both departments are active centres of research; for further information about them see http://www.cs.york.ac.uk/ and http://www.comp.leeds.ac.uk/. The essential qualifications for the post are these: * a PhD in functional programming systems or equivalent research experience; * well-developed skills in both the implementation and application of functional languages; * an aptitude for working collaboratively in a small team with researchers from different domains of expertise; * strong communication skills for written and oral presentation of ideas and results within and beyond the team. Other desirable qualifications include: * fluency in the Haskell programming language; * knowledge of data visualisation methods; * experience with grid computing. Starting salary will be up to 27,116 pounds per annum and the position is available for up to 3 years. For details of how to apply please email jobs(a)york.ac.uk quoting reference number CR05305 or see http://www.york.ac.uk/admin/persnl/jobs/. The closing date is 31 August 2005. For informal enquiries, or more details of the technical aims of the project, you are welcome to contact me directly: e-mail Colin.Runciman at cs.york.ac.uk or telephone +44 1904 432740. Please note, however, that I am due to be away for the last 10 days of August.

1 0

CFP WRLA06
by WRLA Acct (Denker) 13 Aug '05

13 Aug '05

+ + + + + WRLA'06 + + + + + CALL FOR PAPERS + + + + + WRLA'06 + + + + + +----------------------------------------------------------+ | | | 6th International Workshop on | | Rewriting Logic and its Applications | | | | W R L A 2006 | | | | Vienna, Austria, April 1-2, 2006 | | | | http://www-formal.stanford.edu/clt/WRLA06/ | +----------------------------------------------------------+ The workshop will be held in conjunction with ETAPS 2006 9th European Joint Conferences on Theory and Practice of Software March 26 - April 2, 2006 http://www.complang.tuwien.ac.at/etaps06/ IMPORTANT DATES November 21, 2005 Deadline for submissions January 16, 2006 Notification of acceptance February 16, 2006 Final version in electronic form April 1-2, 2006 Workshop in Vienna AIMS AND SCOPE Rewriting logic (RL) is a natural model of computation and an expressive semantic framework for concurrency, parallelism, communication and interaction. It can be used for specifying a wide range of systems and languages in various application fields. It also has good properties as a metalogical framework for representing logics. In recent years, several languages based on RL (ASF+SDF, CafeOBJ, ELAN, Maude) have been designed and implemented. The aim of the workshop is to bring together researchers with a common interest in RL and its applications, and to give them the opportunity to present their recent works, discuss future research directions, and exchange ideas. The topics of the workshop comprise, but are not limited to, * foundations and models of RL; * languages based on RL, including implementation issues; * RL as a logical framework; * RL as a semantic framework, including applications of RL to - object-oriented systems, - concurrent and/or parallel systems, - interactive, distributed, open ended and mobile systems, - specification of languages and systems; * formalisms related to RL, including - real-time and probabilistic extensions of RL, - tile logic, - rewriting approaches to behavioral specifications; * verification techniques for RL specifications, including - equational and coherence methods, and - verification of properties expressed in first-order, higher-order, modal and temporal logics; * comparisons of RL with existing formalisms having analogous aims; * application of RL to specification and analysis of - distributed systems, - physical systems. PAST EVENTS Previous WRLA workshops have been organized in - Asilomar, California, September 3-6, 1996 - Pont-a-Mousson, France, September 1-4, 1998 - Kanazawa, Japan, September 18-20, 2000 - Pisa, Italy, September 19-21, 2002 - Barcelona, Spain, March 27-28, 2004 The proceedings of the WRLA workshops have been published as volumes 4, 15, 36, 71, and 117 in the Elsevier ENTCS series, available at http://www.sciencedirect.com/science/journal/15710661 Selected papers from WRLA'96 have been published in a special issue of Theoretical Computer Science, Volume 285(2), 2002, and selected papers from WRLA 2004 will appear in a special issue of Higher-Order and Symbolic Computation. LOCATION WRLA 2006 will be held in Vienna, Austria in March 25-26, 2006. It is a satellite workshop of ETAPS 2006, the European Joint Conferences on Theory and Practice of Software. For venue, registration and suggested accommodation see the ETAPS 2006 web page http://www.complang.tuwien.ac.at/etaps06 SUBMISSIONS Submissions will be evaluated by the Program Committee for inclusion in the proceedings, which will be available at the time of the workshop and are expected to be published in the Elsevier ENTCS series. Papers must contain original contributions, be clearly written, and include appropriate reference to and comparison with related work. They must be unpublished and not submitted simultaneously for publication elsewhere. Papers (of at most 15 pages, at least 10 point font) should be submitted electronically, preferably as PDF files, to the workshop email address wrla06(a)csl.sri.com providing also a text-only abstract, and detailed contact information of the corresponding author. The final program of the workshop will also include system demonstrations and invited presentations to be determined. Based on the quality and interest of the accepted papers, the program committee will consider the possibility of preparing a special issue of a scientific journal in the field. ORGANIZING COMMITTEE Carolyn Talcott and Grit Denker SRI International Menlo Park, CA 94025 PROGRAM COMMITTEE Roberto Bruni Universita` di Pisa Manuel Clavel Universidad Complutense de Madrid Grit Denker SRI International, Menlo Park (co-Chair) Francisco Duran Universidad de Malaga Steven Eker SRI International, Menlo Park Kokichi Futatsugi JAIST, Nomi Claude Kirchner INRIA & LORIA, Nancy Salvador Lucas Universidad Politecnica de Valencia Narciso Marti-Oliet Universidad Complutense de Madrid Jose Meseguer University of Illinois at Urbana-Champaign Ugo Montanari Universita` di Pisa Pierre-Etienne Moreau INRIA & LORIA, Nancy Peter Olveczky University of Oslo Grigore Rosu University of Illinois at Urbana-Champaign Mark-Oliver Stehr University of Illinois at Urbana-Champaign Carolyn Talcott SRI International, Menlo Park (Chair) Martin Wirsing Ludwig-Maximillian University, Munich CONTACT INFORMATION For more information, please contact the organizers wrla06(a)csl.sri.com or visit the workshop web page http://www-formal.stanford.edu/WRLA06/ + + + + + WRLA'06 + + + + + CALL FOR PAPERS + + + + + WRLA'06 + + + + +

1 0

RE: [Haskell] concurrency analysis
by Simon Peyton-Jones 12 Aug '05

12 Aug '05

I don’t know of any. Quite a bit has been done for the single threaded case, trying to identify cases where thunk updates can be omitted (e.g. http://research.microsoft.com/%7Esimonpj/Papers/usage-types/usage.htm) For the parallel case you may be interested in our Haskell workshop paper (on my home page). Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of John Meacham | Sent: 12 August 2005 04:05 | To: haskell(a)haskell.org | Subject: [Haskell] concurrency analysis | | I was curious if there has been any research on "concurrency analysis" | which would determine which thunks might be accessed concurrently by | different threads. I imagine that the vast majority are only accessed in | a single threaded manner so can use a more efficient representation when | doing SMP parallelism with haskell. It seems that some sort of abstract | interpretation could provide a conservative answer to this similar to | the way update analysis is done. | John | | | -- | John Meacham - ⑆repetae.net⑆john⑈ | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

FP in the (German) CS curriculum
by Johannes Waldmann 12 Aug '05

12 Aug '05

Hello. My institution is currently revising the curriculum for Bachelors and Masters in Computer Science. One point of interest is the role of programming, and especially that of the functional paradigm. I'd like to compare our plans to other existing curricula. The main critique raised implicitely or explicitely by some of my colleagues here is nicely summarized in http://www.galois.com/cufp/ : "industry folks complain that there aren't enough FP folks being produced by schools, and educators complain that students don't see any point in studying FP if there are no jobs to be had." So if you are teaching (or studying) at a German Fachhochschule (technical university, sort of), I'd like to know your opinion (and your institution's opinion). (Please reply to me, not to this list. Is there a better place for this discussion?) Vielen Dank (thanks)! -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

2 1

RE: [Haskell] pros and cons of static typing and side effects ?
by Simon Peyton-Jones 12 Aug '05

12 Aug '05

Perhaps this discussion could move to Haskell-café? We try to keep the bandwidth on Haskell(a)haskell.org fairly low. Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of John Meacham | Sent: 12 August 2005 00:47 | To: haskell(a)haskell.org | Subject: Re: [Haskell] pros and cons of static typing and side effects ? | | On Thu, Aug 11, 2005 at 03:40:25PM -0400, Hamilton Richards wrote: | > At 10:40 PM +0200 2005/8/10, mt wrote: | > >... Languages with | > >static typing would be more suitable if programs were something you thought | > >of in advance, and then merely translated into code. But that's not how | > >programs get written. | > | > Well, that is actually how lots of programs do get written. | > | > For software that is experimental and exploratory, whose code | > undergoes continual change and whose only users are the code's | > authors, static typing is arguably a dispensable nuisance. A type | > error that pops up during execution is probably no more inconvenient | > than one that's caught by static type checking. That's why Lisp is | > popular for AI work. | | I find pretty much completly the opposite is true. for random hacking | and evolving code, static typing is essential. There is only so much | room in one's brain to keep track of how everything works. if you were | meerly translating from a previous design, this isn't so much an issue. | but when writing code that is evolving and changing and perhaps you | don't quite know how it will turn out, your ability to recall and | understand how everything works together is a major limiting factor on | the scope of what you can acomplish. Static typing offloads a _ton_ of | responsibility away from the programmer. you no longer need to worry or | even think about what types are held in variables because you know any | mistakes will be caught by the compiler. and with haskell's advanced | type system, you can encode much more advanced constraints and | invarients in the type system offloading even more work from your brain. | Haskell's strong type system made me writing jhc alone possible, not | because of the better reliability (that is great though!), but because | it let me 'forget' about so many inconsequential details that they type | system enforced so I only needed to use brain-space for high level | constructs and my overall evolving, changing, plan. I tend to only use | perl or other dynamically typed languages when writing something that I | know exactly what it will do and how to do it beforehand, because I find | it to be quite an inflexible language when it comes to changing code | after the fact, not because of any syntatic difficulty, but because you | basically have to constantly redervive everything the program does and | all the unspoken invarients to understand it and how to change it. which | is something that gets super-linearly harder as code size grows. | | John | | -- | John Meacham - ⑆repetae.net⑆john⑈ | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

concurrency analysis
by John Meacham 12 Aug '05

12 Aug '05

I was curious if there has been any research on "concurrency analysis" which would determine which thunks might be accessed concurrently by different threads. I imagine that the vast majority are only accessed in a single threaded manner so can use a more efficient representation when doing SMP parallelism with haskell. It seems that some sort of abstract interpretation could provide a conservative answer to this similar to the way update analysis is done. John -- John Meacham - ⑆repetae.net⑆john⑈

1 0

pros and cons of static typing and side effects ?
by mt 12 Aug '05

12 Aug '05

[thnk 4 the previous answers !] Good [morning, afternoon, night], I try to better understand some things... maybe you can help me. Id' like to know what are the pros and cons of (not) having static typing. Same question for (direct support of) side effects. To help you to find answers, here I quote this page : http://paulgraham.com/lispfaq1.html [Most hackers I know have been disappointed by the ML family. Languages with static typing would be more suitable if programs were something you thought of in advance, and then merely translated into code. But that's not how programs get written. The inability to have lists of mixed types is a particularly crippling restriction. It gets in the way of exploratory programming (it's convenient early on to represent everything as lists), and it means you can't have real macros.] Thanks a lot, minh thu

7 9

RE: [Haskell] pros and cons of static typing and side effects ?
by Bayley, Alistair 11 Aug '05

11 Aug '05

> From: mt [mailto:mtvo@info.fundp.ac.be] > > yes, that's the kind of answer i expected... that's the kind > of thing you > always see when reading something about haskell. but i guess there's > arguments against... i'd like to make my opinion without just reading > a post saying "it catches many errors". maybe this mailing > list is not the > right place to ask this question ;-) maybe i should ask on a > lisp mailing > list :) For far more reading than anyone could possibly tolerate, see various dicussions at http://lambda-the-ultimate.org. Go to the home page, enter "static typing" in the search box, and then report back two days later :-) e.g. "Why type systems are interesting" http://lambda-the-ultimate.org/node/view/100 (continued (!) in part II http://lambda-the-ultimate.org/node/view/175 ) Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

1 0

HaXml ANYContent
by Georg Martius 11 Aug '05

11 Aug '05

Hi, I have some problems with the ANYContent type in HaXml. Currently (1.13) ANYContent is defined as data ANYContent = ANYContent which means I cannot store anything in there. I need two things: 1) Parse a file where some elements have ANY content, but be able to use the content. 2) Create a data structure and fill the ANYContent field and be able to write that to an XML file. I suggest the following sollution: > newtype Unparsed = Unparsed String > data ANYContent = forall a . XmlContent a => Either UnParsed (ANYContent a) If an XML file is parsed we don't know the type yet. Therefore we put everything in Unparsed field. Later on one can use a Parser on that explicitly. It would also make the roundtrip XML->Haskell ->XML more stable. Cheers, Georg -- ---- Georg Martius, Tel: (+49 34297) 89434 ---- ------- http://www.flexman.homeip.net ---------

1 0

RE: Re[2]: [Haskell] proposal about declaring language version andlanguage extensions used in specific module
by Simon Marlow 10 Aug '05

10 Aug '05

On 10 August 2005 08:03, Bulat Ziganshin wrote: > Hello Ross, > > Wednesday, August 10, 2005, 4:24:53 AM, you wrote: > >> On Tue, Aug 09, 2005 at 03:37:01PM -0700, John Meacham wrote: >>> I thought there was talk of a standardized {-# LANGUAGE ... #-} >>> pragma somewhere.. but I can't seem to find it. > >> http://www.haskell.org//pipermail/haskell/2003-September/012692.html >> http://www.haskell.org//pipermail/libraries/2004-October/002589.html > > of course, my proposed extension is very trivial. but compared to > above mentioned variants, it moves definition of language used in > module from pseudocomments to language itself. i also propose moving > of all pragmas from pseudocomments to special language statements The language declaration affects the grammar of the language, and even whether the source is preprocessed or not, so you can't put the declaration into the language itself. {-# LANGUAGE #-} is the right thing (and we should implement it in GHC, really). Cheers, Simon

2 1