From tfp2007 at shu.edu Fri Dec 1 13:36:46 2006 From: tfp2007 at shu.edu (TFP 2007) Date: Fri Dec 1 13:35:09 2006 Subject: [Hat] First Call for Papers: TFP 2007, New York Message-ID: CALL FOR PAPERS Trends in Functional Programming 2007 New York, USA April 2-4, 2007 http://cs.shu.edu/tfp2007/ OR http://tltc.shu.edu/tfp2007/ The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming languages, focusing on providing a broad view of current and future trends in Functional Programming. It aspires to be a lively environment for presenting the latest research results through acceptance by extended abstracts. A formal post-symposium refereeing process then selects the best articles presented at the symposium for publication in a high-profile volume. TFP 2007 is co-hosted by Seton Hall University and The City College of New York (CCNY) and will be held in New York, USA, April 2-4, 2007 at the CCNY campus. SCOPE OF THE SYMPOSIUM The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research Articles leading-edge, previously unpublished research work Position Articles on what new trends should or should not be Project Articles descriptions of recently started new projects Evaluation Articles what lessons can be drawn from a finished project Overview Articles summarizing work with respect to a trendy subject Articles must be original and not submitted for simultaneous publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or more experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Articles on the following subject areas are particularly welcomed: o Dependently Typed Functional Programming o Validation and Verification of Functional Programs o Debugging for Functional Languages o Functional Programming and Security o Functional Programming and Mobility o Functional Programming to Animate/Prototype/Implement Systems from Formal or Semi-Formal Specifications o Functional Languages for Telecommunications Applications o Functional Languages for Embedded Systems o Functional Programming Applied to Global Computing o Functional GRIDs o Functional Programming Ideas in Imperative or Object-Oriented Settings (and the converse) o Interoperability with Imperative Programming Languages o Novel Memory Management Techniques o Parallel/Concurrent Functional Languages o Program Transformation Techniques o Empirical Performance Studies o Abstract/Virtual Machines and Compilers for Functional Languages o New Implementation Strategies o any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2007 program chair, Marco T. Morazan, at tfp2007@shu.edu. SUBMISSION AND DRAFT PROCEEDINGS Acceptance of articles for presentation at the symposium is based on the review of extended abstracts (6 to 10 pages in length) by the program committee. Accepted abstracts are to be completed to full papers before the symposium for publication in the draft proceedings and on-line. Further details can be found at the TFP 2007 website. POST-SYMPOSIUM REFEREEING AND PUBLICATION In addition to the draft symposium proceedings, we intend to continue the TFP tradition of publishing a high-quality subset of contributions in the Intellect series on Trends in Functional Programming. IMPORTANT DATES Abstract Submission: February 1, 2007 Notification of Acceptance: February 20, 2007 Registration Deadline: March 2, 2007 Camera Ready Full Paper Due: March 9, 2007 TFP Symposium: April 2-4, 2007 PROGRAMME COMMITTEE John Clements California Polytechnic State University, USA Marko van Eekelen Radboud Universiteit Nijmegen, The Netherlands Benjamin Goldberg New York University, USA Kevin Hammond University of St. Andrews, UK Patricia Johann Rutgers University, USA Hans-Wolfgang Loidl Ludwig-Maximilians Universit?t M?nchen, Germany Rita Loogen Philipps-Universit?t Marburg, Germany Greg Michaelson Heriot-Watt University, UK Marco T. Moraz?n (Chair) Seton Hall University, USA Henrik Nilsson University of Nottingham, UK Chris Okasaki United States Military Academy at West Point, USA Rex Page University of Oklahoma, USA Ricardo Pena Universidad Complutense de Madrid, Spain Benjamin C. Pierce University of Pennsylvania, USA John Reppy University of Chicago, USA Ulrik P. Schultz University of Southern Denmark, Denmark Clara Segura Universidad Complutense de Madrid, Spain Jocelyn S?rot Universit? Blaise Pascal, France Zhong Shao Yale University, USA Olin Shivers Georgia Institute of Technology, USA Phil Trinder Heriot-Watt University, UK David Walker Princeton University, USA ORGANIZATION Symposium Chair: Henrik Nilsson, University of Nottingham, UK Programme Chair: Marco T. Morazan, Seton Hall University, USA Treasurer: Greg Michaelson, Heriot-Watt University, UK Local Arrangements: Marco T. Morazan, Seton Hall University, USA ************************************************************************************ Dr. Marco T. Morazan TFP 2007 Program Committee Chair http://tltc.shu.edu/tfp2007/ http://cs.shu.edu/tfp2007/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/hat/attachments/20061201/4b72ea0c/attachment-0001.htm From t.cooper at firenet.uk.net Sat Dec 2 16:25:14 2006 From: t.cooper at firenet.uk.net (Tom Cooper) Date: Sat Dec 9 07:38:16 2006 Subject: [Hat] Program Compiles With GHC 6.6 but not Hat Message-ID: <6.0.1.1.0.20061202212514.0219cd68@mail.firenet.uk.net> Olaf said: >This is caused by a limitation of Hat: Hat cannot handle defaulting of >numeric classes. >In real programs we have hardly ever come across uses of defaulting. > >Ciao, >Olaf Malcolm said: * Implementing type inference is difficult enough that we did not consider the effort worthwhile for the tiny benefit of being able to handle defaulting. Bernie said: a slightly inconvenient problem These assessments depend very much on your point of view. The only proper program I have tried to use hat on required rewriting to get hat to understand it. The program was only ~2k lines of code, and there were 3 different idiosyncrasies of hat which gave problems. The defaulting idiosyncrasy was one of them. I imagine that most people that try hat find it won't understand their code, and give up on it immediately. I am therefore skeptical that this is hardly ever a problem for people even if you 'hardly ever come across' it. I don't remember reading, when I downloaded hat, that it was a beta version, or that I would need to change my code in order for hat to work on it, let alone a systematic description of the changes I would have to make. This made it very difficult to understand the problems I was having, and used a lot of my time, and some other people's too. These three idiosyncrasies, if I recall correctly, required ~20 unwanted changes in my code, so I made a hat version of my code with these alterations, but it is very difficult to keep two parallel versions of a piece of code up to date with each other. For this reason, I didn't find it 'a slightly inconvenient problem'. The existence of a decent debugger/tracer makes a significant difference to the utility of a language; particularly, I think, a lazy language, because the cryptic evaluation order makes print statements in the code less informative. I recently gave a presentation about haskell at my work, and had to significantly tone-down the strength of my recommendation of it because I find haskell code so difficult to debug. At work we use windows (as I do at home), and despite Neil Mitchell's efforts, not enough of the hat tools have been converted to windows to make it worth using them. I didn't find the instructions for using hat via cygwin sufficient for someone with my low level of expertise. It is my personal belief that the lack of a powerful debugger/tracer that works 'straight out of the box', is the major constraint preventing the widespread adoption of haskell. I have no idea how difficult it would be to make hat work on all valid haskell98 code 'out of the box', on windows as well as unix, so I can't criticize anyone for the fact that it doesn't. However, I am strongly opposed the point of view that, for whatever reason, this doesn't really matter. Hat is free to use, and because of this, I feel I shouldn't be whining about problems with it. However, I feel that descriptions of Hat, for example in the communities and activities report, or on the hat website, should contain prominent and frank statements about its current limitations. I feel this is only fair to the readers who are otherwise likely to waste a significant amount of time on hat before they get disillusioned. Tom. From ndmitchell at gmail.com Sat Dec 9 09:36:57 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Dec 9 09:34:52 2006 Subject: [Hat] Program Compiles With GHC 6.6 but not Hat In-Reply-To: <6.0.1.1.0.20061202212514.0219cd68@mail.firenet.uk.net> References: <6.0.1.1.0.20061202212514.0219cd68@mail.firenet.uk.net> Message-ID: <404396ef0612090636m46b881d9l9548cca1b0ba9675@mail.gmail.com> Hi Tom, > These assessments depend very much on your point of view. With infinite resources I'm sure all these things would get fixed. Unfortunately infinite resources is not something Hat has... Without infinite resources, you have to prioritise. If Hat was being developed by a commercial company, I am sure more focus would be directed towards graphical tools and fixing the small issues to give something more polished. Unfortunately in academia those things won't make a paper, win any research grants, and are harder to get done. That fact that the goal posts for Haskell keep getting moved also makes this a much harder task! > and > there were 3 different idiosyncrasies of hat which gave problems. The > defaulting idiosyncrasy was one of them. Please list all 3 of them. > I imagine that most people that > try hat find it won't understand their code, and give up on it > immediately. I am therefore skeptical that this is hardly ever a problem > for people even if you 'hardly ever come across' it. I don't use Hat because every time I've tried to use it I get to the point where it's easier to insert trace calls than work round whatever particular reason Hat is failing for now. > I recently gave a presentation about haskell at my work, and had to > significantly tone-down the strength of my recommendation of it because I > find haskell code so difficult to debug. At work we use windows (as I do > at home), and despite Neil Mitchell's efforts, not enough of the hat tools > have been converted to windows to make it worth using them. If the Hat tools all worked on Windows, would that change your assessment of Hat? Would that convince you to use it? Because I don't use Hat, that makes me less inclined to spend too much effort porting the tools. Personally, even with all the tools available on Windows, I still wouldn't use Hat because of the unreliability of generating traces. > I didn't find > the instructions for using hat via cygwin sufficient for someone with my > low level of expertise. If debugging Haskell is to painful as to have to use cygwin, just rewrite your application in C# and use the great debugger included with Visual Studio :) > I have no idea how difficult it would be to make hat work on all valid > haskell98 code 'out of the box', on windows as well as unix, so I can't > criticize anyone for the fact that it doesn't. However, I am strongly > opposed the point of view that, for whatever reason, this doesn't really > matter. I have a plan to get this going using Yhc.Core. The problem would be that its a different version of the code, based on your original, but the user would have to brain hop between their original code and the code being debugged. Having worked with Yhc.Core plenty, my brain does this hopping automatically, but I suspect that it won't be fun for other people - but should be very reliable. Thanks Neil From colin at cs.york.ac.uk Sat Dec 9 10:40:02 2006 From: colin at cs.york.ac.uk (Colin Runciman) Date: Sat Dec 9 10:50:48 2006 Subject: [Hat] Program Compiles With GHC 6.6 but not Hat In-Reply-To: <6.0.1.1.0.20061202212514.0219cd68@mail.firenet.uk.net> References: <6.0.1.1.0.20061202212514.0219cd68@mail.firenet.uk.net> Message-ID: <457AD8D2.2090507@cs.york.ac.uk> Tom, Thanks for reporting your Hat experience, albeit a negative one. For those of us who use Hat regularly, and get the results we need, it is easy to forget the problems that new users may face. > The only proper program I have tried to use hat on required rewriting > to get hat to understand it. The program was only ~2k lines of code, > and there were 3 different idiosyncrasies of hat which gave problems. > The defaulting idiosyncrasy was one of them. It would be very helpful to know what the other problems were, apart from default numeric types. > These three idiosyncrasies, if I recall correctly, required ~20 > unwanted changes in my code, so I made a hat version of my code with > these alterations, but it is very difficult to keep two parallel > versions of a piece of code up to date with each other. For this > reason, I didn't find it 'a slightly inconvenient problem'. I quite agree that maintaining parallel versions is a pain, and should be unnecessary. > It is my personal belief that the lack of a powerful debugger/tracer > that works 'straight out of the box', is the major constraint > preventing the widespread adoption of haskell. You may well be right. Those of us who developed Hat had the aim that it would indeed work 'straight out of the box' for any Haskell 98 program. It is clear that we have fallen short of that aim, and it is useful to have reports such as yours. We'd like to fix whatever problems prevent people from using Hat on their Haskell 98 programs. > Hat is free to use, and because of this, I feel I shouldn't be whining > about problems with it. However, I feel that descriptions of Hat, for > example in the communities and activities report, or on the hat > website, should contain prominent and frank statements about its > current limitations. As I say, your report of problems is welcome and helpful. As to the need for prominent and frank statements about limitations, these are already provided. One link from the main Hat web page is to the Bugs and Limitations page. But if you think there are further limitations that should be added to the list, do tell us. Regards Colin Runciman From tfp2007 at shu.edu Sun Dec 31 09:54:24 2006 From: tfp2007 at shu.edu (TFP 2007) Date: Sun Dec 31 09:51:08 2006 Subject: [Hat] Second Call for Papers: TFP 2007, New York, USA Message-ID: CALL FOR PAPERS Trends in Functional Programming 2007 New York, USA April 2-4, 2007 http://cs.shu.edu/tfp2007/ The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming languages, focusing on providing a broad view of current and future trends in Functional Programming. It aspires to be a lively environment for presenting the latest research results through acceptance by extended abstracts. A formal post-symposium refereeing process then selects the best articles presented at the symposium for publication in a high-profile volume. TFP 2007 is co-hosted by Seton Hall University and The City College of New York (CCNY) and will be held in New York, USA, April 2-4, 2007 at the CCNY campus. The TFP symposium is the successor to the successful series of Scottish Functional Programming Workshops. Previous TFP symposia were held in Edinburgh, Scotland in 2003 (co-located with IFL), in Munich, Germany in 2004, in Tallinn, Estonia in 2005 (co-located with ICFP and GPCE), and in Nottingham, UK in 2006 (co-located with Types). For further general information about TFP please see the TFP homepage at http://cs.shu.edu/tfp2007/ . SCOPE OF THE SYMPOSIUM The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research Articles leading-edge, previously unpublished research work Position Articles on what new trends should or should not be Project Articles descriptions of recently started new projects Evaluation Articles what lessons can be drawn from a finished project Overview Articles summarizing work with respect to a trendy subject Articles must be original and not submitted for simultaneous publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or more experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Articles on the following subject areas are particularly welcomed: o Dependently Typed Functional Programming o Validation and Verification of Functional Programs o Debugging for Functional Languages o Functional Programming and Security o Functional Programming and Mobility o Functional Programming to Animate/Prototype/Implement Systems from Formal or Semi-Formal Specifications o Functional Languages for Telecommunications Applications o Functional Languages for Embedded Systems o Functional Programming Applied to Global Computing o Functional GRIDs o Functional Programming Ideas in Imperative or Object-Oriented Settings (and the converse) o Interoperability with Imperative Programming Languages o Novel Memory Management Techniques o Parallel/Concurrent Functional Languages o Program Transformation Techniques o Empirical Performance Studies o Abstract/Virtual Machines and Compilers for Functional Languages o New Implementation Strategies o any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2007 program chair, Marco T. Morazan, at tfp2007@shu.edu. BEST STUDENT PAPER AWARD TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A prize for the best student paper is awarded each year. SUBMISSION AND DRAFT PROCEEDINGS Acceptance of articles for presentation at the symposium is based on the review of extended abstracts (6 to 10 pages in length) by the program committee. Accepted abstracts are to be completed to full papers before the symposium for publication in the draft proceedings and on-line. The submission must clearly indicate to which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate whether the main author or authors are research students. Formatting details can be found at the TFP 2007 website. Submission procedures will be posted on the TFP 2007 website as the submission deadline is reached. The papers in the draft proceedings will also be made available on-line under the following conditions, with which all authors are asked to agree: The documents distributed by this server have been provided by the contributing authors as a means to ensure timely dissemination of scholarly and technical work on a noncommercial basis. Copyright and all rights therein are maintained by the authors or by other copyright holders, notwithstanding that they have offered their works here electronically. It is understood that all persons copying this information will adhere to the terms and constraints invoked by each author's copyright. These works may not be reposted without the explicit permission of the copyright holder. POST-SYMPOSIUM REFEREEING AND PUBLICATION In addition to the draft symposium proceedings, we intend to continue the TFP tradition of publishing a high-quality subset of contributions in the Intellect series on Trends in Functional Programming. All TFP authors will be invited to submit revised papers after the symposium. These will be refereed using normal conference standards and a subset of the best papers, over all categories, will be selected for publication. Papers will be judged on their contribution to the research area with appropriate criteria applied to each category of paper. Student papers will be given extra feedback by the Program Committee in order to assist those unfamiliar with the publication process. IMPORTANT DATES Abstract Submission: February 1, 2007 Notification of Acceptance: February 20, 2007 Registration Deadline: March 2, 2007 Camera Ready Full Paper Due: March 9, 2007 TFP Symposium: April 2-4, 2007 PROGRAMME COMMITTEE John Clements California Polytechnic State University, USA Marko van Eekelen Radboud Universiteit Nijmegen, The Netherlands Benjamin Goldberg New York University, USA Kevin Hammond University of St. Andrews, UK Patricia Johann Rutgers University, USA Hans-Wolfgang Loidl Ludwig-Maximilians Universit?t M?nchen, Germany Rita Loogen Philipps-Universit?t Marburg, Germany Greg Michaelson Heriot-Watt University, UK Marco T. Moraz?n (Chair) Seton Hall University, USA Henrik Nilsson University of Nottingham, UK Chris Okasaki United States Military Academy at West Point, USA Rex Page University of Oklahoma, USA Ricardo Pena Universidad Complutense de Madrid, Spain Benjamin C. Pierce University of Pennsylvania, USA John Reppy University of Chicago, USA Ulrik P. Schultz University of Southern Denmark, Denmark Clara Segura Universidad Complutense de Madrid, Spain Jocelyn S?rot Universit? Blaise Pascal, France Zhong Shao Yale University, USA Olin Shivers Georgia Institute of Technology, USA Phil Trinder Heriot-Watt University, UK David Walker Princeton University, USA ORGANIZATION Symposium Chair: Henrik Nilsson, University of Nottingham, UK Programme Chair: Marco T. Morazan, Seton Hall University, USA Treasurer: Greg Michaelson, Heriot-Watt University, UK Local Arrangements: Marco T. Morazan, Seton Hall University, USA SPONSORS The Department of Mathematics and Computer Science, Seton Hall University The Department of Computer Science, The City College of New York The Center for Algorithms and Interactive Scientific Software of The City College of New York The Grove School of Engineering of The City College of New York We are actively looking for additional TFP sponsors, who may, for example, help to subsidise attendance by research students. If you or your organisation might be willing to sponsor TFP, or if you know someone who might be willing to do so, please do not hesitate to contact the Program Chair, Marco T. Morazan, or the Symposium Chair, Henrik Nilsson. Your students will be grateful! ************************************************************************************ Dr. Marco T. Morazan TFP 2007 Program Committee Chair http://cs.shu.edu/tfp2007/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/hat/attachments/20061231/af607d03/attachment-0001.htm