From icfp.publicity at googlemail.com Sun Dec 6 03:40:22 2015 From: icfp.publicity at googlemail.com (Lindsey Kuper) Date: Sun, 06 Dec 2015 03:40:22 +0000 Subject: [Haskell] ICFP 2016 Call for Papers Message-ID: <94eb2c0329cc149eba05263280ec@google.com>                               ICFP 2016 The 21st ACM SIGPLAN International Conference on Functional Programming                http://conf.researchr.org/home/icfp-2016                            Call for Papers Important dates --------------- Submissions due:    Wednesday, March 16 2016, 15:00 (UTC)                     https://icfp2016.hotcrp.com                     (in preparation as of December 1) Author response:    Monday, 2 May, 2016, 15:00 (UTC) -                     Thursday, 5 May, 2016, 15:00 (UTC) Notification:       Friday, 20 May, 2016 Final copy due:     TBA Early registration: TBA Conference:         Tuesday, 20 September -                     Thursday, 22 September, 2016 Scope ----- ICFP 2016 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, and 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, concurrency, or parallelism. Topics of interest include (but are not limited to): - Language Design: concurrency, parallelism, and distribution;   modules; components and composition; metaprogramming; type systems;   interoperability; domain-specific languages; and relations to   imperative, object-oriented, or logic programming. - Implementation: abstract machines; virtual machines; interpretation;   compilation; compile-time and run-time optimization; garbage   collection and memory management; multi-threading; exploiting   parallel hardware; interfaces to foreign functions, services,   components, or low-level machine resources. - Software-Development Techniques: algorithms and data structures;   design patterns; specification; verification; validation; proof   assistants; debugging; testing; tracing; profiling. - Foundations: formal semantics; lambda calculus; rewriting; type   theory; monads; continuations; control; state; effects; program   verification; dependent types. - Analysis and Transformation: control-flow; data-flow; abstract   interpretation; partial evaluation; program calculation. - Applications: symbolic computing; formal-methods tools; artificial   intelligence; systems programming; distributed-systems and web   programming; hardware design; databases; XML processing; scientific   and numerical computing; graphical user interfaces; multimedia and   3D graphics programming; scripting; system administration; security. - Education: teaching introductory programming; parallel programming;   mathematical proof; algebra. - Functional Pearls: elegant, instructive, and fun essays on   functional programming. - Experience Reports: short papers that provide evidence that   functional programming really works or describe obstacles that have   kept it from working. If you are concerned about the appropriateness of some topic, do not hesitate to contact the program chair. Abbreviated instructions for authors ------------------------------------ - By Wednesday, March 16 2016, 15:00 (UTC), submit a full paper of at   most 12 pages (6 pages for an Experience Report), in standard   SIGPLAN conference format, including figures but ***excluding   bibliography***. The deadlines will be strictly enforced and papers exceeding the page limits will be summarily rejected. ***ICFP 2016 will employ a lightweight double-blind reviewing process.*** To facilitate this, submitted papers must adhere to two rules:  1. ***author names and institutions must be omitted***, and  2. ***references to authors' own related work should be in the third     person*** (e.g., not "We build on our previous work ..." but     rather "We build on the work of ..."). The purpose of this process is to help the PC and external reviewers come to an initial judgement about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. We have put together a document answering frequently asked questions that should address many common concerns: http://conf.researchr.org/track/icfp-2016/icfp-2016-papers#Submission-and-Reviewing-FAQ - Authors have the option to attach supplementary material to a   submission, on the understanding that reviewers may choose not to   look at it. The material should be uploaded at submission time, as a   single pdf or a tarball, not via a URL. This supplementary material   may or may not be anonymized; if not anonymized, it will only be   revealed to reviewers after they have submitted their review of your   paper and learned your identity. - Each submission must adhere to SIGPLAN's republication policy, as   explained on the web at:   http://www.sigplan.org/Resources/Policies/Republication - Authors of resubmitted (but previously rejected) papers have the   option to attach an annotated copy of the reviews of their previous   submission(s), explaining how they have addressed these previous   reviews in the present submission. If a reviewer identifies   him/herself as a reviewer of this previous submission and wishes to   see how his/her comments have been addressed, the program chair will   communicate to this reviewer the annotated copy of his/her previous   review. Otherwise, no reviewer will read the annotated copies of the   previous reviews. Overall, a submission will be evaluated according to its relevance, correctness, significance, originality, and clarity. It 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. The technical content should be accessible to a broad audience. Functional Pearls and Experience Reports are separate categories of papers that need not report original research results and must be marked as such at the time of submission. Detailed guidelines on both categories are given below. Presentations will be videotaped and released online if the presenter consents. The proceedings will be freely available for download from the ACM Digital Library from at least one week before the start of the conference until two weeks after the conference. Formatting: Submissions must be in PDF format printable in black and white on US Letter sized paper and interpretable by Ghostscript. Papers must adhere to the standard SIGPLAN conference format: two columns, nine-point font on a ten-point baseline, with columns 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter of 2pc (0.33in). A suitable document template for LaTeX is available at http://www.sigplan.org/Resources/Author/ Submission: Submissions will be accepted at https://icfp2016.hotcrp.com (in preparation as of December 1). Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Author response: Authors will have a 72-hour period, starting at 15:00 UTC on Monday, 2 May, 2016, to read reviews and respond to them. ACM Author-Izer is a unique service that enables ACM authors to generate and post links on either their home page or institutional repository for visitors to download the definitive version of their articles from the ACM Digital Library at no charge. Downloads through Author-Izer links are captured in official ACM statistics, improving the accuracy of usage and impact measurements. Consistently linking the definitive version of ACM article should reduce user confusion over article versioning. After your article has been published and assigned to your ACM Author Profile page, please visit http://www.acm.org/publications/acm-author-izer-service to learn how to create your links for free downloads from the ACM DL. Publication date: The official publication date of accepted papers is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. 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 six pages. Authors submitting such papers may wish to consider the following advice. Functional Pearls ================= A Functional Pearl is an elegant essay about something related to functional programming. Examples include, but are not limited to: - a new and thought-provoking way of looking at an old idea - an instructive example of program calculation or proof - a nifty presentation of an old or new data structure - an interesting application of functional programming techniques - a novel use or exposition of functional programming in the classroom While pearls often demonstrate an idea through the development of a short program, there is no requirement or expectation that they do so. Thus, they encompass the notions of theoretical and educational pearls. Functional Pearls are valued as highly and judged as rigorously as ordinary papers, but using somewhat different criteria. In particular, a pearl is not required to report original research, but, it should be concise, instructive, and entertaining. 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 inelegant. The key to writing a good pearl is polishing. A submission you wish to have treated as a pearl must be marked as such on the submission web page, and should contain the words ``Functional Pearl'' somewhere in its title or subtitle. These steps will alert reviewers to use the appropriate evaluation criteria. Pearls will be combined with ordinary papers, however, for the purpose of computing the conference's acceptance rate. Experience Reports ================== 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 what obstacles prevent it from working. 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 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. The acceptance rate for Experience   Reports will be computed and reported separately from the rate for   ordinary papers. - An Experience Report is at most six pages long. 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 body of evidence about the efficacy of functional   programming, an acceptable Experience Report need not add to the   body of knowledge of the functional-programming community by   presenting 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. Typically, more convincing evidence is obtained from papers which show how functional programming was used than from papers which only say that functional programming was used. The most convincing evidence often 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. An Experience Report should be short and to the point: make a claim about how well functional programming worked on your project and why, and produce evidence to substantiate your claim. 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 are unsure in which category to submit, the program chair will be happy to help you decide. Organizers ---------- General Co-Chairs: Jacques Garrigue (Nagoya University) Gabriele Keller (University of New South Wales) Program Chair: Eijiro Sumii (Tohoku University) Program Committee: Koen Claessen (Chalmers University of Technology) Joshua Dunfield (University of British Columbia, Canada) Matthew Fluet (Rochester Institute of Technology) Nate Foster (Cornell University) Dan Grossman (University of Washington, USA) Jurriaan Hage (Utrecht University) Roman Leshchinskiy (Standard Chartered Bank) Keisuke Nakano (The University of Electro-Communications) Aleksandar Nanevski (IMDEA Software Institute) Scott Owens (University of Kent) Sungwoo Park (Pohang University of Science and Technology) Amr Sabry (Indiana University) Tom Schrijvers (KU Leuven) Olin Shivers (Northeastern University) Walid Taha (Halmstad University) Dimitrios Vytiniotis (Microsoft Research, Cambridge) David Walker (Princeton University) Nobuko Yoshida (Imperial College London, UK) External Review Committee to be announced. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjgtuyl at chello.nl Sun Dec 6 17:19:15 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sun, 06 Dec 2015 18:19:15 +0100 Subject: [Haskell] [Haskell-beginners] DOOM rewritten in the Haskell programming language. In-Reply-To: <451608938.16111539.1449415275423.JavaMail.yahoo@mail.yahoo.com> References: <451608938.16111539.1449415275423.JavaMail.yahoo.ref@mail.yahoo.com> <451608938.16111539.1449415275423.JavaMail.yahoo@mail.yahoo.com> Message-ID: On Sun, 06 Dec 2015 16:21:15 +0100, David Blubaugh wrote: > TO ALL, > Hello My name is David Allen Blubaugh. I am currently considering > starting a kick-starter project in redeveloping the DOOM source code > with the Haskell Programming language using the power of > functional-oriented programming...... > I know that John Carmack was interested in the Haskell programming > language and had even recreated wolfenstein 3D using the Haskell > programming language. Does anybody have a copy of John Carmack's > recreation of wolfenstein 3D using haskell ??? Also would anybody enjoy > working with this project ??? What benefits would DOOM have enjoyed had > ID software created the DOOM source code in 1993 with Haskell or some > other functional-oriented programming language instead of C/assembly > programming languages ??? Thanks, > David Allen BlubaughElectrical EngineerATR Associate I don't know about his source code, but the Games page[0] lists: - hadoom A clone of Doom, using reactive-banana, GTK, and the "diagrams" library. https://github.com/ocharles/hadoom - Frag A 3D first person shooting game https://wiki.haskell.org/Frag These might be helpful. Advantages, when developing software in Haskell, are faster development with fewer bugs. Disadvantages are: the compiled programs are slower then when written in C and the garbage collection of a Haskell program (when compiled with GHC) might sometimes cause delays in screen updates. Regards, Henk-Jan van Tuyl [0] https://wiki.haskell.org/Games -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From icfp.publicity at googlemail.com Mon Dec 7 08:49:55 2015 From: icfp.publicity at googlemail.com (Lindsey Kuper) Date: Mon, 7 Dec 2015 00:49:55 -0800 Subject: [Haskell] ICFP 2016 Call for Papers In-Reply-To: <94eb2c0329cc149eba05263280ec@google.com> References: <94eb2c0329cc149eba05263280ec@google.com> Message-ID: [My apologies for the garbled text in a previous version of this email. -- Lindsey] ICFP 2016 The 21st ACM SIGPLAN International Conference on Functional Programming http://conf.researchr.org/home/icfp-2016 Call for Papers Important dates --------------- Submissions due: Wednesday, March 16 2016, 15:00 (UTC) https://icfp2016.hotcrp.com (in preparation as of December 1) Author response: Monday, 2 May, 2016, 15:00 (UTC) - Thursday, 5 May, 2016, 15:00 (UTC) Notification: Friday, 20 May, 2016 Final copy due: TBA Early registration: TBA Conference: Tuesday, 20 September - Thursday, 22 September, 2016 Scope ----- ICFP 2016 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, and 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, concurrency, or parallelism. Topics of interest include (but are not limited to): - Language Design: concurrency, parallelism, and distribution; modules; components and composition; metaprogramming; type systems; interoperability; domain-specific languages; and relations to imperative, object-oriented, or logic programming. - Implementation: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; garbage collection and memory management; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components, or low-level machine resources. - Software-Development Techniques: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling. - Foundations: formal semantics; lambda calculus; rewriting; type theory; monads; continuations; control; state; effects; program verification; dependent types. - Analysis and Transformation: control-flow; data-flow; abstract interpretation; partial evaluation; program calculation. - Applications: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed-systems and web programming; hardware design; databases; XML processing; scientific and numerical computing; graphical user interfaces; multimedia and 3D graphics programming; scripting; system administration; security. - Education: teaching introductory programming; parallel programming; mathematical proof; algebra. - Functional Pearls: elegant, instructive, and fun essays on functional programming. - Experience Reports: short papers that provide evidence that functional programming really works or describe obstacles that have kept it from working. If you are concerned about the appropriateness of some topic, do not hesitate to contact the program chair. Abbreviated instructions for authors ------------------------------------ - By Wednesday, March 16 2016, 15:00 (UTC), submit a full paper of at most 12 pages (6 pages for an Experience Report), in standard SIGPLAN conference format, including figures but ***excluding bibliography***. The deadlines will be strictly enforced and papers exceeding the page limits will be summarily rejected. ***ICFP 2016 will employ a lightweight double-blind reviewing process.*** To facilitate this, submitted papers must adhere to two rules: 1. ***author names and institutions must be omitted***, and 2. ***references to authors' own related work should be in the third person*** (e.g., not "We build on our previous work ..." but rather "We build on the work of ..."). The purpose of this process is to help the PC and external reviewers come to an initial judgement about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. We have put together a document answering frequently asked questions that should address many common concerns: http://conf.researchr.org/track/icfp-2016/icfp-2016-papers#Submission-and-Reviewing-FAQ - Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. The material should be uploaded at submission time, as a single pdf or a tarball, not via a URL. This supplementary material may or may not be anonymized; if not anonymized, it will only be revealed to reviewers after they have submitted their review of your paper and learned your identity. - Each submission must adhere to SIGPLAN's republication policy, as explained on the web at: http://www.sigplan.org/Resources/Policies/Republication - Authors of resubmitted (but previously rejected) papers have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the program chair will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. Overall, a submission will be evaluated according to its relevance, correctness, significance, originality, and clarity. It 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. The technical content should be accessible to a broad audience. Functional Pearls and Experience Reports are separate categories of papers that need not report original research results and must be marked as such at the time of submission. Detailed guidelines on both categories are given below. Presentations will be videotaped and released online if the presenter consents. The proceedings will be freely available for download from the ACM Digital Library from at least one week before the start of the conference until two weeks after the conference. Formatting: Submissions must be in PDF format printable in black and white on US Letter sized paper and interpretable by Ghostscript. Papers must adhere to the standard SIGPLAN conference format: two columns, nine-point font on a ten-point baseline, with columns 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter of 2pc (0.33in). A suitable document template for LaTeX is available at http://www.sigplan.org/Resources/Author/ Submission: Submissions will be accepted at https://icfp2016.hotcrp.com (in preparation as of December 1). Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Author response: Authors will have a 72-hour period, starting at 15:00 UTC on Monday, 2 May, 2016, to read reviews and respond to them. ACM Author-Izer is a unique service that enables ACM authors to generate and post links on either their home page or institutional repository for visitors to download the definitive version of their articles from the ACM Digital Library at no charge. Downloads through Author-Izer links are captured in official ACM statistics, improving the accuracy of usage and impact measurements. Consistently linking the definitive version of ACM article should reduce user confusion over article versioning. After your article has been published and assigned to your ACM Author Profile page, please visit http://www.acm.org/publications/acm-author-izer-service to learn how to create your links for free downloads from the ACM DL. Publication date: The official publication date of accepted papers is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. 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 six pages. Authors submitting such papers may wish to consider the following advice. Functional Pearls ================= A Functional Pearl is an elegant essay about something related to functional programming. Examples include, but are not limited to: - a new and thought-provoking way of looking at an old idea - an instructive example of program calculation or proof - a nifty presentation of an old or new data structure - an interesting application of functional programming techniques - a novel use or exposition of functional programming in the classroom While pearls often demonstrate an idea through the development of a short program, there is no requirement or expectation that they do so. Thus, they encompass the notions of theoretical and educational pearls. Functional Pearls are valued as highly and judged as rigorously as ordinary papers, but using somewhat different criteria. In particular, a pearl is not required to report original research, but, it should be concise, instructive, and entertaining. 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 inelegant. The key to writing a good pearl is polishing. A submission you wish to have treated as a pearl must be marked as such on the submission web page, and should contain the words ``Functional Pearl'' somewhere in its title or subtitle. These steps will alert reviewers to use the appropriate evaluation criteria. Pearls will be combined with ordinary papers, however, for the purpose of computing the conference's acceptance rate. Experience Reports ================== 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 what obstacles prevent it from working. 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 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. The acceptance rate for Experience Reports will be computed and reported separately from the rate for ordinary papers. - An Experience Report is at most six pages long. 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 body of evidence about the efficacy of functional programming, an acceptable Experience Report need not add to the body of knowledge of the functional-programming community by presenting 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. Typically, more convincing evidence is obtained from papers which show how functional programming was used than from papers which only say that functional programming was used. The most convincing evidence often 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. An Experience Report should be short and to the point: make a claim about how well functional programming worked on your project and why, and produce evidence to substantiate your claim. 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 are unsure in which category to submit, the program chair will be happy to help you decide. Organizers ---------- General Co-Chairs: Jacques Garrigue (Nagoya University) Gabriele Keller (University of New South Wales) Program Chair: Eijiro Sumii (Tohoku University) Program Committee: Koen Claessen (Chalmers University of Technology) Joshua Dunfield (University of British Columbia, Canada) Matthew Fluet (Rochester Institute of Technology) Nate Foster (Cornell University) Dan Grossman (University of Washington, USA) Jurriaan Hage (Utrecht University) Roman Leshchinskiy (Standard Chartered Bank) Keisuke Nakano (The University of Electro-Communications) Aleksandar Nanevski (IMDEA Software Institute) Scott Owens (University of Kent) Sungwoo Park (Pohang University of Science and Technology) Amr Sabry (Indiana University) Tom Schrijvers (KU Leuven) Olin Shivers (Northeastern University) Walid Taha (Halmstad University) Dimitrios Vytiniotis (Microsoft Research, Cambridge) David Walker (Princeton University) Nobuko Yoshida (Imperial College London, UK) External Review Committee to be announced. From alexander at plaimi.net Mon Dec 7 10:54:45 2015 From: alexander at plaimi.net (Alexander Berntsen) Date: Mon, 7 Dec 2015 11:54:45 +0100 Subject: [Haskell] [Haskell-beginners] DOOM rewritten in the Haskell programming language. In-Reply-To: <451608938.16111539.1449415275423.JavaMail.yahoo@mail.yahoo.com> References: <451608938.16111539.1449415275423.JavaMail.yahoo.ref@mail.yahoo.com> <451608938.16111539.1449415275423.JavaMail.yahoo@mail.yahoo.com> Message-ID: <56656575.8090109@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 David, I think it would be more valuable to make a DOOM-like game than to remake DOOM. Especially if you are going to aim for funding. The free software community has had this problem for years, where we point to remakes of old games as evidence to viability. It isn't. Nobody will be swayed by Haskell DOOM. (Although I would, personally, think it interesting.) Good luck with your project. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWZWV0AAoJENQqWdRUGk8B0bMQAKu/4hBeS7Iz23IMIatrc5Jd hkWm/bG8FRCtiLyETiH9NtUL5RPtmS+s3+o05h6fZZ1VFFfzucygsmOTw27kWApc ZpZiypv22y7uJsrbyxFgXVp2w6vfp6rrdA+vRSOUp/dmJ+vnn7jVeGUInnlAKX50 WAsEUPx0q4IhGnF/2O3kBuKw/baGvp2kne2IjrgdAJ5qptVEvVoAEpIG3WveTnlP LQMBwTLrB+TkdTIZWTYUT/e8MYZorU5x6LN+GtKuO28PEEG0jS2IgfNeUnzZjalF p37Av84UCiIhTQD3LV6Eq1sQThQMVMm/S+qkqZrNL3I/+TbS3Ztf6q7u7zDRCsnr vum2JR0f9vtGfpd5j3hGVXjQTd0jU3uFdY1kHM0ISGTSKYrOGYs4qsCL/VxPubo8 Lh7YfCltXY+LQkz/Q2FElcd9eM9xYWSOBhPhiudXZ3f+PnkBNRwH03eWk/LHgmhB MByAdf2WCAU4DK7xpJKkCVsyOlsC17t8CtKDIfnt/RkPUr8108i6KOh6zvDR94Du lJyQWuCbL7FFb7uXVO7cKTeWJFejd/K5GrQBTBpVEy3xA15c8Kj+9ALWrdJAlion ktS85eEcp/3IzrNpPby8lhjJvujwzbzny+a9Jdn8ZcybBwpF3+IRSARnb7lJ4Yba Ca972BfXJnFZXiYARfov =mGnp -----END PGP SIGNATURE----- From sumit.sahrawat.apm13 at iitbhu.ac.in Mon Dec 7 11:04:56 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Mon, 7 Dec 2015 16:34:56 +0530 Subject: [Haskell] [Haskell-beginners] DOOM rewritten in the Haskell programming language. In-Reply-To: <56656575.8090109@plaimi.net> References: <451608938.16111539.1449415275423.JavaMail.yahoo.ref@mail.yahoo.com> <451608938.16111539.1449415275423.JavaMail.yahoo@mail.yahoo.com> <56656575.8090109@plaimi.net> Message-ID: I'm interested in game development, and would be willing to learn and contribute if the project kicks off. Just showing my support, good luck with the project. On 7 December 2015 at 16:24, Alexander Berntsen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > David, > > I think it would be more valuable to make a DOOM-like game than to > remake DOOM. Especially if you are going to aim for funding. The free > software community has had this problem for years, where we point to > remakes of old games as evidence to viability. It isn't. Nobody will > be swayed by Haskell DOOM. (Although I would, personally, think it > interesting.) > > Good luck with your project. > - -- > Alexander > alexander at plaimi.net > https://secure.plaimi.net/~alexander > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCgAGBQJWZWV0AAoJENQqWdRUGk8B0bMQAKu/4hBeS7Iz23IMIatrc5Jd > hkWm/bG8FRCtiLyETiH9NtUL5RPtmS+s3+o05h6fZZ1VFFfzucygsmOTw27kWApc > ZpZiypv22y7uJsrbyxFgXVp2w6vfp6rrdA+vRSOUp/dmJ+vnn7jVeGUInnlAKX50 > WAsEUPx0q4IhGnF/2O3kBuKw/baGvp2kne2IjrgdAJ5qptVEvVoAEpIG3WveTnlP > LQMBwTLrB+TkdTIZWTYUT/e8MYZorU5x6LN+GtKuO28PEEG0jS2IgfNeUnzZjalF > p37Av84UCiIhTQD3LV6Eq1sQThQMVMm/S+qkqZrNL3I/+TbS3Ztf6q7u7zDRCsnr > vum2JR0f9vtGfpd5j3hGVXjQTd0jU3uFdY1kHM0ISGTSKYrOGYs4qsCL/VxPubo8 > Lh7YfCltXY+LQkz/Q2FElcd9eM9xYWSOBhPhiudXZ3f+PnkBNRwH03eWk/LHgmhB > MByAdf2WCAU4DK7xpJKkCVsyOlsC17t8CtKDIfnt/RkPUr8108i6KOh6zvDR94Du > lJyQWuCbL7FFb7uXVO7cKTeWJFejd/K5GrQBTBpVEy3xA15c8Kj+9ALWrdJAlion > ktS85eEcp/3IzrNpPby8lhjJvujwzbzny+a9Jdn8ZcybBwpF3+IRSARnb7lJ4Yba > Ca972BfXJnFZXiYARfov > =mGnp > -----END PGP SIGNATURE----- > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From plredmond at gmail.com Mon Dec 7 18:30:23 2015 From: plredmond at gmail.com (Patrick Redmond) Date: Mon, 7 Dec 2015 10:30:23 -0800 Subject: [Haskell] [Haskell-beginners] DOOM rewritten in the Haskell programming language. In-Reply-To: References: <451608938.16111539.1449415275423.JavaMail.yahoo.ref@mail.yahoo.com> <451608938.16111539.1449415275423.JavaMail.yahoo@mail.yahoo.com> <56656575.8090109@plaimi.net> Message-ID: I'd also like to show support and participate in building this out if work is needed. Contact me when/if that happens! On Monday, December 7, 2015, Sumit Sahrawat, Maths & Computing, IIT (BHU) < sumit.sahrawat.apm13 at iitbhu.ac.in> wrote: > I'm interested in game development, and would be willing to learn and > contribute if the project kicks off. > > Just showing my support, good luck with the project. > > On 7 December 2015 at 16:24, Alexander Berntsen > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> David, >> >> I think it would be more valuable to make a DOOM-like game than to >> remake DOOM. Especially if you are going to aim for funding. The free >> software community has had this problem for years, where we point to >> remakes of old games as evidence to viability. It isn't. Nobody will >> be swayed by Haskell DOOM. (Although I would, personally, think it >> interesting.) >> >> Good luck with your project. >> - -- >> Alexander >> alexander at plaimi.net >> >> https://secure.plaimi.net/~alexander >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >> >> iQIcBAEBCgAGBQJWZWV0AAoJENQqWdRUGk8B0bMQAKu/4hBeS7Iz23IMIatrc5Jd >> hkWm/bG8FRCtiLyETiH9NtUL5RPtmS+s3+o05h6fZZ1VFFfzucygsmOTw27kWApc >> ZpZiypv22y7uJsrbyxFgXVp2w6vfp6rrdA+vRSOUp/dmJ+vnn7jVeGUInnlAKX50 >> WAsEUPx0q4IhGnF/2O3kBuKw/baGvp2kne2IjrgdAJ5qptVEvVoAEpIG3WveTnlP >> LQMBwTLrB+TkdTIZWTYUT/e8MYZorU5x6LN+GtKuO28PEEG0jS2IgfNeUnzZjalF >> p37Av84UCiIhTQD3LV6Eq1sQThQMVMm/S+qkqZrNL3I/+TbS3Ztf6q7u7zDRCsnr >> vum2JR0f9vtGfpd5j3hGVXjQTd0jU3uFdY1kHM0ISGTSKYrOGYs4qsCL/VxPubo8 >> Lh7YfCltXY+LQkz/Q2FElcd9eM9xYWSOBhPhiudXZ3f+PnkBNRwH03eWk/LHgmhB >> MByAdf2WCAU4DK7xpJKkCVsyOlsC17t8CtKDIfnt/RkPUr8108i6KOh6zvDR94Du >> lJyQWuCbL7FFb7uXVO7cKTeWJFejd/K5GrQBTBpVEy3xA15c8Kj+9ALWrdJAlion >> ktS85eEcp/3IzrNpPby8lhjJvujwzbzny+a9Jdn8ZcybBwpF3+IRSARnb7lJ4Yba >> Ca972BfXJnFZXiYARfov >> =mGnp >> -----END PGP SIGNATURE----- >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> > > > > -- > Regards > > Sumit Sahrawat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Mon Dec 7 18:34:03 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 7 Dec 2015 19:34:03 +0100 (CET) Subject: [Haskell] [Haskell-beginners] DOOM rewritten in the Haskell programming language. In-Reply-To: References: <451608938.16111539.1449415275423.JavaMail.yahoo.ref@mail.yahoo.com> <451608938.16111539.1449415275423.JavaMail.yahoo@mail.yahoo.com> <56656575.8090109@plaimi.net> Message-ID: On Mon, 7 Dec 2015, Patrick Redmond wrote: > I'd also like to show support and participate in building this out if work is needed. Contact me when/if that happens! haskell at haskell.org is an announcement list. Please continue discussion in haskell-cafe etc. From bob.atkey at gmail.com Tue Dec 8 13:19:45 2015 From: bob.atkey at gmail.com (Bob Atkey) Date: Tue, 8 Dec 2015 13:19:45 +0000 Subject: [Haskell] MSFP 2016: Call for Papers Message-ID: <5666D8F1.6080908@gmail.com> Sixth Workshop on MATHEMATICALLY STRUCTURED FUNCTIONAL PROGRAMMING 8 April 2014, in Eindhoven, The Netherlands A satellite workshop of ETAPS 2016 http://msfp2016.bentnib.org/ The sixth workshop on Mathematically Structured Functional Programming is devoted to the derivation of functionality from structure. It is a celebration of the direct impact of Theoretical Computer Science on programs as we write them today. Modern programming languages, and in particular functional languages, support the direct expression of mathematical structures, equipping programmers with tools of remarkable power and abstraction. Where would Haskell be without monads? Functional reactive programming without temporal logic? Call-by-push-value without adjunctions? The list goes on. This workshop is a forum for researchers who seek to reflect mathematical phenomena in data and control. The first MSFP workshop was held in Kuressaare, Estonia, in July 2006, affiliated with MPC 2006 and AMAST 2006. The second MSFP workshop was held in Reykjavik, Iceland as part of ICALP 2008. The third MSFP workshop was held in Baltimore, USA, as part of ICFP 2010. The fourth workshop was held in Tallinn, Estonia, as part of ETAPS 2012. The fifth workshop was held in Grenoble, France, as part of ETAPS 2014. Important Dates: ================ Abstract 10th January 2016 Submission 17th January 2016 Notification 17th February 2016 Final version 24th February 2016 Workshop 8th April 2016 Invited Speakers: ================= To be announced. Program Committee: ================== Zena Ariola, University of Oregon Robert Atkey, University of Strathclyde (co-chair) Chantal Keller, IUT d'Orsay Neelakantan Krishnaswami, University of Birmingham (co-chair) Helle Hvid Hansen, Delft University of Technology Nicolas Wu, University of Bristol Ornela Dardha, University of Glasgow Submission: =========== Papers must report previously unpublished work and not be submitted concurrently to another conference with refereed proceedings. Accepted papers must be presented at the workshop by one of the authors, and will be published under the auspices of EPTCS under a Creative Commons license. There is no specific page limit, but authors should strive for brevity. From gershomb at gmail.com Wed Dec 9 17:10:06 2015 From: gershomb at gmail.com (Gershom B) Date: Wed, 9 Dec 2015 12:10:06 -0500 Subject: [Haskell] ANNOUNCE: Haskell Platform 7.10.3 Message-ID: Haskellers, we are pleased to announce the release of Haskell Platform 7.10.3 * * get it here: https://www.haskell.org/platform/ * * Highlights include: - GHC 7.10.3 - Major version bumps to - HUnit - OpenGL - OpenGLRaw - syb - Minor version bumps to - Cabal - case-insensitive - fgl - GLUT - GLURaw - primitive Full package and version list: https://www.haskell.org/platform/contents.html GHC release notes can be found at: http://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide/release-7-10-3.html This is the first release in which I've taken over as release manager. Thanks to Erik Rantapaa, Ben Gamari, Randy Polen and Jason Dagit for various platform related work; thanks to Oleg Grenrus and John Wiegley for additional testing; and thanks of course to Mark Lentczner for developing the new streamlined HP build process that has made things so much easier for all of us. * Windows Notes * The Haskell Platform on Windows now provides the MSys2 tools. These tools are needed when installing packages that use conf-tools (generally rare). These tools are not automatically placed onto the PATH in order avoid troubles due to MSys2 tools which have the same name as a standard Windows tool (e.g., echo, find, dir). * Future Plans * As per the November 13 email on "Haskell Platform Plans" (https://mail.haskell.org/pipermail/haskell-cafe/2015-November/122171.html) this is a modest release for ghc, and also a modest release for the platform, to put a capstone on the 7.10 series. Coming with the 8.0 platform we'll have lots of the exciting stuff that has been long promised, including a minimal distro without extra packages, a bundled stack binary, and a much-improved experience for installing build-type: configure packages (such as network) on Windows. Issues can be reported on the github tracker: https://github.com/haskell/haskell-platform/issues * Known Issues * As the platform builds were done from the tarballs lacking 7.10.3 release notes, those notes will not be present in the installed users' guides. However, they are available online, as in the link given above. Happy Haskelling, Gershom Bazerman, Haskell Platform release manager From oleg at okmij.org Thu Dec 10 09:39:06 2015 From: oleg at okmij.org (Oleg) Date: Thu, 10 Dec 2015 18:39:06 +0900 Subject: [Haskell] FLOPS 2016: Call for Participation and Posters/Demos Message-ID: <20151210093906.GA1715@Magus.sf-private> FLOPS 2016: 13th International Symposium on Functional and Logic Programming March 4-6, 2016, Kochi, Japan http://www.info.kochi-tech.ac.jp/FLOPS2016/ Call for Participation and Posters/Demos Registration will be open on Monday, Dec 21, 2015. Early registration deadline is Monday, Feb 8, 2016. Poster/Demo abstract submission deadline is Monday, Jan 11, 2016. FLOPS aims to bring together practitioners, researchers and implementers of the declarative programming, to discuss mutually interesting results and common problems: theoretical advances, their implementations in language systems and tools, and applications of these systems in practice. The scope includes all aspects of the design, semantics, theory, applications, implementations, and teaching of declarative programming. FLOPS specifically aims to promote cross-fertilization between theory and practice and among different styles of declarative programming. In addition to the presentations of regular research papers, the FLOPS program includes tutorials, as well as the poster/demo session for demonstrating the tools and systems described during the talks and for presenting works-in-progress and getting the feedback. FLOPS has established a Best Paper award. The winner will be announced at the symposium. CALLS FOR POSTERS AND DEMONSTRATIONS If you wish to present a poster at FLOPS, please send the plain text abstract by e-mail to -- by January 11, 2016. The abstract should include the title, the names of the authors and their affiliation, along with enough details to judge its scope and relevance. We will announce the accepted submissions on January 25, 2016. The format of the poster will be announced at that time. Important Dates * Submission due: January 11, 2016 (Monday), any time zone * Notification: January 25, 2016 (Monday) INVITED TALKS Kazunori UEDA (Waseda University) The exciting time and hard-won lessons of the Fifth Generation Computer Project Atze Dijkstra (Utrecht University) UHC: Coping with Compiler Complexity TUTORIALS Andreas Abel, on Agda Atze Dijkstra, on Attribute Grammars Neng-Fa Zhou, on programming in Picat ACCEPTED PAPERS Ki Yung Ahn and Andrea Vezzosi. Executable Relational Specifications of Polymorphic Type Systems using Prolog Markus Triska. The Boolean Constraint Solver of SWI-Prolog: System Description Peng Fu, Ekaterina Komendantskaya, Tom Schrijvers and Andrew Pond. Proof Relevant Corecursive Resolution Jay McCarthy, Burke Fetscher, Max New and Robert Bruce Findler. A Coq Library For Internal Verification of Running-Times Akimasa Morihata. Incremental Computing with Abstract Data Structures Wouter Swierstra and Joao Alpuim. >From proposition to program: embedding the refinement calculus in Coq Andre Van Delft and Anatoliy Kmetyuk. Declarative Programming with Algebra Ian Mackie and Shinya Sato. An interaction net encoding of Godel's System T Arthur Blot, Pierre-Evariste Dagand and Julia Lawall. >From Sets to Bits in Coq Jeremy Yallop, David Sheets and Anil Madhavapeddy. Declarative foreign function binding through generic programming Praveen Narayanan, Jacques Carette, Wren Romano, Chung-Chieh Shan and Robert Zinkov. Probabilistic inference by program transformation in Hakaru: System description Francisco Javier Lopez-Fraguas, Manuel Montenegro and Juan Rodriguez-Hortala. Polymorphic Types in Erlang Function Specifications Remy Haemmerle, Pedro Lopez-Garcia, Umer Liqat, Maximiliano Klemen, John Gallagher and Manuel V. Hermenegildo. A Transformational Approach to Parametric Accumulated-cost Static Profiling Taus Brock-Nannestad. Space-efficient Planar Acyclicity Constraints: A Declarative Pearl From atze at uu.nl Mon Dec 14 10:58:05 2015 From: atze at uu.nl (Atze Dijkstra) Date: Mon, 14 Dec 2015 11:58:05 +0100 Subject: [Haskell] [NL-FP 2016] Final CFP: Dutch Functional Programming Day 2016 Message-ID: [My apologies for multiple received copies of the same message] Final Call for Participation: Dear all, The next Dutch Functional Programming day (NL-FP 2016) will be held on Friday, January 8, 2016 at the Utrecht University, The Netherlands. The program of the day now is online (see the below webpage). At the end of the day we will have a joint dinner. Besides the program, on the web page http://foswiki.cs.uu.nl/foswiki/NlFpDay2016/WebHome for the day you?ll also find the registration, which is by letting me know via email (with a subject header that begins with [NL-FP 2016]) whether you want to (1) participate, (2) join dinner, also see the webpage for additional details. There is still room for a demo or poster during lunch/break time. If you intend to participate, please let me know before the end of this year because we like to know how many people we can expect. Hope to meet you all in Utrecht at the next FP Day! Best regards, - Atze - Atze Dijkstra, Department of Information and Computing Sciences. /|\ Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \ Tel.: +31-30-2534118/1454 | WWW : http://www.cs.uu.nl/~atze . /--| \ Fax : +31-30-2513971 .... | Email: atze at uu.nl ............... / |___\ -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.F.Berger at sussex.ac.uk Mon Dec 14 12:59:35 2015 From: M.F.Berger at sussex.ac.uk (Martin Berger) Date: Mon, 14 Dec 2015 12:59:35 +0000 Subject: [Haskell] PhD scholarship on foundations of meta-programming Message-ID: <65B6D060-7D32-4921-9A51-639C4605D081@sussex.ac.uk> I apologise if you get this message multiple times. ------ Applications are invited for a fully funded PhD studentship in the Department of Informatics at the University of Sussex, starting in October 2016. The topic of the studentship is to develop the foundations of meta-programming, and extending our understanding of how to specify and verify meta-programs, in terms of theoretical understanding, implementation and tooling. For further details, see http://www.jobs.ac.uk/job/AMO053/foundations-of-meta-programming or contact Martin Berger . The Scholarship normally includes a three year stipend at a standard rate (currently ?14057 per annum) and, in addition, fees as follows: (a) for Home/EU applicants, full fees; (b) overseas applicants, a contribution of up to ?12000 towards overseas fees, depending on qualifications. The studentship is available to students of any nationality. Applicants are normally expected to have a first-class Masters or Bachelors degree in Computer Science, Mathematics or a related discipline, and must obtain the support of the supervisor prior to submitting their application. Initial contact with supervisors should be made at least two weeks prior to the closing date for applications. For details about funding and the application procedure contact Luke Scott . Closing date for applications is 4th January 2016. From james.cheney at gmail.com Tue Dec 15 15:55:41 2015 From: james.cheney at gmail.com (James Cheney) Date: Tue, 15 Dec 2015 15:55:41 +0000 Subject: [Haskell] Postdoctoral and PhD positions in LFCS on graph databases, provenance, and programming languages Message-ID: Hi, As a result of recent funding awards, I expect to be able to advertise two postdoctoral positions and a PhD position at the Laboratory for Foundations of Computer Science, University of Edinburgh in the near future: * The first postdoc position will be advertised early in January to start as soon as possible (in practice, this likely means February 2016 at the absolute earliest; I'd prefer to have someone by March or April if possible). The position will require a mix of research and development skills, to contribute to the development of a system for processing and analyzing provenance graph data in order to identify and mitigate advanced persistent threat attacks. Preferred programming languages among other project members include Haskell, Scala and Python. Experience with graph databases such as Titan/Cassandra or the Gremlin query language would be a big plus. I would like to hire someone to work on this project whose research dovetails well with the development needed for the project. This could mean a systems-oriented PL researcher interested in gaining experience with graph databases, provenance or security, or a researcher in one of these areas interested in gaining experience with PL. This position is part of the ADAPT project (A Diagnostics Approach for Advanced Persistent Threat Detection) funded by the DARPA Transparent Computing Program. The other partners in ADAPT are Galois, Inc., Xerox PARC, and Oregon State University. The funding is secure until June 2017 and funding after that point is contingent on continuation of the project by DARPA, until the program ends in June 2019. * The second postdoc and PhD studentship position will be advertised later in 2016 for a start date of mid-to-late 2016. Both will be part of the ERC-funded project "Skye: A programming language bridging theory and practice for scientific data curation". Relevant topics/background include heterogeneous metaprogramming, language-integrated query, and scientific data management and provenance. Both positions will have funding for up to 4 years in the period 2016-2021 (pending finalization of the grant agreement). This message does not constitute a formal advertisement of an employment opportunity; formal advertisements will follow when the details are finalized. Please contact me if interested in any of these opportunities or with any questions about the projects, and research environment, and preferably including a CV and summary of your research interests and how they relate to the position(s) you are interested in. --James -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Wed Dec 16 15:42:16 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 16 Dec 2015 15:42:16 +0000 Subject: [Haskell] Research internship at Facebook Message-ID: <56718658.1010501@gmail.com> We have a research internship available for summer 2016 working with the Haxl team at Facebook. The internship is available to mid-term PhD students, and should be of interest to anyone who is interested in working on Haskell, concurrency, garbage collection, static analysis, or related areas. We have a number of projects in mind and we would aim to take the student's background and expertise into account when choosing the specific project. For more details and to apply, go here: https://www.facebook.com/careers/jobs/a0I1200000I9saG/ Cheers, Simon From jeremy.gibbons at cs.ox.ac.uk Thu Dec 17 21:35:09 2015 From: jeremy.gibbons at cs.ox.ac.uk (Jeremy Gibbons) Date: Thu, 17 Dec 2015 21:35:09 +0000 Subject: [Haskell] Associate or Full Professorship in Programming Languages at Oxford Message-ID: <5FEAF372-C0B5-497D-AA28-5095E104B625@cs.ox.ac.uk> The Department of Computer Science at University of Oxford has an opening for an Associate or Full Professorship in Programming Languages, as described below. Please pass this advert on to anyone who may be interested. I would be happy to answer any questions. -jg * Applications are invited for the post of Associate Professor (or Professor) of Programming Languages, to be held in the Department of Computer Science, to start as soon as possible. The successful candidate will also be appointed to a Fellowship at Kellogg College. You will join a vibrant and rapidly-growing computer science department, with a long history of fundamental research in the area of programming languages, benefiting from a rich academic environment for computer science research, with many researchers working in closely-related areas. You will be a member of both the University and the College community, which is an intellectually stimulating research environment, performing to the highest international levels in research and publications, and will have access to the excellent research facilities which Oxford offers. You will have a role to play in the running of the College as a member of its Governing Body, together with your departmental research, teaching, and examining duties. Candidates should hold a doctoral degree in computer science (or cognate discipline), with a proven global research record in peer-reviewed journals, including the ability to attract research funding. You should have experience in teaching programming languages and related topics within Computer Science at graduate level, including supervising graduate students. Experience of research collaborations on a national or global level is highly desirable. Applications are particularly welcome from women and black and minority ethnic candidates, who are under-represented in academic posts in Oxford. The closing date for applications is 12.00 midday on 15 February 2016. For further particulars, and details of how to apply, see: http://tinyurl.com/p3ckkab Contact Person: Michael Wooldridge (mjw at cs.ox.ac.uk) [or JG, at the address below] Vacancy ID : 121645 Grade 36S: Salary on scale from ?45,066 - ?59,914 pa (plus benefits) Closing Date : 15-Feb-2016 Jeremy.Gibbons at cs.ox.ac.uk Oxford University Department of Computer Science, Wolfson Building, Parks Road, Oxford OX1 3QD, UK. +44 1865 283521 http://www.cs.ox.ac.uk/people/jeremy.gibbons/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tamarit27 at gmail.com Wed Dec 23 12:06:49 2015 From: tamarit27 at gmail.com (Salvador Tamarit) Date: Wed, 23 Dec 2015 13:06:49 +0100 Subject: [Haskell] CfP: Workshop on Program Transformation for Programmability in Heterogeneous Architectures (Co-located with CGO16); Deadline Jan 15 Message-ID: ********************************************************************************* PROHA 2016, CALL FOR PAPERS First Workshop on Program Transformation for Programmability in Heterogeneous Architectures http://goo.gl/RzGbzY Barcelona, 12th March 2016, in conjunction with the CGO'16 Conference ********************************************************************************* Important Dates: Paper submission deadline: 15 January 2016 23:59 (UTC) Author notification: 5 February 2016 Final manuscript due: 26 February 2016 Scope: Developing and maintaining high-performance applications and libraries for heterogeneous architectures is a difficult task, usually requiring code transformations performed by an expert. Tools assisting in and, if possible, automating such transformations are of course of great interest. However, such tools require significant knowledge and reasoning capabilities. For example, the former could be a machine-understandable descriptions of what a piece of code is expected to do, while the latter could be a set of transformations and a corresponding logical context in which they are applicable, respectively. Furthermore, strategies to identify the sequence of transformations leading to the best resulting code need to be elaborated. This workshop will focus on techniques and foundations which make it possible to perform source code transformations, which preserve the intended semantics of the original code and improve efficiency, portability or maintainability. The topics of interest for the workshop include, but are not limited to: * Program annotations to capture algorithmic properties and intended code semantics. * Programming paradigms able to express underlying (mathematical) properties of code. * Usage of dynamic and static mechanisms to infer relevant code properties. * Transformations which preserve intended semantics. * Strategies to apply transformations. * Heuristics to guide program transformation and techniques to synthesize / learn these heuristics. * Tools Submission Guidelines: Submissions are to be written in English and not exceed 10 pages, including bibliography. Submissions should be written in ACM double-column format using a 10-point type. Authors should follow the information for formatting ACM SIGPLAN conference papers, which can be found at http://www.sigplan.org/Resources/Author . Authors should submit their papers in pdf format using the EasyChair submission website https://easychair.org/conferences/?conf=proha2016 . Publication: The proceedings will be made publicly available through ArXiV. Workshop Organizers: - Manuel Carro, IMDEA Software Institute and Technical University of Madrid - Colin W. Glass, University of Stuttgart - Jan Kuper, University of Twente - Julio Mari?o, Technical University of Madrid - Lutz Schubert, University of Ulm - Guillermo Vigueras, IMDEA Software Institute - Salvador Tamarit, Technical University of Madrid If you have any questions, please contact the program chair at manuel.carro at imdea.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjgtuyl at chello.nl Wed Dec 30 13:26:33 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Wed, 30 Dec 2015 14:26:33 +0100 Subject: [Haskell] ANN: wxInstall Achelanne and wxHaskell 0.92.2.0 Message-ID: L.S., I am happy to announce a new version of wxHaskell: 0.92.2.0 and new installation packages for wxHaskell on Windows: wxInstall Achelanne 0.1 (32 bit and 64 bit) Changes in wxHaskell since 0.92.1: - Solved warnings for wxcore, wxdirect, wxc - Added support for Pickerctrl, Hyperlinkctrl and some Streams in wxc and wxcore - Solved several bugs - Added some image Functions in wxc and wxcore - Added enumerateFonts function in wxcore - Updated wxBITMAP_TYPE_ constants - Adapted to GHC 7.10.3 Thanks to everyone who contributed! wxInstall Achelanne[0] is created because GHC 7.10.3 for Windows is accompanied with a newer GCC: 5.2.0. A detailed description can be found at the wxHaskell-for-Windows homepage[1]. What is wxHaskell? ------------------ wxHaskell[2] is a portable and native GUI library for Haskell. The goal of the project is to provide an industrial strength GUI library for Haskell, but without the burden of developing (and maintaining) one ourselves. wxHaskell is therefore built on top of wxWidgets ? a comprehensive C++ library that is portable across all major GUI platforms; including GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library (in development since 1992) that supports a wide range of widgets with the native look-and-feel. Links ----- See the homepage of wxHaskell for more information: https://wiki.haskell.org/WxHaskell The packages are: - wxc https://hackage.haskell.org/package/wxc - wxdirect https://hackage.haskell.org/package/wxdirect - wxcore https://hackage.haskell.org/package/wxcore - wx https://hackage.haskell.org/package/wx Regards, Henk-Jan van Tuyl [0] http://sourceforge.net/projects/wxhaskell/files/wxInstall/ [1] https://wiki.haskell.org/WxHaskell/Windows#Installing_the_easy_way [2] https://wiki.haskell.org/WxHaskell -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From anthony_clayden at clear.net.nz Thu Dec 31 01:05:21 2015 From: anthony_clayden at clear.net.nz (AntC) Date: Thu, 31 Dec 2015 01:05:21 +0000 (UTC) Subject: [Haskell] =?utf-8?q?ANN=3A_HaskRel=3B=09Employing_GHC_as_a_DBMS_w?= =?utf-8?q?ith_support_for_the_relational_algebra?= References: <3144C46F-4621-4E0A-9692-9BFEEF9BAF8C@gmail.com> Message-ID: Thor Michael St?re gmail.com> writes: > > After much scratching of my head over intricate parts of this "Haskell" thing > I'm happy to announce that I've finally released my first effort in it: HaskRel. > Thank you and congratulations on dipping your toe in the water. Was it very painful coming from Java ;-) ? [transferring to the cafe for discussion.] I see you're claiming to base HaskRel on ttm. I'm afraid the more I look, the less ttm-like it looks. Perhaps I should explain that looking like ttm doesn't just mean being different to SQL. HaskRel just seems to be a way of holding sets of records, supporting some relational-like operators over those sets. The records don't appear very like ttm tuples. Take an example relation value from that hackage page: let foo = relation' [( 10, "foo" ),( 20, "bar" ) ] :: Relation '[Attr "asdf" Int, Attr "qwer" String] The function /relation'/ presumably takes a list of Haskell tuples, and converts it to a HaskRel relation. The equivalent(-ish) Tutorial D would be: foo := REL{ TUP{ asdf 10, qwer "foo" }, TUP{ asdf 20, qwer "bar"} } (OK, compared to the HaskRel I've omitted the INT and CHAR signatures for attributes asdf and qwer respectively.) What is not apparent to me in the HaskRel syntax is whether we have each tuple being a set of triples. I think it's okay to omit the T (type of the value) because in Haskell every value must be at a type. But in HaskRel the attribute is 'hidden' in the signature. (It's a "phantom type".) It seems you can't freely order tuples. This is exactly the same relation as the Tut D above: foo := REL{ TUP{ asdf 10, qwer "foo" }, TUP{ qwer "bar", asdf 20} } You can't reorder the attributes like that in HaskRel -- you'll get a type error. Having the Attribute names 'hidden' is going to be difficult for any operation needing to name attributes, such as: - projecting - renaming - extending - restricting (attrib names appearing in the WHERE expr) IOW Attribute names don't appear to be first-class values. (Did you consider making attributes data constructors -- newtypes, so getting pairs explicit in the syntax. Perhaps that can be done with phantom types using proxy value constructors -- hmm seems messy.) I'm not sufficiently stimulated by what I've seen, to go hunting how HaskRel handles those operations. Given Haskell is a functional language, with first-class lambda expressions, this would have been a great testbed for the 'algorithmic relations' idea from HHT 1975. [see download on the ttm website, with comments by Hugh] On a Haskell state-of-the-art note: given all the heat around Haskell record system proposals, HaskRel doesn't seem to use any of them. (There's talk of Lenses for one flavour of HaskRel.) I'm not saying that's a wrong decision, but I'd like to understand the reasoning. Anthony From jeremy at n-heptane.com Thu Dec 31 19:23:56 2015 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Thu, 31 Dec 2015 13:23:56 -0600 Subject: [Haskell] ANN: HaskRel; Employing GHC as a DBMS with support for the relational algebra In-Reply-To: <3144C46F-4621-4E0A-9692-9BFEEF9BAF8C@gmail.com> References: <3144C46F-4621-4E0A-9692-9BFEEF9BAF8C@gmail.com> Message-ID: Would it be feasible to use this in conjunction with [acid-state]( http://acid-state.seize.it/) to create a more complete RDBMS? - jeremy On Sun, Nov 22, 2015 at 7:22 PM, Thor Michael St?re wrote: > Hello, > > After much scratching of my head over intricate parts of this "Haskell" > thing > I'm happy to announce that I've finally released my first effort in it: > HaskRel. > > Overview > -------- > > Because I've spent quite a bit of time on database prompts I thought it > would be > a fun exercise to see how much GHC can be made to operate like a DBMS, and > how > much of the relational model of database management (as defined by Chris > Date et > al. today) I'm able to make it accommodate. I'm pleased to register that > the > relational algebra, base variables and assignment works as one would > expect at a > database prompt. It does not qualify as an actual *RDBMS* > (unsurprisingly), > since it doesn't implement many other things that are required for it to > be a > proper RDBMS, either because I haven't gotten around to it or they cannot > be > implemented in Haskell. > > I've put the source up on GitHub and published it on Hackage: > > Hackage: > http://hackage.haskell.org/package/HaskRel > > GitHub: > https://github.com/thormick/HaskRel/tree/master/HaskRel > > HaskRel employs a Data.Set of Data.HList.Record as a relation type, for > which it > defines "Relation" as a synonym. It supports base variables (files) of this > type, and implements the functions of the relational algebra such that > they can > be expressed upon both constants or literal values, upon variables, and > upon > expressions on variables. > > Example > ------- > > The following is a minimal definition of a database with a single relation > variable, "sp": > > module MiniDB where > > import Data.HList.CommonMain > import Database.HaskRel.RDBMS > > sp :: Relvar '[Attr "sno" String, > Attr "pno" String, > Attr "qty" Integer] > sp = Relvar "SP.rv" > > > "Attr" has been defined as a synonym for "Data.Tagged.Tagged", because > that is > employed to represent what are known as attributes in relational theory. > Loading > this in GHCi we can first create a relation constant, do some relational > assignment, and print the results (pardon the long lines): > > *MiniDB> let s = ( relation' [ ( "S1", "Smith", 20, "London" ), ( "S2", > "Jones", 10, "Paris" ), ( "S3", "Blake", 30, "Paris" ) ] :: Relation '[Attr > "sno" String, Attr "sName" String, Attr "status" Integer, Attr "city" > String] ) > *MiniDB> pt s > ???????????????????????????????????????????????????????????????????????? > ? sno :: String ? sName :: String ? status :: Integer ? city :: String ? > ???????????????????????????????????????????????????????????????????????? > ? S1 ? Smith ? 20 ? London ? > ? S2 ? Jones ? 10 ? Paris ? > ? S3 ? Blake ? 30 ? Paris ? > ???????????????????????????????????????????????????????????????????????? > *MiniDB> sp `assign` ( relation' [ ("S1", "P1", 300), ("S1", "P3", 400), > ("S1", "P5", 100), ("S2", "P1", 300), ("S3", "P2", 200) ] :: Relation > '[Attr "sno" String, Attr "pno" String, Attr "qty" Integer] ) > Value assigned to ./SP.rv > *MiniDB> pt sp > ?????????????????????????????????????????????????? > ? sno :: String ? pno :: String ? qty :: Integer ? > ?????????????????????????????????????????????????? > ? S1 ? P1 ? 300 ? > ? S1 ? P3 ? 400 ? > ? S1 ? P5 ? 100 ? > ? S2 ? P1 ? 300 ? > ? S3 ? P2 ? 200 ? > ?????????????????????????????????????????????????? > > > (Mind that correct display of the Unicode table drawing characters depends > on > using the right fixed-width font.) > > Fundamental operations of the relational algebra can of course be > performed on > them: > > *MiniDB> p $ s `naturalJoin` sp > ????????????????????????????????????????????? > ? sno ? sName ? status ? city ? pno ? qty ? > ????????????????????????????????????????????? > ? S1 ? Smith ? 20 ? London ? P1 ? 300 ? > ? S1 ? Smith ? 20 ? London ? P3 ? 400 ? > ? S1 ? Smith ? 20 ? London ? P5 ? 100 ? > ? S2 ? Jones ? 10 ? Paris ? P1 ? 300 ? > ? S3 ? Blake ? 30 ? Paris ? P2 ? 200 ? > ????????????????????????????????????????????? > > > A proper relational database management system (which, again, this isn't, > for > several other reasons) must support type inference for relational > expressions > (see The Third Manifesto, relational model prescription 18). Fortunately, > that > is of course no problem for GHC with the right extensions: > > *MiniDB> :t s > s :: Relation > '[Attr "sno" String, Attr "sName" String, Attr "status" Integer, > Attr "city" String] > *MiniDB> :t sp > sp > :: Relvar > '[Attr "sno" String, Attr "pno" String, Attr "qty" Integer] > *MiniDB> :t s `naturalJoin` sp > s `naturalJoin` sp > :: IO > (containers-0.5.6.2:Data.Set.Base.Set > (RTuple > '[Tagged "sno" String, Tagged "sName" String, > Tagged "status" Integer, Tagged "city" String, Tagged "pno" > [Char], > Tagged "qty" Integer])) > > > DML is also supported, of course: > > *MiniDB> insert sp ( relation' [ ("S1", "P2", 200), ("S1", "P3", 400), > ("S1", "P4", 200) ] :: Relation '[Attr "sno" String, Attr "pno" String, > Attr "qty" Integer] ) > Inserted 2 of 3 tuples into ./SP.rv > > > Concise expression of "update" require a set of language extensions (this > in > addition to DataKinds, which this module enables by default since it is > quite > ubiquitous in this endeavor): > > *MiniDB> :set -XQuasiQuotes -XKindSignatures -XViewPatterns > *MiniDB> :{ > *MiniDB| update sp (\[pun|pno qty|] -> ( pno == "P2" || pno == "P3" || pno > == "P4" ) && qty < 300 ) > *MiniDB| (\[pun|qty|] -> case qty + 50 of qty -> [pun|qty|]) > *MiniDB| :} > Updated 3 of 7 tuples in ./SP.rv > *MiniDB> pt$ sp `restrict` \[pun|pno|] -> ( pno == "P2" || pno == "P3" || > pno == "P4" ) > ?????????????????????????????????????????????????? > ? sno :: String ? pno :: String ? qty :: Integer ? > ?????????????????????????????????????????????????? > ? S1 ? P2 ? 250 ? > ? S1 ? P3 ? 400 ? > ? S1 ? P4 ? 250 ? > ? S3 ? P2 ? 250 ? > ?????????????????????????????????????????????????? > > > And of course delete-by-predicate: > > *MiniDB> count sp > 7 > *MiniDB> deleteP sp (\[pun|pno|] -> pno == "P3") > Deleted 1 tuples from SP.rv > *MiniDB> count sp > 6 > > > For an overview of the functions of the relational algebra and relational > assignment defined by HaskRel see: > > > http://hackage.haskell.org/package/HaskRel/docs/Database-HaskRel-Relational-Expression.html > > Summary > ------- > > This is a personal, spare-time project, the motivations for which have > been to > learn Haskell, and see how much of the relational model Haskell/GHC can > accommodate, or how much like an RDBMS GHC can operate. Making this > practically > usable has not been part of the scope. > > Ascertaining that Haskell/GHC accommodates the relational algebra, > relational > base variables and operations thereupon in such a straight forward manner, > was > quite nice. It was particularly fun to see how this allowed examples of > expressions in Tutorial D from Chris Date's "SQL and Relational Theory, > 2nd. ed" > to be expressed in Haskell in a manner quite verbatim to the originals (see > > https://github.com/thormick/HaskRel/blob/master/HaskRel/examples/SuppliersPartsExample.hs > and chapters 6 and 7 of said book). It was also interesting to see trivial > querying and DML operations on GHCi operate in a manner similar to what one > would expect in a DBMS. > > Even if this isn't of practical use I still hope it is of some interest, > or at > least that it can enable Haskell as a demonstrator of some parts of the > relational model for database management. > > Thanks, > Thor Michael St?re > > > _______________________________________________ > Haskell mailing list > Haskell at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > > -------------- next part -------------- An HTML attachment was scrubbed... URL: