January 2007 - Haskell

Call for participation and abstracts: BCTCS, Oxford, 2-5 Apr
by Jeremy.Gibbons＠comlab.ox.ac.uk 19 Jan '07

19 Jan '07

(apologies for any duplicate cross-postings you may receive) +--------------------------------------------------------------------+ 23rd British Colloquium for Theoretical Computer Science BCTCS 2007 2-5 April 2007 St Anne's College, Oxford http://cms.brookes.ac.uk/bctcs2007/ The purpose of BCTCS is to provide a forum in which researchers in theoretical computer science can meet, present research findings, and discuss developments in the field. It also aims to provide an environment in which PhD students can gain experience in presenting their work, and benefit from contact with established researchers. SCOPE All aspects of theoretical computer science, including automata theory, algorithms, complexity theory, semantics, formal methods, concurrency, types, languages and logics. Computer scientists and mathematicians are welcome to attend, as are participants from outside the UK. PROGRAMME The programme will consist of nearly 3 days worth of invited and contributed talks, beginning at 5.30pm on Monday 2nd April and concluding at 1pm on Thursday 5th April 2007. The abstracts of the talks will be published in the Bulletin of the European Association for Theoretical Computer Science (EATCS). The invited speakers are as follows: Dimitris Achlioptas, University of California, Santa Cruz, U.S.A. "Random Constraint Satisfaction Problems: from Physics to Algorithms" Steven Alpern, The London School of Economics and Political Science "Search Games and Utilitarian Postman Paths on Networks" Julian Bradfield, University of Edinburgh (BCS-FACS Lecturer in Formal Methods) Georg Gottlob, University of Oxford "Living with Computational Complexity" (This is Prof. Gottlob's inaugural lecture at Oxford University.) Bob Harper, Carnegie Mellon University, U.S.A. Richard Jozsa, University of Bristol Kristina Vuskovic, University of Leeds (LMS Lecturer in Discrete Mathematics) LOCATION The 2007 colloquium will be held at St Anne's College, Oxford, one of the colleges of the University of Oxford, and hosted by the computing departments of both Oxford Brookes and Oxford universities, Oxford itself is known as the "City of Dreaming Spires", and has been home to both royalty and scholars for over 800 years. REGISTRATION Registration for BCTCS2007 is open, via the web page. The deadline for registration and submission of abstracts for proposed talks is 16th February 2007. The registration fee is 340 UK pounds, including accommodation and meals, and the day rate is 145 UK pounds. A number of free registrations for UK-based PhD students are available. SPONSORS The colloquium is sponsored by EPSRC, BCS-FACS, and also the London Mathematical Society. FURTHER DETAILS Google search - BCTCS 2007 Web page - http://cms.brookes.ac.uk/bctcs2007/ +--------------------------------------------------------------------+

1 0

British Colloquium for Theoretical, Computer Science (BCTCS)
by Clare Martin 18 Jan '07

18 Jan '07

Dear all, The registration deadline for the British Colloquium for Theoretical Computer Science (BCTCS) is just a few weeks away (16th February) As well as this encouragement to register yourself, please could you pass this message on to your colleagues and students, and encourage them to register too! There are a number of free places available for UK-based PhD students. Best wishes, Clare Martin on behalf of: Sharon Curtis Jeremy Gibbons (organisers) (apologies for any duplicate cross-postings you may receive) +--------------------------------------------------------------------+ 23rd British Colloquium for Theoretical Computer Science BCTCS 2007 2-5 April 2007 St Anne's College, Oxford http://cms.brookes.ac.uk/bctcs2007/ The purpose of BCTCS is to provide a forum in which researchers in theoretical computer science can meet, present research findings, and discuss developments in the field. It also aims to provide an environment in which PhD students can gain experience in presenting their work, and benefit from contact with established researchers. SCOPE All aspects of theoretical computer science, including automata theory, algorithms, complexity theory, semantics, formal methods, concurrency, types, languages and logics. Computer scientists and mathematicians are welcome to attend, as are participants from outside the UK. PROGRAMME The programme will consist of nearly 3 days worth of invited and contributed talks, beginning at 5.30pm on Monday 2nd April and concluding at 1pm on Thursday 5th April 2007. The abstracts of the talks will be published in the Bulletin of the European Association for Theoretical Computer Science (EATCS). The invited speakers are as follows: Dimitris Achlioptas, University of California, Santa Cruz, U.S.A. "Random Constraint Satisfaction Problems: from Physics to Algorithms" Steven Alpern, The London School of Economics and Political Science "Search Games and Utilitarian Postman Paths on Networks" Julian Bradfield, University of Edinburgh (BCS-FACS Lecturer in Formal Methods) Georg Gottlob, University of Oxford "Living with Computational Complexity" (This is Prof. Gottlob's inaugural lecture at Oxford University.) Bob Harper, Carnegie Mellon University, U.S.A. Richard Jozsa, University of Bristol Kristina Vuskovic, University of Leeds (LMS Lecturer in Discrete Mathematics) LOCATION The 2007 colloquium will be held at St Anne's College, Oxford, one of the colleges of the University of Oxford, and hosted by the computing departments of both Oxford Brookes and Oxford universities, Oxford itself is known as the "City of Dreaming Spires", and has been home to both royalty and scholars for over 800 years. REGISTRATION Registration for BCTCS2007 is open, via the web page. The deadline for registration and submission of abstracts for proposed talks is 16th February 2007. The registration fee is 340 UK pounds, including accommodation and meals, and the day rate is 145 UK pounds. A number of free registrations for UK-based PhD students are available. SPONSORS The colloquium is sponsored by EPSRC, BCS-FACS, and also the London Mathematical Society. FURTHER DETAILS Google search - BCTCS 2007 Web page - http://cms.brookes.ac.uk/bctcs2007/

1 0

ICFP07 Call for Papers
by Matthew Fluet (ICFP Publicity Chair) 17 Jan '07

17 Jan '07

Call for Papers ICFP 2007: International Conference on Functional Programming Freiburg, Germany, 1-3 October 2007 ICFP 2007 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects and concurrency. Particular topics of interest include * Applications and domain-specific languages: systems programming; scientific and numerical computing; symbolic computing; artificial intelligence; databases; graphical user interfaces; multimedia programming; scripting; system administration; distributed-systems and web programming; XML processing; security * Foundations: formal semantics; lambda calculus; type theory; monads; continuations; control; state; effects * Design: algorithms and data structures; modules; type systems; concurrency and distribution; components and composition; relations to object-oriented or logic programming * Implementation: abstract machines; compile-time and run-time optimization; just-in-time compilers; memory management; parallel hardware; interfaces to foreign functions, services, components or low-level machine resources * Transformation and analysis: abstract interpretation; partial evaluation; program transformation * Software-development techniques: design patterns; specification; verification; validation; debugging; test generation; tracing; profiling * Practice and experience: novel results drawn from experience in education or industry * Functional pearls: elegant, instructive examples of functional programming A functional pearl need not report original research results, but it must be instructive, elegant, and fun. ICFP 2007 also seeks Experience Reports. An Experience Report is a short paper (2-4 pages) which need not present novel results, but which should provide evidence that functional programming really works or should describe obstacles that prevented it from working. Detailed guidelines appear below. What's new this year? ~~~~~~~~~~~~~~~~~~~~~ Experienced ICFP authors may want to pay special attention to the points below, which are new this year. * Double-blind review * Author-date citations * Supplemental material in a separate document, not appended to the main text * Morning deadline (but equivalent to late afternoon or early evening in many time zones of interest) * Experience Reports Instructions for authors ~~~~~~~~~~~~~~~~~~~~~~~~ By 11:00 AM Friday, 6 April 2007, Samoan time, submit an abstract of at most 300 words and a full paper of at most 12 pages or an Experience Report of at most 4 pages. Submissions will be accepted electronically, at a URL to be named later. The deadline is set at Samoan time, so if your submission is in by 11:00 AM Friday according to your local time, wherever you are, the submission will be on time. The world clock at http://www.timeanddate.com/worldclock/fixedtime.html?month=4&day=6&year=200… can give you the equivalent in your local time, e.g., 3:00 PM Friday in Portland, 6:00 PM Friday in Boston, and midnight Friday in Freiburg. The deadline is firm. Your submission should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. Make the technical content understandable to a broad audience. Each submission must adhere to SIGPLAN's republication policy, which appears in full at http://www.acm.org/sigplan/republicationpolicy.htm. The policy means in part that your paper may not have already appeared in a journal, conference, or workshop with published proceedings; that you may not submit substantially the same work simultaneously to ICFP and to another venue; and that your submission must discuss any closely related material, including your own, that was previously accepted at a journal, conference, or workshop with or without published proceedings. Full details of the policy are available at the SIGPLAN site. If you are in any doubt about whether this policy applies to your paper, either consult the program chair in advance or notify the chair when you submit. To do otherwise risks summary rejection of your submission. If your submission is accepted, you must assign copyright to ACM. Proceedings will be published by the ACM Press. Double-blind review ~~~~~~~~~~~~~~~~~~~ To increase confidence in the fairness and objectivity of the reviewing process, reviewing will be double blind. Make it possible for reviewers to evaluate your paper without having to know who you are. It should suffice to omit your names from your submission and to avoid revealing your identity through citation; detailed guidelines are available at http://icfp07.eecs.harvard.edu/blind.html. Formatting ~~~~~~~~~~ Your submission must be printable on US Letter sized paper and be either PDF or PostScript that is interpretable by Ghostscript. If this requirement is a hardship, make contact with the program chair at least one week before the deadline. Your submission must be at most 12 pages (4 pages for an Experience Report), including bibliography and figures, in the standard ACM conference format: two columns, nine-point font on a ten-point baseline, with pages 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter of 2pc (0.33in). (A suitable LaTeX class file is available from SIGPLAN; see http://www.acm.org/sigs/sigplan/authorInformation.htm. Categories, keywords, and so on are optional.) If you wish to supply material beyond the 12-page limit, up to and including a full technical report, you may attach a separate document to your submission, on the understanding that reviewers are not expected to read it. (As a particular example, if you feel that your submission should be supported by a lengthy technical report, do not cite such a technical report on the web, since doing so would reveal your identity. Please instead attach that report to your submission.) Detailed instructions for attaching supplementary documents will be available on the submission web site. The length limit is firm; submissions that do not meet these guidelines will not be considered. Citation ~~~~~~~~ We recommend (but do not require) that you put your citations into author-date form. This procedure makes your paper easier to review. For example, if you cite a result on testing as ``(Claessen and Hughes 2000)'', many reviewers will recognize the result instantly. On the other hand, if you cite it as ``[4]'', even the best-informed reviewer has to page through your paper to find the reference. By using author-date form, you enable a knowledgeable reviewer to focus on content, not arbitrary numbering of references. LaTeX users can simply use the natbib package along with the plainnat bibliography style. Author response ~~~~~~~~~~~~~~~ You will have a 48-hour period (11:00 23 May to 11:00 25 May 2007 Samoa time) to read and respond to reviews. Details of the author-response process will be available as it approaches. Special categories of papers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In addition to research papers, ICFP solicits two kinds of papers that do not require original research contributions: functional pearls, which are full papers, and Experience Reports, which are limited to four pages. Authors submitting such papers may wish to consider the following advice. Functional pearls ~~~~~~~~~~~~~~~~~ To paraphrase both Jon Bentley and Richard Bird, the ideal pearl goes beyond solid engineering into the realm of insight and creativity. Just as a natural pearl grows from a grain of sand that has irritated an oyster, a topnotch functional pearl should grow from a real problem that has irritated a programmer. A pearl should be polished, elegant, instructive, and entertaining. Ideally it should teach important programming techniques and fundamental design principles. Past pearls have included instructive examples of program calculation or proof, nifty presentations of old or new data structures, and interesting applications and programming techniques. Papers submitted to ICFP as pearls often miss the mark, by being too trivial, too complicated, or somehow not quite the elegant solution one hopes for. The key to an accepted pearl is polishing. Your pearl is likely to be rejected if your readers get bored, if the material gets too complicated, if too much specialized knowledge is needed, or if the writing is distasteful. Richard Bird advises: * Throw away the rule book for writing research papers. * Get in quick; get out quick. * Be self-contained; don't go deep into related work, with lengthy references. * You are telling a story, so some element of surprise is welcome. * Above all, be engaging. * Give a talk on the pearl to non-specialists, your students, or your department. If you changed the order of presentation for the talk, consider using the new order in the next draft. * Put the pearl away for a while, then take it out and polish it again. Experience reports ~~~~~~~~~~~~~~~~~~ ICFP has long solicited submissions on the practice and experience of functional programming. But reports of experience are inherently different from research papers, and when judged by the criteria of scientific merit, novelty, or research contribution, they have not competed well against traditional ICFP submissions. Yet we believe that the functional- programming community would benefit from being able to draw on and cite the experience of others. For this reason, we have introduced the ICFP Experience Report. Unlike a normal ICFP paper, the purpose of an Experience Report is not to add to the body of knowledge of the functional-programming community. Rather, the purpose of an Experience Report is to help create a body of published, refereed, citable *evidence* that functional programming really works---or to describe obstacles that prevented it from working. An Experience Report is distinguished from a normal ICFP paper by its title, by its length, and by the criteria used to evaluate it. * Both in the proceedings and in any citations, the title of each accepted Experience Report must begin with the words "Experience Report", followed by a colon. * Experience Reports are limited in length: the suggested length is 2 pages and the maximum length is 4 pages. Each accepted Experience Report will be presented at the conference, but depending on the number of Experience Reports and regular papers accepted, authors of Experience Reports may be asked to give shorter talks. * Because the purpose of Experience Reports is to enable our community to accumulate a published, citable body of evidence about the efficacy of functional programming, an acceptable Experience Report need not present novel results or conclusions. It is sufficient if the Report states a clear thesis and provides supporting evidence. The thesis must be relevant to ICFP, but it need not be novel. The program committee will accept or reject Experience Reports based on whether they judge the evidence to be convincing. Anecdotal evidence will be acceptable provided it is well argued and the author explains what efforts were made to gather as much evidence as possible. The committee will be especially convinced by evidence that includes *comparisons* of situations before and after the introduction or discontinuation of functional programming. Evidence drawn from a single person's experience may be sufficient, but more weight will be given to evidence drawn from the experience of groups of people. Possible topics for an Experience Report include, but are not limited to * Insights gained from real-world projects using functional programming * Comparison of functional programming with conventional programming in the context of an industrial project or a university curriculum * Project-management, business, or legal issues encountered when using functional programming in a real-world project * Curricular issues encountered when using functional programming in education * Real-world constraints that created special challenges for an implementation of a functional language or for functional programming in general An Experience Report should be short and to the point: if functional programming worked for you in the same ways it has worked for others, you need only to summarize the results---the main part of your paper should discuss how well it worked and in what context. Most readers will not want to know all the details of your project and its implementation, but please characterize your project and its context well enough so that readers can judge to what degree your experience is relevant to their own projects. Be especially careful to highlight any unusual aspects of your project. Also keep in mind that specifics about your project are more valuable than generalities about functional programming; for example, it is more valuable to say that your team delivered its software a month ahead of schedule than it is to say that functional programming made your team more productive. If your paper not only describes experience but also presents new technical results, or if your experience refutes cherished beliefs of the functional-programming community, you may be better off submitting it as a full paper, which will be judged by the usual criteria of novelty, originality, and relevance. If you unsure in which category to submit, the program chair will be happy to help you decide. Other information ~~~~~~~~~~~~~~~~~ Conference Chair ~~~~~~~~~~~~~~~~ Ralf Hinze (Universität Bonn) Program Chair ~~~~~~~~~~~~~ Norman Ramsey Harvard University Cambridge, MA, 02148 USA Email: icfp07(a)eecs.harvard.edu Phone: +1 617 496 8615 Mail sent to the address above is filtered for spam. If you send mail and do not receive a prompt response, particularly if the deadline is looming, feel free to telephone and reverse the charges. Program Committee ~~~~~~~~~~~~~~~~~ Nick Benton (Microsoft Research) Matthew Fluet (Toyota Technological Institute) Jeremy Gibbons (University of Oxford) Kevin Hammond (University of St Andrews) Bastiaan Heeren (Utrecht University) Graham Hutton (University of Nottingham) Mark P. Jones (Portland State University) Gabriele Keller (University of New South Wales) Fabrice Le Fessant (INRIA/LIX, France) Todd Millstein (UCLA) Mike Sperber (DeinProgramm) Christopher A. Stone (Harvey Mudd College) Andrew Tolmach (Portland State University and INRIA Rocquencourt) Janis Voigtländer (Technische Universität Dresden) Stephanie Weirich (University of Pennsylvania) Important Dates ~~~~~~~~~~~~~~~ Submission: 11:00 6 April 2007, Samoa time (AST) Author response: 11:00 23 May to 11:00 25 May 2007 (AST) Notification: 8 June 2007 Final papers due: 20 July 2007 ICFP 2007 Web Site ~~~~~~~~~~~~~~~~~~ http://www.informatik.uni-bonn.de/~ralf/icfp07.html Special Issue of JFP ~~~~~~~~~~~~~~~~~~~~ Authors of the best final papers, as determined by the program committee, will be invited to submit journal versions for a special issue of the Journal of Functional Programming.

1 0

A question about a possible bug in GHC regarding GADTs and type classes
by Pablo Nogueira 17 Jan '07

17 Jan '07

Hi, I've been told the following short code is correct but it's GHC's fault it does not type check. Is that the case? -- {-# OPTIONS -fglasgow-exts #-} -- An expression GADT: data Exp :: * -> * where LitNum :: Num a => a -> Exp a LitBool :: Bool -> Exp Bool Plus :: Num a => Exp a -> Exp a -> Exp a And :: Exp Bool -> Exp Bool -> Exp Bool If :: Exp Bool -> Exp a -> Exp a -> Exp a -- An expression evaluator: evalExp :: Exp a -> a evalExp (LitNum i) = i evalExp (LitBool b) = b evalExp (Plus x y) = evalExp x + evalExp y evalExp (And x y) = evalExp x && evalExp y evalExp (If c t e) = if (evalExp c) then (evalExp t) else (evalExp e) -- The type checker complains that evalExp needs a Num constraint on its type signature. This can't be right, for Bool is not an instance of Num, right? Is it the case that the interaction between GADTs and type classes is not fully worked out yet? Here is a related problem. I'd like to make the types of expressions extensible by using a type class: -- class TyRange a instance TyRange Int instance TyRange Bool data Exp :: * -> * where Lit :: TyRange a => a -> Exp a Plus :: Exp Int -> Exp Int -> Exp Int And :: Exp Bool -> Exp Bool -> Exp Bool If :: TyRange a => Exp Bool -> Exp a -> Exp a -> Exp a But I cannot add the types in other classes into TyRange in modular fashion, cause the superclass is specified at the moment of declaration. I may try to extend TyRange by adding the instances in, say, Num: -- {-# OPTIONS -fglasgow-exts #-} {-# OPTIONS -fallow-undecidable-instances #-} class TyRange a instance TyRange Bool instance Num a => TyRange a data Exp :: * -> * where Lit :: TyRange a => a -> Exp a Plus :: Exp Int -> Exp Int -> Exp Int And :: Exp Bool -> Exp Bool -> Exp Bool If :: TyRange a => Exp Bool -> Exp a -> Exp a -> Exp a evalExp :: Exp a -> a evalExp (Lit i) = i evalExp (Plus x y) = evalExp x + evalExp y evalExp (And x y) = evalExp x && evalExp y evalExp (If c t e) = if (evalExp c) then (evalExp t) else (evalExp e) -- But I get the following error when evaluating evalExp (If (Lit True) (Lit 1) (Lit 2)) Overlapping instances for TyRange Bool arising from use of `Lit' at <interactive>:1:13-15 Matching instances: /home/pni/Papers/EDT/TyRangeProblem.hs:5:0: instance TyRange Bool /home/pni/Papers/EDT/TyRangeProblem.hs:4:0: instance (Num a) => TyRange a In the first argument of `If', namely `(Lit True)' In the first argument of `evalExp', namely `(If (Lit True) (Lit 1) (Lit 2)) Apologies for being so daft, but why are the instances overlapping if Bool is not in Num?

1 0

ANNOUNCE: Phooey 0.1 -- Functional user interface library
by Conal Elliott 17 Jan '07

17 Jan '07

I've just release version 0.1 of Phooey, an arrow-based functional user interface library. Please see the new project page at http://haskell.org/haskellwiki/phooey . What's new in version 0.1: - Relocated, improved & wikified home page, with new section on Motivation. - Text input (textEntry) - Boolean input/output (checkBoxEntry, checkBoxDisplay) - Switched from monadLib to mtl, for easier installation - Web-located references to other libraries (base, mtl, arrows.) - Colorized source code links (thanks to hscolour). - Docs have "User Comments" links, for adding add comments and questions. - Phooey is now used in TV: http://haskell.org/haskellwiki/TV . Cheers, - Conal

2 1

ANNOUNCE: TV 0.0 -- Tangible Values / composable interfaces
by Conal Elliott 17 Jan '07

17 Jan '07

I'm happy to announce the birth of *TV*, a library for composing *tangible values* ("TVs"), i.e., values that carry along external interfaces. In particular, TVs can be composed to create new TVs, *and* they can be directly executed with a friendly GUI, a process that reads and writes character streams, or many other kinds interfaces. Values and interfaces are *combined* for direct use, and *separable* for composability. Please see the project page at http://haskell.org/haskellwiki/TV . TV makes use of the DeepArrow and Phooey libraries. Cheers, - Conal

1 0

ANNOUNCE: DeepArrow 0.0 -- Arrows for "deep application"
by Conal Elliott 17 Jan '07

17 Jan '07

I'm happy to announce the birth of DeepArrow, a Haskell library for composable "editors" of pure values. DeepArrow enables "deep function application" in two senses: deep application of functions and application of deep functions. These tools generalize beyond values and functions, via the DeepArrow subclass of the Arrow type class. Please see the project page at http://haskell.org/haskellwiki/DeepArrow . Cheers, - Conal

1 0

Capturing output from System.system
by Mads Lindstrøm 17 Jan '07

17 Jan '07

Hi All Haskeleers The function System.system (:: String -> IO ExitCode) makes the OS execute it first parameter as a command. It prints its output to standard output and standard error. How do I easily capture this output? /Mads Lindstrøm

4 3

ANNOUNCE hscom library
by Krasimir Angelov 15 Jan '07

15 Jan '07

Hello all, I have created darcs repository for my hscom library at: http://darcs.haskell.org/packages/hscom/ This is a FFI library for Microsoft COM. It is far from complete and it doesn't have automatic IDL->Haskell translator but if you have ever thought to start writing you own COM library for Haskell then please take a look. Maybe you will find it useful and you might be willing to extend it. It is designed to be as close as possible to the standard FFI library for C. That helps to reuse the existing library as much as possible and to keep the new library as small as possible. Cheers, Krasimir

1 0

Postdoctoral Research Fellow at St Andrews
by Kevin Hammond 15 Jan '07

15 Jan '07

I have a vacancy for a postdoctoral research fellow, working with the Hume language developed jointly with Heriot-Watt University (http://www.hume-lang.org) Knowledge of Haskell and other functional programming technologies is a distinct advantage. Please do forward to anyone who may be interested, and please let me know if you intend to make a late application or if you see this late (the deadline is January 17th, but I may need to extend this). Note that the Human Resources department has only listed the lower salary level on the research fellow scale: my understanding is that there is in fact a range. Best Wishes, Kevin University of St Andrews, School of Computer Science ========================================= Postdoctoral Research Fellow in Worst-Case Execution Time Analysis for Embedded Software Salary - £26,915+ pa(*) Applications are invited from well-qualified individuals. The post involves the development of static analyses of worst-case time behaviour for embedded software, working on industrial/EU projects as part of the internationally recognised functional programming group at the University of St Andrews. Appointments will be made for one year in the first instance, with a possibility of extension based on pending funding applications. The start date will be 1 March 2007, or as soon as possible thereafter. Informal enquiries to: Dr Kevin Hammond, email: kh8(a)cs.st-and.ac.uk * Salary is subject to confirmation under the new Framework Agreement. Please quote ref: SK109/06 Closing Date: 17 January 2007 Application forms and further particulars are available from Human Resources, University of St Andrews, College Gate, North Street, St Andrews, Fife KY16 9AJ, (tel: 01334 462571, by fax 01334 462570 or by e-mail Jobline(a)st-andrews.ac.uk. The advertisement and further particulars can be viewed at http://www.st-andrews.ac.uk/hr/recruitment/vacancies. The University is committed to equality of opportunity. http://www.st-andrews.ac.uk/hr/recruitment/vacancies/vacancy-list -- In accordance with University policy on electronic mail, this email reflects the opinions of the individual concerned, may contain confidential or copyright information that should not be copied or distributed without permission, may be of a private or personal nature unless explicitly indicated otherwise, and should not under any circumstances be taken as an official statement of University policy or procedure (see http://www.st-and.ac.uk)

1 0