Re: LAST CALL to comment on the Appicative/Monad Proposal
Hi, On 12/18/2018 02:52 PM, Cale Gibbard wrote: Secondarily, it's a bit hard to describe why this is, but I personally find it a bit obnoxious whenever someone uses 'pure' rather than 'return' if the functor is known to be an instance of Monad and the generality isn't needed. It's a kind of signal that the code we're writing is (and perhaps needs to be) Applicative-polymorphic, or that we lack a Monad instance. So when I see it, I'm forced to consider for a moment why that might be, and whether I've understood the context incorrectly (and if it's not the case, that's sort of irritating). So when I see a suggestion to remove 'return' altogether it's sort of like "let's make everything mildly annoying to read forever" (by forcing this thought about exactly how general the code is, and making it slightly harder to guess the types at a glance). I personally fully agree with this sentiment: I do find the use of "pure" vs. "return" to be a very useful signal to the reader. Moreover, while there is little risk of confusion when arrow syntax is used, looking just at names, the fact is that the use of the distinct "returnA" also sends a similar signal to the reader, and consequently there is a certain consistency in distinct names being used for the three different computational notions for which (variations of) do-notation is provided. Best, /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: LAST CALL to comment on the Applicative/Monad Proposal
Hi, Philippa wrote: > It's a lot easier to estimate ecosystem impact given a switch that'll > find all the resulting errors and give everyone a chance to fail any > tests. Yes, a good point. But just to be clear, the impact of some changes go well beyond what can be assessed by looking at impact on an existing code base alone. And that is one reason for why MRP has been, and remains, so controversial. Best, /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: LAST CALL to comment on the Applicative/Monad Proposal
Hi all, Well, I am in favour of discussing AMP and MRP separately because: a) As far as I am aware, there is no compelling *technical* reason for not doing so. b) On balance, this is the path most likely to result in some progress on this issue. Of course, if there *is* a fundamental technical reason for why the AMP, MFP, and MRP all *must* be discussed together, then please put this forward. As to the underlying issue, I don't agree that AMP on its own somehow is not "clean". But of course, design is something where reasonable people may choose to disagree. (Which in itself strongly suggests that it makes sense to strive to consider technically independent proposals separately.) The rationale for my position is: a) The remaining legacy issues raised by MRP significantly outweighs any technical benefits. b) Keeping "return" as a monadic *method* would in principle (through a minor language extension that has been proposed separately for different reasons) allow both Functor and Applicative instances to be defined in terms of a Monad instance. The latter is really useful in a situation where one genuinely only cares about the monad, makes perfect sense mathematically of course, and would go a long way towards alleviating the genuine difficulties of teaching monads that AMP did bring about, as reported by a number of *very* experienced educators. But clearly this is a separate discussion. Which is why AMP, MRP, and MFP should be considered separately. One high-level perspective on this is the well-established possibility in Haskell of defining an instance of a class by only giving definitions of a subset of its methods where methods are interdefinable. Many methods in the Functor/Monad/Applicative hierarchy are similarly interdefinable, but spread over more than one class. But in principle, choosing to define e.g. "fmap" in terms of the monadic methods, or "pure" in terms of "return", or vice versa for that matter, is not very different from the choice between defining a monad in terms of bind or join. Best, /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: The first proposal has been merged
Hi, On 11/27/2018 03:28 AM, Mario Blažević wrote: Break out the champagne, because the first Haskell 2020 proposal has been fully merged [1]. Thank you, Mario! /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Quo vadis?
Hi, On 10/05/2018 01:20 PM, Mario Blažević wrote: I hereby propose we formally disband the present Haskell 2020 committee. Our performance has been so dismal It has. And I should apologise in particular: I've just had far less time than I thought over the past year for a variety of reasons. that I feel this is the only course of action that gives Haskell 2020 any chance of fruition. A new committee could then be formed with some more dedicated membership. I'm less convinced about that, though. I believe those who signed up for H2020 actually are people who believe in the value of an updated standard and has core expertise to make it happen. I can't see how giving up and forming a new group would speed things up or even increase the chance of success. Instead, what about focusing on identifying a couple of things that absolutely would have to be in H2020 to make a new standard worthwhile, like multi-parameter type classes, possibly GADTs, then figure out what else is needed to support that (like what Anthony Clayden sketched), and with that as a basis, find out exactly what technical problems, if any, are hindering progress? If this could be neatly summarized, then we'd actually be in a position to make some progress. /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Shall the Haskell Report remain in LaTeX?
Yes, I see no benefits moving from LaTeX. So remain LaTeX. /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
New Haskell Prime Chair
Dear Haskell Primers, At the Haskell Prime Meeting at ICFP last week, it was agreed that I will take over as Chair of the Haskell Prime committee from Herbert Valerio Riedel for initially one year with the aim of facilitating and co-ordinating the language revision process. This will allow Herbert to focus on supporting the editorial aspects of the report by improving the LaTeX code of the existing report and automating publication of report drafts and changes to improve overall transparency and facilitate feedback from the wider community. All the best, /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Remove eq and show from num class
On 09/08/2017 12:45 AM, Carter Schonwald wrote: please say yes or no. its quite easy with email . i'm not going to write that little proposal if folks wont accept it :) I'd love to see those constraints go. But it is important that the full ramifications are clearly articulated. Best, /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Haskell Prime Meeting at ICFP (Was: Whose gonna be at icfp?)
Hi all, Reminder: Haskell' is meeting lunchtime today, so shortly after 12:30. We now, thank to Jeremy Gibbons, also have a room: C5. So grab lunch and then go to C5. Best, /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Haskell Prime Meeting at ICFP (Was: Whose gonna be at icfp?)
Hi Haskell Primers, We have now agreed Thursday Lunch (1st Day of Haskell Symposium) for the Haskell Prime coordination meeting. We agreed to meet towards the far end of the Foyer, past the café viewed from the main lecture theatre L1. All the best, /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Whose gonna be at icfp?
Hi, On 09/05/2017 12:54 PM, Mario Blazevic wrote: In that case I suggest we meet during the coffee break and decide when we really meet. OK. Should we try to find each other at 16:10, then? Outside L1, the ICFP lecture theatre? /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Whose gonna be at icfp?
Hi, On 09/05/2017 10:27 AM, Mario Blazevic wrote: I thought John said 4:40 today. You missed Andres Löh. Must have missed that. Works for me! /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Whose gonna be at icfp?
Hi! > We should coord a committee catch-up at icfp. Seems that at least a few people are/or will be here in Oxford. I counted: Carter Schonwald John Wiegley Mario Blazević Lennart is also here, and Iavor is or will be here. Anyone else? It would make most sense to try to time a meeting around the Haskell Symposium, I think. A lunch meeting either Thursday or Friday could be an option (but might be a bit rushed) or trying to meet up Thursday evening, probably after the Industry Reception (that is scheduled to end 20:30). What do you think? /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Whose gonna be at icfp?
I will attend ICFP and the Haskell symposium. Meeting up is a very good idea! Best, /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
[Haskell] PhD studentships at FP lab, Nottingham
The School of Computer Science in Nottingham is advertising 10 fully-funded PhD studentships. Applicants in the area of the Functional Programming lab (fp.cs.nott.ac.uk) are encouraged! If you are interested in applying, please contact a potential supervisor in the FP lab prior to submitting your application: Thorsten Altenkirch - constructive logic, proof assistants, (homotopy) type theory, category theory, lambda calculus, quantum computing. Venanzio Capretta - type theory, mathematical logic, corecursive structures, proof assistants, dependently-typed programming. Henrik Nilsson - functional reactive programming, modelling and simulation languages, domain-specific languages, generalized notions of computation Graham Hutton - program construction and verification, category theory, recursion operators, coinductive types. See http://www.nottingham.ac.uk/jobs/currentvacancies/ref/SCI1674 for details. Closing date: Sunday, 22nd January 2017 -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Re: Proposal: ArgumentDo
Hi all, On 07/09/2016 08:09 AM, C Maeder wrote: The asymmetry that you mention is already apparent for (Haskell98) infix expressions, i.e. when "composing" lambda- or if-expression: (if c then f else g) . \ x -> h x Parentheses around the last argument of "." do not matter, but parentheses around the first argument make a real difference But that has to do with how grammatical ambiguity related to in this case "if" and "lambda" are resolved by letting the constructs extend as far as possible to the right. This the standard way of resolving that kind of ambiguity across a very wide range of programming languages and parsing tools (e.g. preferring shift over reduce in an LR parser). (And also in principle how lexical ambiguities are typically resolved, sometimes referred to as the "maximal munch rule".) In contrast, the present proposal suggests treating different argument positions in grammatically different ways (different non-terminals). As far as I know, that is unprecedented. And in any case, it manifestly complicates the grammar (more non-terminals) and as a consequence adds another grammatical hurdle to learning the language. I think we often tend to forget just how exotic Haskell syntax can be to the uninitiated. Which is the vast majority of the rest of the programmer world as well as beginners. Only the other week I gave a presentation to a group of highly skilled developers at a tech-savvy London-based company. The emphasis of the talk was not at all on Haskell as such, but small Haskell fragments did feature here and there, which I (naively) thought would be mostly self explanatory. Well, let's just say I was wrong. Now, we can't make Haskell syntax less exotic (not that I'd advocate that: I think basic Haskell syntax for the most part strikes a pretty good balance on a number of counts), but we can certainly avoid making it even more complicated and exotic. Which the present proposal would, in my opinion. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Proposal: ArgumentDo
Hi all, Joachim Breitner wrote: > Am Freitag, den 08.07.2016, 13:09 +0200 schrieb Sven Panne: > > I don't think so: https://ghc.haskell.org/trac/ghc > /wiki/ArgumentDo#Bl > [...] > Where is the outer set of parenthesis coming from? > > This is all not related to the ArgumentDo notation. Note that [...] The very fact that that experts can't easily agree on how a small Haskell fragment is parsed to me just confirms that Haskell already is a syntactically very cumbersome language. The present proposal just makes matters worse. For that reason alone, I don't find it compelling at all. (So -1 from me, then.) I will not repeat the many other strong arguments against that has been made. But I must say I don't find the use cases as documented on the associated web page compelling at all. Maybe there is a tacit desire to be able to pretend functions are keywords for various creative uses in supporting EDSLs and such. But for that to be truly useful, one need to support groups of related keywords. Something like Agda's mixfix syntax springs to mind. But this proposal does not come close, so the benefits are minimal and the drawbacks large. As a final point, the inherent asymmetry of the proposal (the last argument position is special as, for certain kinds of expressions, parentheses may be omitted there but not elsewhere) is also deeply unsettling. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Are there GHC extensions we'd like to incorporate wholesale?
Hi all, > For example, much as I love GADTs and would be all for them being > added in some future language report, I do not feel they should be > added this time around. (Though I emphatically and wholeheartedly > support adding GADTSyntax.) In my opinion, GADTs is one of the most important extensions of the Haskell type system over the past decade and definitely a sweet spot in the design space in terms of power vs. complexity, at least from a user perspective. I eagerly await Herbert's summary of of most used extensions (which I think will be an extremely important input when deciding how to go forward in general), but my definite impression is that GADTs (and not just GADT syntax) are used a lot. Point taken about the difficulty of specifying GADT type inference declaratively. But as long as there at least is a way to standardise inference that works, and from what Simon said there is, I do think aiming to make GADTs an official part of Haskell 2020 should be a priority. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Chairship / responsibility
Hi all, > It was my understanding that Herbert would be the chair when I asked > to be on the committee, and the fact that this question was already > answer was a factor in my decision to try to help. I agree completely with this. And thanks to Herbert for now having completed the first step of the reboot. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
[Haskell] Reminder: Call for papers EOOLT 2016
Dear all, EOOLT 2016, the 7th Workshop on Equation-Based Object-Oriented Modeling Languages and Tools, may be of interest to people working on e.g. functional reactive programming or more generally aspects of embedded declarative domain-specific languages. EOOLT 2016 is organised in cooperation with ACM SIGPPLAN and the submission deadline is 25 January. The CFP is enclosed below and full information is available here: http://www.eoolt.org/2016 All the best, /Henrik EOOLT 2016 April 18, Milano, Italy 7th International Workshop on Equation-Based Object-Oriented Modeling Languages and Tools Politecnico di Milano, Milano, Italy Deadline for paper submission: January 25, 2016 GENERAL CHAIR Francesco Casella Politecnico di Milano (DEIB) PROGRAM CHAIR Dirk Zimmer German Aerospace Center (DLR) The EOOLT workshop addresses the current state of the art of equation-based object-oriented (EOO) modeling languages and tools. Integration of and comparison with related approaches and languages, such as actor-oriented, synchronous, and domain specific languages, are of particular interest. Contributions to this workshop focus on methodological aspects and describe new solutions for the design and use of equation-based languages. In addition to full contributions, shorter work-in-progress paper are welcome, offering an opportunity to discuss current approaches within the community. Typical themes of the EOOLT workshop range from language design via modeling aspects to simulation code: • Design aspects of equation-based languages and their formal semantics • Relation to other languages such as functional reactive programming (FRP) or synchronous languages • Verification, type systems, and early static checking • Discrete-event and hybrid system modeling • Acausality/non-causality and its role in model reusability • Multi-resolution/multi-scale modeling using EOO languages • Model-driven development related to EOO languages • Equation-based modeling in the frame of system engineering • Reflection and meta-programming • Environments for modeling, simulation and debugging • Mathematical formalisms for simulation semantics • Code generation for real-time systems, embedded system, multi-core platforms, and distributed systems • Tools for analyzing or optimizing equation-based models -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] CFP: EOOLT 2016
Dear Haskellers, I would like to draw your attention to EOOLT 2016: the 7th International Workshop on Equation-Based Object-Oriented Languages and Tools. EOOLT may be of interest to anyone interested in applying functional/declarative programming to modelling and simulation of physical systems, for example through the route of embedded domain-specific languages. It is particularly relevant for people with an interest in Functional Reactive Programming (FRP) or the synchronous dataflow paradigm more generally. EOOLT 2016 will take place in Milano, Italy, on 18 April 2016, and the submission deadline is 25 January. The call for papers can be found here: http://eoolt.org/2016/index.php?id=cfp and general information about EOOLT 2016 here: http://eoolt.org/2016/ All the best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] PhD studentships at the Functional Programming Lab in Nottingham
Dear Haskellers, The School of Computer Science in Nottingham is advertising 10 fully- funded PhD studentships. Applicants in the area of the Functional Programming lab (fp.cs.nott.ac.uk) are highly encouraged! If you are interested in applying, please contact a potential supervisor in the FP lab prior to submitting your application: Thorsten Altenkirch - constructive logic, proof assistants, homotopy type theory, category theory, lambda calculus. Venanzio Capretta - type theory, mathematical logic, corecursive structures, proof assistants, dependently-typed programming. Graham Hutton - program construction and verification, category theory, recursion operators, coinductive types. Henrik Nilsson - functional reactive programming, modelling and simulation, probabilistic languages, and design and implementation of declarative domain-specific languages in general. See below for full details. All the best, /Henrik +---+ 10 Fully-Funded PhD Studentships School of Computer Science University of Nottingham, UK http://nottingham.ac.uk/jobs/currentvacancies/ref/SCI1498 Applications are invited for up to ten fully-funded PhD studentships in the School of Computer Science at the University of Nottingham, starting on 1st October 2016. The topics for the studentships are open, but should relate to the interests of one of the School’s research groups: Agents Lab; Automated Scheduling, Optimisation and Planning; Computer Vision Lab; Functional Programming Lab; Intelligent Modelling and Analysis; Mixed Reality Lab and in the area of Data Science. The studentships are for three years and include a stipend of £14,507 per year and tuition fees, and are available to students of any nationality. Applicants are normally expected to have a first-class Masters or Bachelors degree in Computer Science or a related discipline, and must obtain the support of a potential supervisor in the School prior to submitting their application. Initial contact with supervisors should be made at least two weeks prior to the closing date for applications. Informal enquiries may be addressed to christine.fletc...@nottingham.ac.uk. To apply, please submit the following items by email to the above address: (1) a brief covering letter that describes your reasons for wishing to pursue a PhD, your proposed research area and topic, and the name of a potential supervisor; (2) a copy of your CV, including your actual or expected degree class(es), and results of all University examinations; (3) an example of your technical writing, such as a project report or dissertation; (4) contact details for two academic referees. Closing date for applications: 19th February 2016 +---+ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Re: Breaking Changes and Long Term Support Haskell
> I think voting to decide these kind of issues a terrible idea; we > might as well throw dice. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Breaking Changes and Long Term Support Haskell
Hi all, Jeremy wrote: > There seems to be a fair amount of friction between those who want to > introduce new features or fix significant historical warts in the base > libraries - even if this requires breaking changes - and those who > insist on no significant breaking changes in new releases, regardless > of the reason or how much warning was given. With respect, and without commenting on the merits of the proposal that is then outlined (Long-Term Support Haskell), I don't think this is an accurate description of the two main positions in the debate at all. Most of those who have argued against MRP, for example, have made it very clear that they are not at all against any breaking change. But they oppose breaking changes to Haskell itself, including central libraries, as defined by the Haskell report, unless the benefits are very compelling indeed. Speaking for myself, I have had to clarify this position a number of times now, as there has been a tendency by the some proponents of the proposed changes to suggest that those who disagree are against all changes, the long term implication being that Haskell would "stagnate and die". And in the light of the above, I felt compelled to clarify this position again. It's not about no more changes ever. It is about ensuring that changes are truly worthwhile and have wide support. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
Hi all, Geoffrey Mainland wrote; > What worries me most is that we have started to see very valuable > members of our community publicly state that they are reducing their > community involvement. That worries me too. A lot. To quote myself from an earlier e-mail in this thread: > Therefore, please let us defer further discussion and > ultimate decision on MRP to the resurrected > HaskellPrime committee, which is where it properly > belongs. Otherwise, the Haskell community itself might > be one of the things that MRP breaks. Geoffrey further wrote: > Proposal 3: A decision regarding any proposal that significantly > affects backwards compatibility is within the purview of the Haskell > Prime Committee, not the Core Libraries Committee. I thus definitely support this, at least for anything related to the libraries covered by the Haskell report. Indeed, I strongly suspect that many people who did not actively follow the libraries discussions did so because they simply did not think that changes to the central libraries as defined in the Haskell report, at least not breaking changes, were in the remit of the libraries committee, and were happy to leave discussions on any other libraries to the users of those libraries. And as a consequence they were taken by surprise by AMP etc. So before breaking anything more, that being code, research papers, books, what people have learned, or even the community itself, it is time to very carefully think about what the appropriate processes should be for going forward. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
Dear all, Executive Summary: Please let us defer further discussion and ultimate decision on MRP to the resurrected HaskellPrime committee While we can discuss the extent of additional breakage MRP would cause, the fact remains it is a further breaking change. A survey of breakage to books as Herbert did is certainly valuable (thanks!), but much breakage will (effectively) remain unquantifiable. It is also clear from the discussions over the last couple of weeks, on the Haskell libraries list as well as various other forums and social media, that MRP is highly contentions. This begs two questions: 1. Is the Haskell Libraries list and informal voting process really an appropriate, or even acceptable, way to adopt such far-reaching changes to what effectively amounts to Haskell itself? 2. Why the hurry to push MRP through? As to question 1, to Graham Hutton's and my knowledge, the libraries list and its voting process was originally set up for 3rd-party libraries in fptools. It seems to have experienced some form of "mission creep" since. Maybe that is understandable given that there was no obvious alternative as HaskellPrime has been defunct for a fair few years. But, as has been pointed out in a number of postings, a lot of people with very valuable perspectives are also very busy, and thus likely to miss a short discussion period (as has happened in the past in relation to the Burning the Bridges proposal) and also have very little time for engaging in long and complicated e-mail discussions that, from their perspective, happen at a completely random point in time and for which they thus have not had a chance to set aside time even if they wanted to participate. Just as one data point, AMP etc. mostly passed Graham and me by simply because a) we were too busy to notice and b) we simply didn't think there was a mandate for such massive overhauls outside of a process like HaskellPrime. And we are demonstrably not alone. This brings us to question 2. Now that HaskellPrime is being resurrected, why the hurry to push MRP through? Surely HaskellPrime is the forum where breaking changes like MRP should be discussed, allowing as much time as is necessary and allowing for an as wide range of perspectives as possible to properly be taken into account? The need to "field test" MRP prior to discussing it in HaskellPrime has been mentioned. Graham and I are very sceptical. In the past, at least in the past leading up to Haskell 2010 or so, the community at large was not roped in as involuntary field testers. If MRP is pushed through now, with a resurrection of HaskellPrime being imminent, Graham and I strongly believe that risks coming across to a very large part of the Haskell community as preempting proper process by facing the new HaskellPrime committee with (yet another) fait accompli. Therefore, please let us defer further discussion and ultimate decision on MRP to the resurrected HaskellPrime committee, which is where it properly belongs. Otherwise, the Haskell community itself might be one of the things that MRP breaks. Best regards, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
[Haskell] FARM 2015: 2nd Call For Papers
Dear all, The workshop on Functional Art, Music, Modelling and Design, co-located with ICFP 2015 in Vancouver, may be of interest to some of you. The 2nd call for papers is enclosed; deadline 17 May. Any help spreading the CFP to colleagues and friends who might be interested would be much appreciated. Thanks! /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. 2nd CFP FARM 2015 3rd ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design Vancouver, Canada, 5 September, 2015 affiliated with ICFP 2015 Full Paper and Demo Abstract submission Deadline: 17 May The ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design (FARM) gathers together people who are harnessing functional techniques in the pursuit of creativity and expression. Functional Programming has emerged as a mainstream software development paradigm, and its artistic and creative use is booming. A growing number of software toolkits, frameworks and environments for art, music and design now employ functional programming languages and techniques. FARM is a forum for exploration and critical evaluation of these developments, for example to consider potential benefits of greater consistency, tersity, and closer mapping to a problem domain. FARM encourages submissions from across art, craft and design, including textiles, visual art, music, 3D sculpture, animation, GUIs, video games, 3D printing and architectural models, choreography, poetry, and even VLSI layouts, GPU configurations, or mechanical engineering designs. The language used need not be purely functional (“mostly functional” is fine), and may be manifested as a domain specific language or tool. Theoretical foundations, language design, implementation issues, and applications in industry or the arts are all within the scope of the workshop. Submissions are invited in two categories: * Full papers 5 to 12 pages using the ACM SIGPLAN template. FARM 2015 is an interdisciplinary conference, so a wide range of approaches are encouraged and we recognize that the appropriate length of a paper may vary considerably depending on the approach. However, all submissions must propose an original contribution to the FARM theme, cite relevant previous work, and apply appropriate research methods. * Demo abstracts Demo abstracts should describe the demonstration and its context, connecting it with the themes of FARM. A demo could be in the form of a short (10-20 minute) tutorial, presentation of work-in-progress, an exhibition of some work, or even a performance. Abstracts should be no longer than 2 pages, using the ACM SIGPLAN template and will be subject to a light-touch peer review. If you have any questions about what type of contributions that might be suitable, or anything else regarding submission or the workshop itself, please contact the organisers at: farm-2...@easychair.org KEY DATES: Full Paper and Demo Abstract submission Deadline: 17 May Author Notification:26 June Camera Ready: 19 July Workshop: 5 September SUBMISSION All papers and demo abstracts must be in portable document format (PDF), using the ACM SIGPLAN style guidelines. The text should be in a 9-point font in two columns. The submission itself will be via EasyChair: https://easychair.org/conferences/?conf=farm2015 PUBLICATION Accepted papers will be included in the formal proceedings published by ACM Press and will also be made available through the the ACM Digital Library; see http://authors.acm.org/main.cfm for information on the options available to authors. Authors are encouraged to submit auxiliary material for publication along with their paper (source code, data, videos, images, etc.); authors retain all rights
[Haskell] Fwd: FARM 2015 Workshop - 1st call for papers and demos
Dear Haskell interested, Please find enclosed the call for paper for FARM that may be of interest to many of you. Best, /Henrik Original Message Subject: FARM 2015 Workshop - 1st call for papers and demos Date: Thu, 12 Feb 2015 08:30:04 + From: FARM 2015 farm-2...@easychair.org To: Henrik Nilsson n...@cs.nott.ac.uk FARM 2015 3rd ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design Vancouver, Canada, 5 September, 2015 The ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design (FARM) gathers together people who are harnessing functional techniques in the pursuit of creativity and expression. Functional Programming has emerged as a mainstream software development paradigm, and its artistic and creative use is booming. A growing number of software toolkits, frameworks and environments for art, music and design now employ functional programming languages and techniques. FARM is a forum for exploration and critical evaluation of these developments, for example to consider potential benefits of greater consistency, tersity, and closer mapping to a problem domain. FARM encourages submissions from across art, craft and design, including textiles, visual art, music, 3D sculpture, animation, GUIs, video games, 3D printing and architectural models, choreography, poetry, and even VLSI layouts, GPU configurations, or mechanical engineering designs. The language used need not be purely functional (“mostly functional” is fine), and may be manifested as a domain specific language or tool. Theoretical foundations, language design, implementation issues, and applications in industry or the arts are all within the scope of the workshop. Submissions are invited in two categories: * Full papers 5 to 12 pages using the ACM SIGPLAN template. FARM 2015 is an interdisciplinary conference, so a wide range of approaches are encouraged and we recognize that the appropriate length of a paper may vary considerably depending on the approach. However, all submissions must propose an original contribution to the FARM theme, cite relevant previous work, and apply appropriate research methods. * Demo abstracts Demo abstracts should describe the demonstration and its context, connecting it with the themes of FARM. A demo could be in the form of a short (10-20 minute) tutorial, presentation of work-in-progress, an exhibition of some work, or even a performance. Abstracts should be no longer than 2 pages, using the ACM SIGPLAN template and will be subject to a light-touch peer review. If you have any questions about what type of contributions that might be suitable, or anything else regarding submission or the workshop itself, please contact the organisers at: farm-2...@easychair.org KEY DATES: Full Paper and Demo Abstract submission Deadline: 17 May Author Notification:26 June Camera Ready: 19 July Workshop: 5 September SUBMISSION All papers and demo abstracts must be in portable document format (PDF), using the ACM SIGPLAN style guidelines. The text should be in a 9-point font in two columns. The submission itself will be via EasyChair: https://easychair.org/conferences/?conf=farm2015 PUBLICATION Accepted papers will be included in the formal proceedings published by ACM Press and will also be made available through the the ACM Digital Library; see http://authors.acm.org/main.cfm for information on the options available to authors. Authors are encouraged to submit auxiliary material for publication along with their paper (source code, data, videos, images, etc.); authors retain all rights to the auxiliary material. WORKSHOP ORGANISATION Workshop Chair: Henrik Nilsson, University of Nottingham Program Chair: David Janin, University of Bordeaux Publicity Chair: Samuel Aaron, University of Cambridge Program Committee: Samuel Aaron, University of Cambridge Jean Bresson, IRCAM Paris David Broman, KTH and UC Berkeley Paul Hudak, Yale University David Janin (chair), University of Bordeaux Anton Kholomiov, Orffeus instrumental ensemble Moscow Alex Mclean, University of Leeds Carin Meier, Outpace Systems Henrik Nilsson, University of Nottingham Yann Orlarey, GRAME Lyon Donya Quick, Yale University Shigeki Sagayama, Meiji University Chung-chieh Shan, Indiana University Michael Sperber, Active Group GmbH Bodil Stokke, FutureAdLabs For further details, see the FARM website: http://functional-art.org This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained
[Haskell] FARM 2014 Call for Participation
Dear Haskell interested, Please find enclosed the call for participation in FARM 2014: 2nd ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design, co-located with ICFP 2014v in Gothenburg, September. All the best, /Henrik -- FARM 2014 2nd ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design Gothenburg, Sweden; 6 September, 2014 http://functional-art.org/2014/ The ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design (FARM) gathers together people who are harnessing functional techniques in the pursuit of creativity and expression. Functional Programming has emerged as a mainstream software development paradigm, and its artistic and creative use is booming. A growing number of software toolkits, frameworks and environments for art, music and design now employ functional programming languages and techniques. FARM is a forum for exploration and critical evaluation of these developments, for example to consider potential benefits of greater consistency, tersity, and closer mapping to a problem domain. Registration You can register via the ICFP 2014 registration: https://regmaster4.com/2014conf/ICFP14/register.php Don't be confused that it says “ICFP� - FARM is part of a larger event around ICFP 2014, and you can register for FARM without registering for ICFP. Early registration deadline is 3 August. Accepted papers --- Functional Generation of Harmony and Melody. José Pedro Magalhães, Department of Computer Science, University of Oxford; Hendrik Vincent Koops, Department of Information and Computing Sciences, Utrecht University. Exploring melody space in a live context using declarative functional programming. Thomas Kristensen, uSwitch Ltd. Making programming languages to dance to: Live Coding with Tidal. Alex McLean, Temporal semantics for a live coding language. Sam Aaron, Computer Laboratory, University of Cambridge; Dominic Orchard, Computer Laboratory, University of Cambridge; Alan Blackwell, Computer Laboratory, University of Cambridge. Tiled Polymorphic Temporal Media. Paul Hudak, Yale University; David Janin, LaBRI, Université de Bordeaux. LiveCodeLab 2.0 and its language LiveCodeLang. Davide Della Casa, LiveCodeLab; Guy John, LiveCodeLab. Accepted demonstrations --- littleBits Synth Kit as a livecoded, functional, monadic, physically-embodied, domain specific programming language. James Noble, Victoria University of Wellington; Timothy Jones, Victoria University of Wellington. Scripthica: a web environment for collective algorithmic composition. Gabriel Sanchez, New York University. Music Suite: A Family of Musical Representations. Hans Höglund. Patterning: Repetitive and recursive pattern generation using Clojure and Quil. Phil Jones, Alchemy Islands. Using Haskell as DSL for controlling immersive media experiences. Henrik Bäärnhielm, Integral Systems Engineering; Mikael Vejdemo-Johansson, KTH Royal Institute of Technology; Daniel Sundström, Integral Systems Engineering. Sound and Soundness – Practical Total Functional Data-Flow Programming. Baltasar Trancón Y Widemann, TU Ilmenau; Markus Lepper, semantics GmbH. Live Performances - On the evening of September 6 (after the workshop) we will have an evening of live performances at 3:e Våningen (3rd floor) (http://www.3vaningen.se/), in collaboration with with Anders Carlsson aka goto80 and Palle Dahlstedt, starting at 8PM. The evening will feature: - Sam Aaron with Dominic Orchard with Sonic Pi - LiveCodeLab - James Noble with Classic computer science algorithms assembled into algorave Details to be announced soon. Workshop Organisation - Workshop Chair: Alex McLean, School of Music, University of Leeds Program Chair: Henrik Nilsson, University of Nottingham Publicity Chair: Michael Sperber, Active Group GmbH Program Committee - - Sam Aaron, Cambridge University - David Duke, University of Leeds - Kathleen Fisher, Tufts University - Julie Greensmith, University of Nottingham - Bas de Haas, Universiteit Utrecht - Paul Hudak, Yale University - David Janin, Université de Bordeaux - Richard Lewis, Goldsmiths, University of London - Louis Mandel, Collège de France - Carin Meier, Neo Innovation Inc - Rob Myers, Furtherfield - Dan Piponi, Google Inc - Andrew Sorensen, Queensland University of Technology -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed
[Haskell] CFP: FARM 2014: Deadline extended!
Dear Haskell interested, You might want to be aware that the deadline for FARM 2014, 2nd ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design, has been extended to the *** 15 May, 2014 *** http://functional-art.org/2014/cfp.html All the best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. FARM 2014 2nd ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design Gothenburg, Sweden; 6 September, 2014 The ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design (FARM) gathers together people who are harnessing functional techniques in the pursuit of creativity and expression. Functional Programming has emerged as a mainstream software development paradigm, and its artistic and creative use is booming. A growing number of software toolkits, frameworks and environments for art, music and design now employ functional programming languages and techniques. FARM is a forum for exploration and critical evaluation of these developments, for example to consider potential benefits of greater consistency, tersity, and closer mapping to a problem domain. FARM encourages submissions from across art, craft and design, including textiles, visual art, music, 3D sculpture, animation, GUIs, video games, 3D printing and architectural models, choreography, poetry, and even VLSI layouts, GPU configurations, or mechanical engineering designs. The language used need not be purely functional (“mostly functional” is fine), and may be manifested as a domain specific language or tool. Theoretical foundations, language design, implementation issues, and applications in industry or the arts are all within the scope of the workshop. Submissions are invited in two categories: * Full papers 5 to 12 pages using the ACM SIGPLAN template. FARM 2014 is an interdisciplinary conference, so a wide range of approaches are encouraged and we recognize that the appropriate length of a paper may vary considerably depending on the approach. However, all submissions must propose an original contribution to the FARM theme, cite relevant previous work, and apply appropriate research methods. * Demo abstracts Demo abstracts should describe the demonstration and its context, connecting it with the themes of FARM. A demo could be in the form of a short (10-20 minute) tutorial, presentation of work-in-progress, an exhibition of some work, or even a performance. Abstracts should be no longer than 2 pages, using the ACM SIGPLAN template and will be subject to a light-touch peer review. If you have any questions about what type of contributions that might be suitable, or anything else regarding submission or the workshop itself, please contact the organisers at: workshop2...@functional-art.org KEY DATES: Full Paper and Demo Abstract submission Deadline: 15 May (NEW!) Author Notification:30 May Camera Ready: 18 June Workshop: 6 September SUBMISSION All papers and demo abstracts must be in portable document format (PDF), using the ACM SIGPLAN style guidelines. The text should be in a 9-point font in two columns. The submission itself will be via EasyChair. See the FARM website for further details: http://functional-art.org PUBLICATION Accepted papers will be included in the formal proceedings published by ACM Press and will also be made available through the the ACM Digital Library; see http://authors.acm.org/main.cfm for information on the options available to authors. Authors are encouraged to submit auxiliary material for publication along with their paper (source code, data, videos, images, etc.); authors retain all rights to the auxiliary material. WORKSHOP ORGANISATION Workshop Chair: Alex McLean, University of Leeds Program Chair: Henrik Nilsson, University of Nottingham Publicity Chair: Michael Sperber, Active Group GmbH Program Committee: Sam Aaron, Cambridge University David Duke
[Haskell] Reminder: FARM 2014: deadlines approaching!
Dear all, This is just a reminder about FARM 2014: Workshop on Functional Art, Music, Modeling and Design, co-located with ICFP in Gothenburg in September. http://functional-art.org/2014/ The abstract deadline (for full papers) is fast approaching (7 May), and the overall deadline for full papers and demos is not far behind (11 May). Call for papers enclosed. Apologies for cross-postings. All the best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. FARM 2014 2nd ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design Gothenburg, Sweden; 6 September, 2014 The ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design (FARM) gathers together people who are harnessing functional techniques in the pursuit of creativity and expression. Functional Programming has emerged as a mainstream software development paradigm, and its artistic and creative use is booming. A growing number of software toolkits, frameworks and environments for art, music and design now employ functional programming languages and techniques. FARM is a forum for exploration and critical evaluation of these developments, for example to consider potential benefits of greater consistency, tersity, and closer mapping to a problem domain. FARM encourages submissions from across art, craft and design, including textiles, visual art, music, 3D sculpture, animation, GUIs, video games, 3D printing and architectural models, choreography, poetry, and even VLSI layouts, GPU configurations, or mechanical engineering designs. The language used need not be purely functional (“mostly functional” is fine), and may be manifested as a domain specific language or tool. Theoretical foundations, language design, implementation issues, and applications in industry or the arts are all within the scope of the workshop. Submissions are invited in two categories: * Full papers 5 to 12 pages using the ACM SIGPLAN template. FARM 2014 is an interdisciplinary conference, so a wide range of approaches are encouraged and we recognize that the appropriate length of a paper may vary considerably depending on the approach. However, all submissions must propose an original contribution to the FARM theme, cite relevant previous work, and apply appropriate research methods. * Demo abstracts Demo abstracts should describe the demonstration and its context, connecting it with the themes of FARM. A demo could be in the form of a short (10-20 minute) tutorial, presentation of work-in-progress, an exhibition of some work, or even a performance. Abstracts should be no longer than 2 pages, using the ACM SIGPLAN template and will be subject to a light-touch peer review. If you have any questions about what type of contributions that might be suitable, or anything else regarding submission or the workshop itself, please contact the organisers at: workshop2...@functional-art.org KEY DATES: Abstract (for Full Papers) submission deadline: 7 May Full Paper and Demo Abstract submission Deadline: 11 May Author Notification:30 May Camera Ready: 18 June Workshop: 6 September SUBMISSION All papers and demo abstracts must be in portable document format (PDF), using the ACM SIGPLAN style guidelines. The text should be in a 9-point font in two columns. The submission itself will be via EasyChair. See the FARM website for further details: http://functional-art.org PUBLICATION Accepted papers will be included in the formal proceedings published by ACM Press and will also be made available through the the ACM Digital Library; see http://authors.acm.org/main.cfm for information on the options available to authors. Authors are encouraged to submit auxiliary material for publication along with their paper (source code, data, videos, images, etc.); authors retain all rights to the auxiliary material. WORKSHOP ORGANISATION Workshop Chair: Alex McLean, University
Re: RFC: changes to -i flag for finding source files
Hi, I want to propose a simple change to the -i flag for finding source files. The problem we often have is that when you're writing code for a library that lives deep in the module hierarchy, you end up needing a deep directory structure, e.g. +1 from me. The deep file system hierarchies imposed by the assumption that hierarchical module names need to be matched by a hierarchical directory structure has always bothered me (well, since hierarchical modules were introduced into Haskell some 15 years ago). In part because I do find it inconvenient, even if navigation arguably is not too hard, but more importantly because I think that language naming conventions in general should be as decoupled as possible from naming conventions of file systems/the mapping to how source code happen to be stored and organised on any particular system. While I do acknowledge the pragmatical convenience of essentially one-to-one mappings between module and file names, I think this proposal would be a step in the right direction, if feasible. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] CFP: FARM 2014: Functional Art, Music, Modelling and Design
Dear all, This is the second FARM 2014 call for papres. Sorry for any duplicate postings! If you are using Haskell or any mostly functional language in any kind of musical, artistic, or design endeavour, please consider contributing to FARM 2014, the 2nd ACM SIGPLAN International Workshop of Functional Art, Music, Modelling and Design, co-located with ICFP 2014. Call-for-papers enclosed. Best regards, /Henrik -- FARM 2014 2nd ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design Gothenburg, Sweden; 6 September, 2014 The ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design (FARM) gathers together people who are harnessing functional techniques in the pursuit of creativity and expression. Functional Programming has emerged as a mainstream software development paradigm, and its artistic and creative use is booming. A growing number of software toolkits, frameworks and environments for art, music and design now employ functional programming languages and techniques. FARM is a forum for exploration and critical evaluation of these developments, for example to consider potential benefits of greater consistency, tersity, and closer mapping to a problem domain. FARM encourages submissions from across art, craft and design, including textiles, visual art, music, 3D sculpture, animation, GUIs, video games, 3D printing and architectural models, choreography, poetry, and even VLSI layouts, GPU configurations, or mechanical engineering designs. The language used need not be purely functional (“mostly functional” is fine), and may be manifested as a domain specific language or tool. Theoretical foundations, language design, implementation issues, and applications in industry or the arts are all within the scope of the workshop. Submissions are invited in two categories: * Full papers 5 to 12 pages using the ACM SIGPLAN template. FARM 2014 is an interdisciplinary conference, so a wide range of approaches are encouraged and we recognize that the appropriate length of a paper may vary considerably depending on the approach. However, all submissions must propose an original contribution to the FARM theme, cite relevant previous work, and apply appropriate research methods. * Demo abstracts Demo abstracts should describe the demonstration and its context, connecting it with the themes of FARM. A demo could be in the form of a short (10-20 minute) tutorial, presentation of work-in-progress, an exhibition of some work, or even a performance. Abstracts should be no longer than 2 pages, using the ACM SIGPLAN template and will be subject to a light-touch peer review. If you have any questions about what type of contributions that might be suitable, or anything else regarding submission or the workshop itself, please contact the organisers at: workshop2...@functional-art.org KEY DATES: Abstract (for Full Papers) submission deadline: 7 May Full Paper and Demo Abstract submission Deadline: 11 May Author Notification:30 May Camera Ready: 18 June Workshop: 6 September SUBMISSION All papers and demo abstracts must be in portable document format (PDF), using the ACM SIGPLAN style guidelines. The text should be in a 9-point font in two columns. The submission itself will be via EasyChair. See the FARM website for further details: http://functional-art.org PUBLICATION Accepted papers will be included in the formal proceedings published by ACM Press and will also be made available through the the ACM Digital Library; see http://authors.acm.org/main.cfm for information on the options available to authors. Authors are encouraged to submit auxiliary material for publication along with their paper (source code, data, videos, images, etc.); authors retain all rights to the auxiliary material. WORKSHOP ORGANISATION Workshop Chair: Alex McLean, University of Leeds Program Chair: Henrik Nilsson, University of Nottingham Publicity Chair: Michael Sperber, Active Group GmbH Program Committee: Sam Aaron, Cambridge University David Duke, University of Leeds Kathleen Fisher, Tufts University Julie Greensmith, University of Nottingham Bas de Haas, Universiteit Utrecht Paul Hudak, Yale University David Janin, Université de Bordeaux Richard Lewis, Goldsmiths, University of London Louis Mandel, Collège de France Alex McLean, University of Leeds Carin Meier, Neo Innovation Inc Rob Myers, Furtherfield Henrik Nilsson, University of Nottingham (chair) Dan Piponi, Google Inc Andrew Sorensen, Queensland University of Technology Michael Sperber, Active Group GmbH For further details, see the FARM website: http
[Haskell] CFP: FARM 2014: Functional Art, Music, Modelling and Design
Dear all, If you are using Haskell or any mostly functional language in any kind of musical, artistic, or design endeavour, please consider contributing to FARM 2014, the 2nd ACM SIGPLAN International Workshop of Functional Art, Music, Modelling and Design, co-located with ICFP 2014. Call-for-papers enclosed. Best regards, /Henrik -- FARM 2014 2nd ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design Gothenburg, Sweden; 6 September, 2014 The functional programming community is largely interested in writing beautiful programs. The ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design (FARM) is intended to gather researchers and practitioners interested in writing beautiful programs which generate beautiful artifacts or experiences, or perhaps even challenge notions of beauty. FARM encourages submissions from across art, craft and design, including textiles, visual art, music, 3D sculpture, animation, GUIs, video games, physical models, architectural models, choreographies for dance, poetry, and even VLSI layouts, GPU configurations, or mechanical engineering designs. The language used need not be purely functional (mostly functional is fine); may be based on abstractions such as higher-order functions, monads, arrows, or streams; and may be manifested as a domain specific language or tool. Theoretical foundations, language design, implementation issues, and applications in industry or the arts are all within the scope of the workshop. Submissions are invited in two categories: * Full papers 5 to 12 pages using the ACM SIGPLAN template. FARM 2014 is an interdisciplinary conference, so a wide range of approaches are encouraged and we recognize that the appropriate length of a paper may vary considerably depending on the approach. However, all submissions must propose an original contribution to the FARM theme, cite relevant previous work, and apply appropriate research methods. * Demo abstracts Demo abstracts should describe the demonstration and its context, connecting it with the themes of FARM. A demo could be in the form of a short (10-20 minute) tutorial, presentation of work-in-progress, an exhibition of some work, or even a performance. Abstracts should be no longer than 2 pages, using the ACM SIGPLAN template and will be subject to a light-touch peer review. If you have any questions about what type of contributions that might be suitable, or anything else regarding submission or the workshop itself, please contact the organisers at: workshop2...@functional-art.org KEY DATES: Abstract (for Full Papers) submission deadline: 7 May Full Paper and Demo Abstract submission Deadline: 11 May Author Notification:30 May Camera Ready: 18 June Workshop: 6 September SUBMISSION All papers and demo abstracts must be in portable document format (PDF), using the ACM SIGPLAN style guidelines. The text should be in a 9-point font in two columns. The submission itself will be via EasyChair. See the FARM website for further details: http://functional-art.org PUBLICATION Accepted papers will be included in the formal proceedings published by ACM Press and will also be made available through the the ACM Digital Library; see http://authors.acm.org/main.cfm for information on the options available to authors. Authors are encouraged to submit auxiliary material for publication along with their paper (source code, data, videos, images, etc.); authors retain all rights to the auxiliary material. WORKSHOP ORGANISATION Workshop Chair: Alex McLean, University of Leeds Program Chair: Henrik Nilsson, University of Nottingham Publicity Chair: Michael Sperber, Active Group GmbH Program Committee: Sam Aaron, Cambridge University David Duke, University of Leeds Kathleen Fisher, Tufts University Julie Greensmith, University of Nottingham Bas de Haas, Universiteit Utrecht Paul Hudak, Yale University David Janin, Université de Bordeaux Richard Lewis, Goldsmiths, University of London Louis Mandel, Collège de France Alex McLean, University of Leeds Carin Meier, Neo Innovation Inc Rob Myers, Furtherfield Henrik Nilsson, University of Nottingham (chair) Dan Piponi, Google Inc Andrew Sorensen, Queensland University of Technology Michael Sperber, Active Group GmbH For further details, see the FARM website: http://functional-art.org -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately
[Haskell] CFP: EOOLT 2013
Dear Haskellers, The included call for participation in the 5th international workshop on Equation-based Object-Oriented Languages and Tools (EOOLT) 2013 may be of interest to those interested in declarative domain-specific languages in the context of Haskell. Apologies for multiple copies! All the best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.  EOOLT 2013 5th International Workshop on Equation-Based Object-Oriented Modeling Languages and Tools Nottingham, UK, 19 April, 2013 CALL FOR PARTICIPATION ***Early registration deadline:*** *** 5 April, 2013 *** *** http://www.eoolt.org/2013 *** During the past decade, integrated model-based design of complex cyber- physical systems (which mix physical dynamics with software and networks) has gained significant attention. Hybrid modeling languages based on equations, supporting both continuous-time and event-based aspects (e.g. Modelica, SysML, VHDL-AMS, and Simulink/Simscape) enable high-level reuse and integrated modeling capabilities of both the physically surrounding system and software for embedded systems. The EOOLT workshop addresses the current state of the art of such equation-based object-oriented (EOO) modeling languages, as well as open issues that currently still limit their expressiveness, correctness, and usefulness. Moreover, integration of and comparison with related approaches and languages, such as actor-oriented, synchronous, and domain specific languages, are of particular interest. The program for EOOLT 2013 can be found here: http://www.eoolt.org/2013/index.php?id=program Further, registration is now open: http://www.eoolt.org/2013/index.php?id=attending#registration Travel and accommodation information can be found here: http://www.eoolt.org/2013/index.php?id=attending IMPORTANT DATES: Early registration deadline:5 April Registration deadline: 14 April Workshop: 19 April WORKSHOP ORGANISATION Chair: Henrik Nilsson, University of Nottingham Program Committee: Bernhard Bachmann, University of Applied Sciences, Bielefeld Bert van Beek, Eindhoven University of Technology David Broman, U.C. Berkeley and Linköping University Francesco Casella, Politecnico di Milano François Cellier, ETH Zürich Olaf Enge-Rosenblatt, Fraunhofer Institute, Dresden Peter Fritzson, Linköping University Michaela Huhn, Clausthal University of Technology Edward A. Lee, U.C. Berkeley Pieter Mosterman, MathWorks Ramine Nikoukhah, INRIA Rocquencourt and Altair Chris Paredis, Georgia Institute of Technology Peter Pepper, TU Berlin Walid Taha, Halmstad University and Rice University Alfonso UrquÃa, UNED, Madrid Hans Vangheluwe, McGill University and University of Antwerp Justyna Zander, MathWorks and Gdansk University of Technology Dirk Zimmer, DLR Oberpfaffenhofen Steering Committee: David Broman, U.C. Berkeley and Linköping University François E. Cellier, ETH Zürich Peter Fritzson, Linköping University Edward A. Lee, U.C. Berkeley Local Organisation: John Capper, University of Nottingham Nadine Holmes, University of Nottingham Henrik Nilsson, University of Nottingham For further details, see the EOOLT 2013 website: www.eoolt.org/2013 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: GHC 7.8 release?
Hi all, Ian Lynagh wrote: Does the Haskell Platform actually want to commit to using a GHC release with tons of [new] stuff, that has had little testing, days or weeks after its release? I thought the idea was that it would favour known-good releases over the latest-and-greatest, but perhaps I misunderstood or the philosophy has changed. From a teaching perspective, I'd hope the philosophy is still known-good releases. The Haskell platform is what we deploy on our teaching machines, and we really need to be able to trust that it will work very smoothly, or we'd risk losing lots of valuable teaching time and, even worse, putting lots of students off Haskell. (Getting students to appreciate Haskell is an upwards struggle at the best of times anyway.) Something like new run-time system features sounds like something that really ought to be tested very thoroughly before being integrated into the HP. So, for (general) teaching, at least, stability over new features any day. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] CFP: EOOLT 2013: Extended Submission Deadline!
Dear Haskellers, The included call for papers to the 5th international workshop on Equation-based Object-Oriented Languages and Tools (EOOLT) 2013 may be of interest to those interested in declarative domain-specific languages in the context of Haskell. Note that the deadlines have been extended: * Abstracts: 8 February * Full papers: 18 February Apologies for multiple copies! All the best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.  EOOLT 2013 5th International Workshop on Equation-Based Object-Oriented Modeling Languages and Tools Nottingham, UK, 19 April, 2013 *** Extended submission deadlines: *** ***Abstracts: 8 February, 2013 *** *** Full papers: 18 February, 2013 *** CALL FOR PAPERS During the past decade, integrated model-based design of complex cyber- physical systems (which mix physical dynamics with software and networks) has gained significant attention. Hybrid modeling languages based on equations, supporting both continuous-time and event-based aspects (e.g. Modelica, SysML, VHDL-AMS, and Simulink/Simscape) enable high-level reuse and integrated modeling capabilities of both the physically surrounding system and software for embedded systems. The EOOLT workshop addresses the current state of the art of such equation-based object-oriented (EOO) modeling languages, as well as open issues that currently still limit their expressiveness, correctness, and usefulness. Moreover, integration of and comparison with related approaches and languages, such as actor-oriented, synchronous, and domain specific languages, are of particular interest. Specific topics of interest include (but are not limited to): o Acausality and its role in model reusability. o Component systems for EOO languages. o Discrete-event and hybrid modeling. o Embedded systems and efficient code generation. o Modeling language constructs in support of simulation, optimization, diagnostics, and system identification. o EOO mathematical modeling vs. UML software modeling. o Integrated hardware and software modeling of cyber-physical systems. o Requirement to model traceability, translation, and integration. o Formal semantics of EOO related languages. o Multi-resolution and multi-scale modeling using EOO languages. o Model-driven development related to EOO languages. o Numerical coupling of EOO simulators and other simulation tools. o Parallel execution of EOO models. o Programming and modeling environments. o Real-time simulation using EOO languages. o Reflection and meta-programming. o Verification, type systems, and early static checking. o Relation to functional reactive programming (FRP) and synchronous languages. SUBMISSION Researchers and practitioners are invited to submit full-length papers (up to 10 pages, EOOLT style, written in English) for consideration by the program committee. Papers must be original, and not submitted for simultaneous publication in any other forum. EOOLT welcomes original research contributions as well as contributions with a focus on practice, such as experience reports and comparisons of existing languages and tools. Each contributions will be judged according to criteria appropriate for its kind. For submission details, see the EOOLT 2013 website (link below). OTHER CONTRIBUTIONS To allow for a more dynamic workshop format, the EOOLT PC will, subject to space in the program, consider proposals for other kinds of program points, such as tool demonstrations or discussion sessions on some timely topics in the scope of EOOLT. Such proposals will be judged by the PC as a whole on the grounds of how much interest they add to the workshop, and they should thus not be confused with formally peer-reviewed contributions. That said, if considered appropriate and useful, the PC may invite a short (1 - 2 pages) written outline for inclusion in the workshop proceedings (clearly labeled to distinguish it from regular papers). For further details, see
[Haskell] CFP: EOOLT 2013
Dear Haskellers, The included call for papers to the 5th international workshop on Equation-based Object-Oriented Languages and Tools (EOOLT) 2013 may be of interest to those interested in declarative domain-specific languages in the context of Haskell. Apologies for multiple copies! All the best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. EOOLT 2013 5th International Workshop on Equation-Based Object-Oriented Modeling Languages and Tools Nottingham, UK, 19 April, 2013 CALL FOR PAPERS During the past decade, integrated model-based design of complex cyber- physical systems (which mix physical dynamics with software and networks) has gained significant attention. Hybrid modeling languages based on equations, supporting both continuous-time and event-based aspects (e.g. Modelica, SysML, VHDL-AMS, and Simulink/Simscape) enable high-level reuse and integrated modeling capabilities of both the physically surrounding system and software for embedded systems. The EOOLT workshop addresses the current state of the art of such equation-based object-oriented (EOO) modeling languages, as well as open issues that currently still limit their expressiveness, correctness, and usefulness. Moreover, integration of and comparison with related approaches and languages, such as actor-oriented, synchronous, and domain specific languages, are of particular interest. Specific topics of interest include (but are not limited to): o Acausality and its role in model reusability. o Component systems for EOO languages. o Discrete-event and hybrid modeling. o Embedded systems and efficient code generation. o Modeling language constructs in support of simulation, optimization, diagnostics, and system identification. o EOO mathematical modeling vs. UML software modeling. o Integrated hardware and software modeling of cyber-physical systems. o Requirement to model traceability, translation, and integration. o Formal semantics of EOO related languages. o Multi-resolution and multi-scale modeling using EOO languages. o Model-driven development related to EOO languages. o Numerical coupling of EOO simulators and other simulation tools. o Parallel execution of EOO models. o Programming and modeling environments. o Real-time simulation using EOO languages. o Reflection and meta-programming. o Verification, type systems, and early static checking. o Relation to functional reactive programming (FRP) and synchronous languages. SUBMISSION Researchers and practitioners are invited to submit full-length papers (up to 10 pages, EOOLT style, written in English) for consideration by the program committee. Papers must be original, and not submitted for simultaneous publication in any other forum. EOOLT welcomes original research contributions as well as contributions with a focus on practice, such as experience reports and comparisons of existing languages and tools. Each contributions will be judged according to criteria appropriate for its kind. For submission details, see the EOOLT 2013 website (link below). OTHER CONTRIBUTIONS To allow for a more dynamic workshop format, the EOOLT PC will, subject to space in the program, consider proposals for other kinds of program points, such as tool demonstrations or discussion sessions on some timely topics in the scope of EOOLT. Such proposals will be judged by the PC as a whole on the grounds of how much interest they add to the workshop, and they should thus not be confused with formally peer-reviewed contributions. That said, if considered appropriate and useful, the PC may invite a short (1 - 2 pages) written outline for inclusion in the workshop proceedings (clearly labeled to distinguish it from regular papers). For further details, see the EOOLT 2013 website (link below). IMPORTANT DATES Submission Deadline:1 February Author Notification:1 March Camera Ready: 22 March Workshop: 19 April PUBLICATION Accepted papers will be published electronically by Linköping University
[Haskell] CFP: EOOLT 2013
Dear Haskellers, The included call for papers to the 5th international workshop on Equation-based Object-Oriented Languages and Tools (EOOLT) 2013 may be of interest to those interested in declarative domain-specific languages in the context of Haskell. EOOLT 2013 is now open for submission. Apologies for multiple copies! All the best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.  EOOLT 2013 5th International Workshop on Equation-Based Object-Oriented Modeling Languages and Tools Nottingham, UK, 19 April, 2013 CALL FOR PAPERS During the past decade, integrated model-based design of complex cyber- physical systems (which mix physical dynamics with software and networks) has gained significant attention. Hybrid modeling languages based on equations, supporting both continuous-time and event-based aspects (e.g. Modelica, SysML, VHDL-AMS, and Simulink/Simscape) enable high-level reuse and integrated modeling capabilities of both the physically surrounding system and software for embedded systems. The EOOLT workshop addresses the current state of the art of such equation-based object-oriented (EOO) modeling languages, as well as open issues that currently still limit their expressiveness, correctness, and usefulness. Moreover, integration of and comparison with related approaches and languages, such as actor-oriented, synchronous, and domain specific languages, are of particular interest. Specific topics of interest include (but are not limited to): o Acausality and its role in model reusability. o Component systems for EOO languages. o Discrete-event and hybrid modeling. o Embedded systems and efficient code generation. o Modeling language constructs in support of simulation, optimization, diagnostics, and system identification. o EOO mathematical modeling vs. UML software modeling. o Integrated hardware and software modeling of cyber-physical systems. o Requirement to model traceability, translation, and integration. o Formal semantics of EOO related languages. o Multi-resolution and multi-scale modeling using EOO languages. o Model-driven development related to EOO languages. o Numerical coupling of EOO simulators and other simulation tools. o Parallel execution of EOO models. o Programming and modeling environments. o Real-time simulation using EOO languages. o Reflection and meta-programming. o Verification, type systems, and early static checking. o Relation to functional reactive programming (FRP) and synchronous languages. SUBMISSION Researchers and practitioners are invited to submit full-length papers (up to 10 pages, EOOLT style, written in English) for consideration by the program committee. Papers must be original, and not submitted for simultaneous publication in any other forum. EOOLT welcomes original research contributions as well as contributions with a focus on practice, such as experience reports and comparisons of existing languages and tools. Each contributions will be judged according to criteria appropriate for its kind. For submission details, see the EOOLT 2013 website (link below). OTHER CONTRIBUTIONS To allow for a more dynamic workshop format, the EOOLT PC will, subject to space in the program, consider proposals for other kinds of program points, such as tool demonstrations or discussion sessions on some timely topics in the scope of EOOLT. Such proposals will be judged by the PC as a whole on the grounds of how much interest they add to the workshop, and they should thus not be confused with formally peer-reviewed contributions. That said, if considered appropriate and useful, the PC may invite a short (1 - 2 pages) written outline for inclusion in the workshop proceedings (clearly labeled to distinguish it from regular papers). For further details, see the EOOLT 2013 website (link below). IMPORTANT DATES Submission Deadline:1 February Author Notification:1 March Camera Ready: 22 March Workshop: 19 April PUBLICATION Accepted papers will be published
[Haskell] CFP: EOOLT 2013
Dear Haskellers, The included call for papers to the 5th international workshop on Equation-based Object-Oriented Languages and Tools (EOOLT) 2013 may be of interest to those interested in declarative domain-specific languages in the context of Haskell. Apologies for multiple copies! All the best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.  EOOLT 2013 5th International Workshop on Equation-Based Object-Oriented Modeling Languages and Tools Nottingham, UK, 19 April, 2013 CALL FOR PAPERS During the past decade, integrated model-based design of complex cyber- physical systems (which mix physical dynamics with software and networks) has gained significant attention. Hybrid modeling languages based on equations, supporting both continuous-time and event-based aspects (e.g. Modelica, SysML, VHDL-AMS, and Simulink/Simscape) enable high-level reuse and integrated modeling capabilities of both the physically surrounding system and software for embedded systems. The EOOLT workshop addresses the current state of the art of such equation-based object-oriented (EOO) modeling languages, as well as open issues that currently still limit their expressiveness, correctness, and usefulness. Moreover, integration of and comparison with related approaches and languages, such as actor-oriented, synchronous, and domain specific languages, are of particular interest. Specific topics of interest include (but are not limited to): o Acausality and its role in model reusability. o Component systems for EOO languages. o Discrete-event and hybrid modeling. o Embedded systems and efficient code generation. o Modeling language constructs in support of simulation, optimization, diagnostics, and system identification. o EOO mathematical modeling vs. UML software modeling. o Integrated hardware and software modeling of cyber-physical systems. o Requirement to model traceability, translation, and integration. o Formal semantics of EOO related languages. o Multi-resolution and multi-scale modeling using EOO languages. o Model-driven development related to EOO languages. o Numerical coupling of EOO simulators and other simulation tools. o Parallel execution of EOO models. o Programming and modeling environments. o Real-time simulation using EOO languages. o Reflection and meta-programming. o Verification, type systems, and early static checking. o Relation to functional reactive programming (FRP) and synchronous languages. SUBMISSION Researchers and practitioners are invited to submit full-length papers (up to 10 pages, EOOLT style, written in English) for consideration by the program committee. Papers must be original, and not submitted for simultaneous publication in any other forum. EOOLT welcomes original research contributions as well as contributions with a focus on practice, such as experience reports and comparisons of existing languages and tools. Each contributions will be judged according to criteria appropriate for its kind. For submission details, see the EOOLT 2013 website (link below). OTHER CONTRIBUTIONS To allow for a more dynamic workshop format, the EOOLT PC will, subject to space in the program, consider proposals for other kinds of program points, such as tool demonstrations or discussion sessions on some timely topics in the scope of EOOLT. Such proposals will be judged by the PC as a whole on the grounds of how much interest they add to the workshop, and they should thus not be confused with formally peer-reviewed contributions. That said, if considered appropriate and useful, the PC may invite a short (1 - 2 pages) written outline for inclusion in the workshop proceedings (clearly labeled to distinguish it from regular papers). For further details, see the EOOLT 2013 website (link below). IMPORTANT DATES Submission Deadline:1 February Author Notification:1 March Camera Ready: 22 March Workshop: 19 April PUBLICATION Accepted papers will be published electronically by Linköping University
[Haskell] CFP: EOOLT 2013
Dear Haskellers, The included call for papers to the 5th international workshop on Equation-based Object-Oriented Languages and Tools (EOOLT) 2013 may be of interest to those interested in declarative domain-specific languages in the context of Haskell. Please consider to contribute! Also, if you could forward to colleagues who might be interested, I would be much obliged. Apologies for multiple copies! All the best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.  EOOLT 2013 5th International Workshop on Equation-Based Object-Oriented Modeling Languages and Tools Nottingham, UK, 19 April, 2013 CALL FOR PAPERS During the past decade, integrated model-based design of complex cyber- physical systems (which mix physical dynamics with software and networks) has gained significant attention. Hybrid modeling languages based on equations, supporting both continuous-time and event-based aspects (e.g. Modelica, SysML, VHDL-AMS, and Simulink/Simscape) enable high-level reuse and integrated modeling capabilities of both the physically surrounding system and software for embedded systems. The EOOLT workshop addresses the current state of the art of such equation-based object-oriented (EOO) modeling languages, as well as open issues that currently still limit their expressiveness, correctness, and usefulness. Moreover, integration of and comparison with related approaches and languages, such as actor-oriented, synchronous, and domain specific languages, are of particular interest. Specific topics of interest include (but are not limited to): o Acausality and its role in model reusability. o Component systems for EOO languages. o Discrete-event and hybrid modeling. o Embedded systems and efficient code generation. o Modeling language constructs in support of simulation, optimization, diagnostics, and system identification. o EOO mathematical modeling vs. UML software modeling. o Integrated hardware and software modeling of cyber-physical systems. o Requirement to model traceability, translation, and integration. o Formal semantics of EOO related languages. o Multi-resolution and multi-scale modeling using EOO languages. o Model-driven development related to EOO languages. o Numerical coupling of EOO simulators and other simulation tools. o Parallel execution of EOO models. o Programming and modeling environments. o Real-time simulation using EOO languages. o Reflection and meta-programming. o Verification, type systems, and early static checking. o Relation to functional reactive programming (FRP) and synchronous languages. SUBMISSION Researchers and practitioners are invited to submit full-length papers (up to 10 pages, EOOLT style, written in English) for consideration by the program committee. Papers must be original, and not submitted for simultaneous publication in any other forum. EOOLT welcomes original research contributions as well as contributions with a focus on practice, such as experience reports and comparisons of existing languages and tools. Each contributions will be judged according to criteria appropriate for its kind. For submission details, see the EOOLT 2013 website (link below). OTHER CONTRIBUTIONS To allow for a more dynamic workshop format, the EOOLT PC will, subject to space in the program, consider proposals for other kinds of program points, such as tool demonstrations or discussion sessions on some timely topics in the scope of EOOLT. Such proposals will be judged by the PC as a whole on the grounds of how much interest they add to the workshop, and they should thus not be confused with formally peer-reviewed contributions. That said, if considered appropriate and useful, the PC may invite a short (1 - 2 pages) written outline for inclusion in the workshop proceedings (clearly labeled to distinguish it from regular papers). For further details, see the EOOLT 2013 website (link below). IMPORTANT DATES Submission Deadline:1 February Author Notification:1 March Camera Ready: 22 March
[Haskell-cafe] Adding to / subtracting from a LocalTime?
Hi. How do you add to or subtract from a LocalTime? I'm trying to subtract a second from a LocalTime value but the only API's I can find act only on the TimeOfDay part. subSec :: LocalTime - LocalTime subSec (LocalTime d t) = LocalTime d $ timeToTimeOfDay ((timeOfDayToTime t) - (secondsToDiffTime 1)) I'm obviously on the wrong track as this looks way too complex for what it's trying to achieve. Calling with '2012-08-18 00:00:00' gives '2012-08-18 -01:59:59' which isn't very helpful. How do I get to '2012-08-17 23:59:59'? Thanks, Adde ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Adding to / subtracting from a LocalTime?
Ok, do you know of any way to add/subtract without converting to UTC and back? On Sat, Aug 18, 2012 at 7:53 PM, Paolino paolo.verone...@gmail.com wrote: Hello. This is a part of a solution, with explicit TimeZone Prelude Data.Time :t \z s t - utcToLocalTime z $ addUTCTime (fromIntegral s) (localTimeToUTC z t) \z s t - utcToLocalTime z $ addUTCTime (fromIntegral s) (localTimeToUTC z t) :: Integral a = TimeZone - a - LocalTime - LocalTime where the Integral arguments is in seconds, by docs regards paolino 2012/8/18 Adde Nilsson trialc...@gmail.com Hi. How do you add to or subtract from a LocalTime? I'm trying to subtract a second from a LocalTime value but the only API's I can find act only on the TimeOfDay part. subSec :: LocalTime - LocalTime subSec (LocalTime d t) = LocalTime d $ timeToTimeOfDay ((timeOfDayToTime t) - (secondsToDiffTime 1)) I'm obviously on the wrong track as this looks way too complex for what it's trying to achieve. Calling with '2012-08-18 00:00:00' gives '2012-08-18 -01:59:59' which isn't very helpful. How do I get to '2012-08-17 23:59:59'? Thanks, Adde ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Adding to / subtracting from a LocalTime?
Didn't know, thanks. Back in Haskell land my conclusion is that if you're planning on doing pure date calculations you have to pass a TimeZone as well. /Adde On Sun, Aug 19, 2012 at 12:11 AM, Brandon Allbery allber...@gmail.comwrote: On Sat, Aug 18, 2012 at 6:05 PM, Adde Nilsson trialc...@gmail.com wrote: Ok, do you know of any way to add/subtract without converting to UTC and back? I'm not sure I'd do that in any environment, since usually libraries don't deal with the result crossing a daylight/summer time change (and those that do, surprise surprise, normalize to UTC). -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: default instance for IsString
Hi, On 04/25/2012 09:15 AM, Yitzchak Gale wrote: Because all other uses of OverloadedStrings that I have seen, and there are many, are ill-advised in my opinion. They all should have been quasiquoters. But the problem here is that reasonable people may choose to disagree as to what is ill-advised or not. Thus, rather than generalising the existing approach to overloaded literals in the most straightforward way possible to strings, the argument is that overloaded string literals need to be handled differently due to a fundamentally subjective argument about what is ill-advised or not, and how overloaded strings might be abused unless there is some special checking in place. I'm not saying that partial instances of fromString is a good idea. In fact, I'm prepared to believe those who say that all instances of this they have come across are ill-advised. But that is not to say that it necessarily always has to be a bad idea. Thus, it seems to me that a systematic language extension is preferable for simplicity and as it does not add any fundamentally new issues, to one which leads to a more involved design based on subjective arguments about programming style. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
Hi, Yitzhack Gale wrote: Wouldn't it be ironic if the one thing that every language other than Haskell is able to check at compile time, namely the static syntax of string literals, could only be checked at run time in Haskell? I don't really see the irony, I'm afraid, as nothing really has changed, and as Simon M. that I don't see what the fuss is about. Presumably, the syntax of string literals as such is still going to be checked by the scanner, as it always was? And the issue, then, is whether an overloaded fromString is total in all its overloadings? Or did I miss something central, here? Well, Haskell is not a total language, so the fact that fromString might have non-total overloadings is not surprising. Yes, fromString would be implicitly inserted, just like e.g. fromInteger for overloaded integer literals, to create the effect of overloaded literals, but this is really just a convenience, albeit an important one. The benefit of an approach to overloading of string literals that is analogous to the existing method for overloading of numeric literals would seem to me to outweigh the benefits of additional static checking through an essentially new approach to overloading of literals for a specific case. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Long live String = [Char] (Was: Re: String != [Char])
, you can't write an instance MyClass String in Haskell2010, and even with GHC extensions it seems wrong and you often end up writing instances that overlap with MyClass [a].) I'm using Data.Text a lot, so I can work around the issue, but unfortunately you run into a lot of issues where the standard library forces the use of String, and that, I believe, is wrong. If changing the standard library is the bigger issue, however, then I'm not sure whether this discussion needs to take place on the haskell-prime list or on the libraries list. Indeed. Maybe all that's really needed at the language level is to standardize overloading of string literals? (In a way that avoids issues like the ones described above.) Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
Hi all, Gabriel Dos Reis wrote: Look at the almost permanent damage done by the culture that equated 'char*' to strings. It may be inconvenient to say, but [Char] isn't any better -- in fact, I'll go further and say: it is spreading the same damage but only with a different syntax. The damage is semantics, no amount of syntax clothing will undo it. I realize that may appear as a strong statement, but think about it. Reasonable people might choose to disagree with that. In any case, this is hardly the place to to discuss how to best teach Haskell or programming in general. Nor is the Haskell standard a vehicle to prescribe how Haskell should be taught or for what reasons Haskell should be taught: that can only be decided by individual educators based in their experience and given a specific teaching context. Given intimate knowledge of our specific teaching context here at Nottingham, I can say that removing String = [Char] from the language wouldn't be helpful to us. And we do respect our students. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Records in Haskell
Hi,
Just checking my understanding here as I have not followed this thread
in all its details.
Gabor Lehel wrote:
I agree completely. This is what I like about DORF: the D stands for
Declared, which is referring to the fact that the contracts are
explicit. Record fields aren't automatically polymorphic based on
their name and type, as with SORF, rather they are scoped and
disambiguated in the same way as classes.
So, with both DORF and your variant of it, am I correct in understanding
that polymorphic fields, be it universally quantified as in
data ARecordType a =
C1 {
...,
fieldX :: a,
...,
fieldY :: a - a,
...
}
or existentially quantified as in:
data AnotherRecordType =
forall a . C2 {
...,
fieldU :: a,
...,
fieldV :: a - Int,
...
}
would no longer be possible?
Note that the type variable a in both cases scope just over the
constructor(s) of the data type in question. So any attempt at
declaring the types of the fields outside of this context,
be it explicitly with the fieldLabel notation, or implicitly as
per your proposal, would not be possible. E.g.
fieldLabel fieldY :: a - a
would presumably mean
fieldLabel fieldY :: forall a . a - a
resulting in ARecordType becoming second-order polymorphic
where the value of fieldY would *have* to be a polymorphic function,
which is very different from the original definition.
Similarly, the whole point with the existentially quantification is
to allow a number of fields to share some specific but arbitrary type,
which again means that any attempt to type these fields outside of the
context of the datatype to which they belong would result in something
different.
Note that fieldU and fieldV cannot be used as projection functions
due to escaped type variables, but that field selection by pattern
matching is perfectly fine.
Both constructions above are very useful and, I'd argue that a design
that rules them out actually is a rather poor fit for a language like
Haskell.
To be completely honest, I, at least, would be much happier keeping
working around the present limitations of Haskell's named fields by
picking my field names carefully, than losing the above.
Or am I missing something? E.g. is the idea that sharing of fields
only applies to fields of monomorphic type, i.e. whose type can be
declared globally?
Best,
/Henrik
--
Henrik Nilsson
School of Computer Science
The University of Nottingham
n...@cs.nott.ac.uk
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Posting etiquette, was Re: Records in Haskell
Hi, On 01/19/2012 10:22 AM, Jos Pedro Magalhes wrote: One could also argue that a good email client should automatically hide long quotes. In fact, I guess many people are not even aware of the problem because their client does this. But then what is the point of including the text in the first place if it is understood it is only there to be hidden? Besides, personally, I don't want my e-mail client to attempt (and, short of it truly having an understanding of what is being said, inevitably fail) to understand which parts of an e-mail are of interest to me and which parts are not. No, I agree completely with Malcolm: not taking the time to quote ONLY what is of relevance to provide the immediately relevant context for a point one wishes to make is a failure of communication and, indeed, an abuse of other's time. Thanks, Malcolm, well said! /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] How did iteratees get their names?
Hi, Ertugrul wrote: Just like chatter and chattee, employer and employee, there is an iterator (usually as part of an enumerator/ee) and an iteratee. Thanks for the attempt to explain. But I, at least, remain mystified, and I agree with Douglas that the terminology is confusing. Usually, the relationship between word-pairs such as the ones above is pretty obvious, typically implying some kind of subordinate relationship. For example: * employer: the one employing employee: the one employed * tutor: the one teaching, instructing, providing care tutee: the one receiving instruction, care * caller: that which is calling callee: that which is being called And so on. The above would suggest that iterator would be something that iterates over something, and that iteratee would be (an element of) that being iterated over. However, no such simple relationship seems to emerge from the provided explanation. I also had a look at John Millikin's page on Understanding Iteratees, which is very good: https://john-millikin.com/articles/understanding-iteratees/ But, the intuition that comes across there is: * iteratee: a stream (of sorts) consumer * enumerator: a stream (of sorts) producer * enumeratee: a stream (of sorts) transformer And iterator isn't mentioned at all. I might be missing something, but the terminology is hardly crystal clear. Which is a pity! Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How did iteratees get their names?
Hi Ertugrul, Coroutines actually capture this kind of composition (where some code interrupts itself to hand control over to some other code) very well. Perhaps it would be better to use terms from that abstraction instead. In fact, iteratees are a special case of coroutines. That would seem to make sense, if there is appropriate terminology. And if we are indeed talking about co-routines, i.e. cooperation between peers, routines of equal status, that would in itself suggest that the X-or and X-ee names that imply an asymmetric relationship are somewhat unfortunate choices conveying the wrong intuition. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Two Proposals
Hi all, Simon PJ wrote: should we not treat [a,b,c] as short for return a `mappend` return b `mappend` return c [...] I'm not sure if this plan would support [(fred,45), (bill,22)] :: Map String Int. Probably not. Maybe that's a shortcoming... but such Maps are a rather surprising use of list literals. Maybe. But not more surprising than how, say, numeric literals are used in many EDSLs. I also like George's proposal. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] tfp2011: last CFP
of students, the students are listed as first authors, and a student would present the paper. 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 a lightweight peer review process of extended abstracts (6 to 10 pages in length) or full papers (16 pages). Accepted abstracts are to be completed to full papers before the symposium for publication in the draft proceedings. The submission must clearly indicate 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 2011 website. Submission procedures will be posted on the TFP 2011 website as the submission deadline is approaching. The papers of the local proceedings will also be made available on-line under some copyright conditions, with which all authors are asked to agree (see http://dalila.sip.ucm.es/tfp11/). POST-SYMPOSIUM REFEREEING AND PUBLICATION In addition to the symposium draft proceedings, we will continue the last year decision of publishing a high-quality subset of contributions in the Springer Lecture Notes in Computer Science series (previous editions were published by Intellect). 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 submitted 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 (2011): TFP 2011 Symposium:May 16-18th Student papers feedback: June 6th Submission for formal review: June 24th Notification of acceptance for LNCS: September 2nd Camera ready paper:September 23rd TFP 2011 ORGANIZATION Steering Committee Chair: Marko van Eekelen, Radboud University Nijmegen and Open University, NL Steering Committee Treasurer: Hans-Wolfgang Loidl, Heriot-Watt University, UK Symposium Organization Chair: Ricardo Pe~na, Complutense University of Madrid, ES TFP 2011 PROGRAMME COMMITTEE Peter Achten(Radboud University Nijmegen, NL) Ana Bove(Chalmers University of Technology, SE) Olaf Chitil (University of Kent, UK) Marko van Eekelen (Radboud University Nijmegen,Open University, NL) Robby Findler (Northwestern University, USA) Victor Gul'ias (University of La Coru~na, ES) Jurriaan Hage (University of Utrecht, NL) Kevin Hammond (University of St. Andrews, UK) Michael Hanus (Christian Albrechts University zu Kiel, DE) Zolt'an Horv'ath(Eotvos Lor'and University, HU) Frank Huch (Christian Albrechts University zu Kiel, DE) Mauro Jaskelioff(National University of Rosario, AR) Rita Loogen (Philipps University Marburg, DE) Jay McCarthy(Brigham Young University, USA) Henrik Nilsson (University of Nottingham, UK) Rex Page(University of Oklahoma, USA) Ricardo Pe~na (Chair) (Complutense University of Madrid, ES) John Reppy (University of Chicago, USA) Konstantinos Sagonas(Uppsala University, SE, and National Technical University of Athens, GR) Simon Thompson (University of Kent, UK) German Vidal(Universidad Polit'ecnica de Valencia, ES) SPONSORS Computer Science Faculty, Complutense University of Madrid Spanish Ministry of Science and Innovation ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] PhD Studentships in Functional Programming
Apologies for multiple copies. -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk +--+ PhD Studentships in Functional Programming School of Computer Science University of Nottingham, UK The Functional Programming Lab (FP Lab) in the School of Computer Science at the University of Nottingham is seeking to appoint up to two new PhD students, starting on 1st October 2011. The topics for the studentships are open, but will be within the general area of functional programming. The studentships are for 3.5 years, include a maintenance grant of 13,590 UK pounds per year and UK/EU tuition fees, and are open to UK and EU applicants. Particularly strong candidates from outside the EU may also be considered, subject to additional funds being available. Applicants will require a first-class Honours degree (or equivalent) in Computer Science, Mathematics, and/or Physics, experience in functional programming, and an aptitude for mathematical subjects. A higher degree (e.g. Masters) would be desirable. Additionally, experience in one or more of the following will be particularly welcome: formal semantics, type theory, program verification, theorem provers, domain-specific languages, languages for physical modelling, programming language implementation and tools. Successful applicants will work under the supervision of Dr Graham Hutton or Dr Henrik Nilsson in the FP Lab in Nottingham, a leading centre for research on functional programming. The group currently comprises 5 academic staff, 1 research fellow, and 10 PhD students. In order to apply, please submit the following to Dr Graham Hutton (g...@cs.nott.ac.uk) or Dr Henrik Nilsson (n...@cs.nott.ac.uk) by 1st March 2011: an up-to-date copy of your CV (including the results of all your University examinations to date) along with a brief covering letter that describes your experience in functional programming, your reasons for wishing to pursue a PhD in this area, and any ideas you have regarding possible research directions. Note: applicants to the FP Lab should follow the procedure above, rather than applying directly to the School or University, e.g. in response to a general advert for PhD studentships. Closing date for applications: 1st March 2011. +--+ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] PhD Studentships in Functional Programming, Nottingham
Apologies for multiple copies. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk +--+ PhD Studentships in Functional Programming School of Computer Science University of Nottingham, UK The Functional Programming Lab (FP Lab) in the School of Computer Science at the University of Nottingham is seeking to appoint up to two new PhD students, starting on 1st October 2011. The topics for the studentships are open, but will be within the general area of functional programming. The studentships are for 3.5 years, include a maintenance grant of 13,590 UK pounds per year and UK/EU tuition fees, and are open to UK and EU applicants. Particularly strong candidates from outside the EU may also be considered, subject to additional funds being available. Applicants will require a first-class Honours degree (or equivalent) in Computer Science, Mathematics, and/or Physics, experience in functional programming, and an aptitude for mathematical subjects. A higher degree (e.g. Masters) would be desirable. Additionally, experience in one or more of the following will be particularly welcome: formal semantics, type theory, program verification, theorem provers, domain-specific languages, languages for physical modelling, programming language implementation and tools. Successful applicants will work under the supervision of Dr Graham Hutton or Dr Henrik Nilsson in the FP Lab in Nottingham, a leading centre for research on functional programming. The group currently comprises 5 academic staff, 1 research fellow, and 10 PhD students. In order to apply, please submit the following to Dr Graham Hutton (g...@cs.nott.ac.uk) or Dr Henrik Nilsson (n...@cs.nott.ac.uk) by 1st March 2011: an up-to-date copy of your CV (including the results of all your University examinations to date) along with a brief covering letter that describes your experience in functional programming, your reasons for wishing to pursue a PhD in this area, and any ideas you have regarding possible research directions. Note: applicants to the FP Lab should follow the procedure above, rather than applying directly to the School or University, e.g. in response to a general advert for PhD studentships. Closing date for applications: 1st March 2011. +--+ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] More work to be done re: haskell.org move?
Hi, Then posting the list of missing URLs here might alert those who care about them (or not, but at least fewer things would disappear silently). OK, here are a few broken links I happen to care about: Old Haskell Workshop proceedings, including the very first one. They are on the Haskell Symposium web page: http://www.haskell.org/haskell-symposium/ The links that do not work are: * The 1995 proceedings: http://www.haskell.org/haskell-workshop/1995/HW1995-Proceedings.pdf * The 2000 papers: http://www.haskell.org/haskell-workshop/2000/papers.html In the latter case, presumably the papers themselves also need to move across. And the links should perhaps be updated to point to haskell-symposium as well. (And no, as far as I can tell, it is not enough to to simply replace haskell-workshop with haskell-symposium.) There are a number of other broken proceedings dependences, but they are external. Additionally, all links for the Haskell Workshop web pages, from 1995 to 2007 inclusive, are broken. Also, the www.haskell.org/yampa page is gone. Very out of date, no doubt, but even so. Sorry, probably a FAQ, but this move has essentially passed me by: any way I can get at the old content before the old server is decommissioned? Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Quasi quoting
| But it'd remove | and | as a | valid operators, at least for quasiquote customers. I don't know | how bad that would be. | | Good brackets are scarce. I'd prefer to stick with one of the many | fine variations on [|...|] currently being discussed. I agree with this. My gut feel is to stick with [| ..|] and variants, and live with the fact that TH and QQ aren't using them in quite the same way. Seconded. Removing | and | as valid operators is potentially quite bad, in my opinion worse than the interference with the list comprehensions for quasiquote customers, because the operators may come from various external libraries that one really would like to use. The list comprehension interference is strictly confined to modules where quasiquoting is enabled. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Quasi quoting
Hi Simon, For all I know, no one is using quasi-quotation (although it's a very cool feature, thanks to Geoff Mainland), but I didn't think I should take it for granted! For info, My PhD student George Giorgidze and myself are using it for our EDSL Hydra for non-causal modelling and simulation of physical systems. Indeed, it is a very cool feature. Actually, for us, almost essential, as it gives us *principled* control over the syntax of the deep aspects of our embedding in a way that the usually embedding tricks just don't provide. We'll have a look. Thanks for letting us know! /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Quasi quoting
Hi all, Simon wrote (answering Robert Greayer): A variant of your suggestion would be: for any quote [|..blah..|] behave as if the programmer had written [quasiQuoter| ...blah...|]. That is, simply pick up whatever record named quasiQuoter is in scope. Then you'd say import Pads( quasiQuoter ) and away you go. But you can only use one at a time. Yes, I can see that (or one of the alternative forms proposed) would sometimes be convenient. But, being explicit about *which* syntax one is switching into does arguably enhance readability. Without this cue, the reader have to hunt for the appropriate binding before he or she can make sense of a piece of quasiquoted text. Also, as Simon suggests, being explicit makes it possible to use more than one quasiquoter at a time (in one module). Potentially quite useful. I can see being explicit about which quasiquoterbeing to use would be a bit of an issue in a setting with lots of very small fragments being spliced in all over the place. But at least in our experience, and what we've seen in Geoffrey's papers, quiasiquoted code fragments tend to be relatively substantial, where naming the quasiquoter doesn't add much overhead at all. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposal: FirstClassFieldUpdates
Hi all,
Jon Fairbairn jon.fairba...@cl.cam.ac.uk wrote:
Isaac Dupree m...@isaac.cedarswampstudios.org wrote:
yes it is, however field updates are occasionally slightly
annoying, since they can't change something's type at all,
IIRC. Say,
data C nx ny = C { x :: nx, y :: ny }
x_set :: nx2 - C nx1 ny - C nx2 ny
--x_set x2 c = c {x = x2} --type error
If that were the case, it would be a serious wart that needed to be
addressed. However, implementation would be fairly straightforward as
an extension is already present in ghc:
let x_set x2 c = c{x=x2}
:t x_set
x_set :: nx - C t ny - C nx ny
;-) (or did I misunderstand you?)
Indeed, field update can change the type, which I guess is the point
Jon is making. And Isaac's example above compiles without any problems
or extensions. H98 as far as I'm aware.
However, there are cases where the current field update facility
arguably isn't good enough, namely when there are more than one
constructor, some of which do not have certain of the fields. See
http://hackage.haskell.org/trac/haskell-prime/wiki/ExistingRecords
for examples, in particular Polymorphic Record Update take II.
As an aside, having revisited that discussion, I still think the idea of
being able to do an update for constructors that do NOT have
certain fields makes a lot of sense. The record wildcard extension,
that was mentioned as a possible workaround, seems far less appealing
and flexible. I don't even know what it would mean if it's used more
than once in a scope, e.g. what about the following:
f (C1 {a = 1, ..}) (C2 {b = 2, ..}) =
(C1 {a = 10, ..}, C2 {b = 20, ..})
???
Best,
/Henrik
--
Henrik Nilsson
School of Computer Science
The University of Nottingham
n...@cs.nott.ac.uk
This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] Yampa vs. Reactive
Hi Tom, In reactive, one doesn't. All behaviors and events have the same absolute 0 value for time. Right. I believe the possibility of starting behaviors later is quite important. And from what Conal wrote in a related mail, I take it that this is recognized, and that this capability is something that is being considered for reactive? Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Yampa vs. Reactive
continuous time. On the other hand, ANY implementation will have to do sampling at some point. But I suppose what you're saying is that Reactive allows different part of a system to be sampled at different rates in a transparent manner? Which is nice. But the tradeoffs are not clear to me. * Reactive is push based. The result of this is that we will not waste CPU cycles for example refreshing the screen when nothing has changed on the output. The optimizations of Yampa also achieves a fair amount of pushing. But granted, Yampa is fundamentally pull-based. That said, for truly hybrid systems, that do a lot of continuous computation, it is not at all clear that push is a clear winner. Only extensive benchmarking can really provide genuine insight into the actual pros and cons here of different FRP implementations for various applications, I'd say. Also, when there is a need to combine output from different parts of a system, and this is done by combining the various outputs into a tuple or record, then one have to push combined output whenever any one of the constituent parts changes, which means one lose track of the changes down the line, possibly resulting in redundant computations anyway. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Yampa vs. Reactive
Hi Tom, I don't think this is really true. Behaviors and Events do not reveal in their type definitions any relation to any system that they may or may not exist in. OK. So how does e.g. mousePoint :: Behavior Point get at the mouse input? unsafePerformIO? I.e. it is conceptually a global signal? I'm not sure I understand you clearly. If I wish to apply a constant function to a signal, can I not just use fmap? The question is why I would want to (conceptually). I'm just saying I find it good and useful to be able to easily mix static values and computations and signals and computations on signals. You would certainly need to ask Conal on this point, but I have no reason to suspect that b' = [1,2,3,4,5] `stepper` listE [(1,[])] would not deallocate the first list once it had taken its step. It's not the lists that concern me, nor getting rid of a collection of behaviors all at once. The problem is if we ant to run a collection of behaviors in parallel, all potentially accumulating internal state, how do we add/delete individual behaviors to/from that collection, without disturbing the others? For the sake of argument, say we have the following list of behaviours: [integral time, integral (2 * time), integral (3 * time)] We turn them into a single behavior with a list output in order to run them. After one second the output is thus [1,2,3] Now, we want to delete the second behavior, but continue to run the other two, so that the output at time 2 is [2,6] Simply mapping postprocessing that just drops the second element from the output isn't a satisfactory solution. let n :: Behavior Int n = behaviour that counts left mouse button clicks in n `until` some event -= n I'm not sure I got the syntax right. But the idea is that we output the number of left mouse button clicks, and then at some point, we switch to a behavior that again output the number of left mouse button clicks, notionally the same one n. The question is, after the switch, do we observe a count that continues from where the old one left off, i.e. is there a single *shared* instance of n that is merely being *observed* from within the two branches of the switch, or is the counting behavior n restarted (from 0) after the switch? Yes, we really do get a shared n -- without doing that we certainly would see a large space/time leak. Interesting, although I don't see why not sharing would imply a space/time leak: if the behavior is simply restarted, there is no catchup computation to do, nor any old input to hang onto, so there is neither a time nor a space-leak? Anyway, let's explore this example a bit further. Suppose lbp is the signal of left button presses, and that we can count them by count lbp Then the question is if let n :: Behavior Int n = count lbp in n `until` some event -= n means the same as (count lbp) `until` some event -= (count lbp) If no, then Reactive is not referentially transparent, as we manifestly cannot reason equationally. If yes, the question is how to express a counting that starts over after the switch (which sometimes is what is needed). Yep, such Behaviors are seperated in Reactive only by the method you create them with. I may use the `stepper` function to create a behavior that increases in steps based on an event occurring, or I may use fmap over time to create a continuously varying Behavior. But the question was not about events vs continuous signals. The question is, what is a behavior conceptually, and when is it started? E.g. in the example above, at what point do the various instances of count lbp start counting? Or are the various instances of count lbp actually only one? Or if you prefer, are beahviours really signals, that conceptually start running all at once at a common time 0 when the system starts? The answers regarding input behaviors like mousePosition, that n is shared, and the need to do catchup computations all seem to indicate this. But if so, that leaves open an important question on expressivity, examplified by how to start counting from the time of a switch above, and makes if virtually impossible to avoid time and space leaks in general, at least in an embedded setting. After all, something like count lbp can be compiled into a function that potentially may be invoked at some point. And as long as this possibility exists, the system needs to hang on to the entire history of mouse clicks so that they can be coounted at some future point if necessary. These are all questions that go back to classical FRP, which we didn't find any good answers to back then, and which also were part of the motivation for moving to AFRP/Yampa. If Reactive has come up with better answers, that would be very exciting indeed! Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message has been checked
Re: [Haskell-cafe] Yampa vs. Reactive
Hi Tom, I'm not sure why mapping the function is not satisfactory -- It would create a new Behavior, who's internals contain only the two elements from the list -- that would expose to the garbage collector that the second element has no reference from this behavior any more, and thus the whole behavior could be collected. We must be talking at cross purposes here: there is no way that deleting the *output* from one of the behaviours from a list of outputs would cause the underlying behavior whose output no longer is observed to be garbage collected. After all, that list of three numbers is just a normal value: why should removing one of its elements, so to speak, affect the producer of the list? But if we have a list of running behaviors or signals, and that list is changed, then yes, of course we get the desired behavior (this is what Yampa does). So maybe that's what you mean? That's a yes. My first answer to how to implement the resetting counter would be someting along the lines of this, but I'm not certain it's dead right: e = (1+) $ mouseClick e' = (const 0) $ some event b = accumB 0 (e `mappend` e') i.e. b is the behavior got by adding 1 every time the mouse click event occurs, but resetting to 0 whenever some event occurs. Hmm. Looks somewhat complicated to me. Anyway, it doesn't really answer the fundamental question: how does one start a behavior/signal function at a particular point in time? I consider the fact that Yampa, through supporting both signals and signal functions, provides simple yet flexible answers to the question when a signal function starts to be one of its key strengths over Classical FRP and maybe then also over Reactive. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Yampa vs. Reactive
is similar in style to Classical FRP, I think Reactive also needs to address those questions. All the best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implementing PacMan
Hi, What do we think of this, folks? http://prog21.dadgum.com/23.html (And the rest in the series, obviously.) To me, it seems that this plan would *work*... but it wouldn't be very eligant. You'd have the code to respond to user input and move PacMan in one place, the code for collision detection in other place, the code that decides what to *do* about a collision somewhere else, the code for drawing the animations in yet another place... If you wanted to change one game element, you'd have to make changes scattered all over the place. The whole thing seems messy, non-modular and non-composible to my ears. Thoughts, people? Functional Reactive Programming (FRP) tends to, in principle, work pretty well for this kind of application. At least it allows for code that is very modular in many ways, includig when it comes to the game state. See e.g. the paper The Yampa Arcade or the Haskell game Frag which uses FRP for the game logic: http://www.haskell.org/haskellwiki/Frag The page you referred to didn't seem to consider FRP? Don't know if FRP would address all of your concerns. But as to collisions, we can observe that this involves two or more entities and is, from the perspective of each entity, something external. Thus I don't think it's unreasonable that code handling collision detection is done somewhere else, meaning outside the code describing the game entities themselves. As to how to respond to collisions, that can be a great deal trickier, and may involve devising suitable interfaces to allow the proper interaction of a set of object to be computed, e.g. in a physical simulation, the masses and velocities of the involved objects must be known. There was an interesting article about building a Physics Engine in Haskell in issue 12 of the monad reader that touched on physical collision detection and response: http://www.haskell.org/sitewiki/images/f/f0/TMR-Issue12.pdf For a game like PacMan, I should think collision response is fairly straightforward, though! Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Abusing quickcheck to check existential properties
On Sun, 19 Oct 2008 00:39:32 +0200, Norman Ramsey [EMAIL PROTECTED] wrote: I guess what I would like is to reuse most of the mechanisms in QuickCheck to have it say one of these two things: 1. Found an satisfying instance after 73 tries: [gives instance] 2. After 100 tries, could not find a satisfying instance. Like failure, the first tells you something definite about your program. And like passing 100 tests, the second tells you nothing. In ScalaCheck (QuickCheck for Scala, www.scalacheck.org) there is an exists combinator which naively tries to find a value satisfying the property. So you can do the following: val p = exists(arbitrary[Int])( n = (n 0) == (n+n == n*n) ) scala p.check + OK, proved property. ARG_0: 2 val q = exists(arbitrary[Int])( n = (n 10) == (n+n == n*n) ) scala q.check ! Gave up after only 0 passed tests. 500 tests were discarded. As you can see, there is a notion of proved properties in ScalaCheck, which was introduced to support the exists method. Of course, if the property is non-trivial ScalaCheck has a hard time finding a proof. Regards, Rickard Nilsson ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] 2 modules in one file
Hi, Yitzchak Gale wrote: But for large and complex projects, this policy really complicates the task of the project manager who wants to be able to present various views of the source to teams working on different subprojects, while juggling the version control in an intelligent way. Directory tree structure is sometimes the perfect tool for that, but Haskell has stolen it away. It would be nice if compilers would offer, as an optional alternative, a system of locating modules based on manifest files. That would then allow multiple modules per source file. Not that it is of any practical relevance now, but this was exactly the thinking behind the design (some 10 - 15 years ago, time flies!) of how Freja manages files and modules, as Malcolm mentioned. I believe a clear separation between a language and aspects of the environment in which programs are developed, such as file systems, is a good thing. And while the Haskell standard as such respects this, I've always found the fact that most tools rely on naming conventions for mapping names of modules to names of files very unfortunate. Hierarchical modules makes this even worse: what says that I necessarily want the module hierarchy reflected in the directory hierarchy? And indeed, as Yitzchak said, what about non-hierarchical file systems, or maybe storing source code by completely different means? And there are also potential issues with not every legal module name being a legal file name across all possible file systems. So, yes, a system of locating modules based on manifest files would be great. I'd use it all the time whenever possible, and never look back! Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Meta-point: backward compatibility
Hi all, Manuel wrote: As I have argued before on the committee list, I also think we should *not* worry about backwards incompatible changes too much in cases where a simple automatic translation from H98 to H' code is possible. Yes, tools can and should help with migration, and we should keep that in mind. In particular, complicated language design to incorporate new features while maintaining backwards compatibility should be avoided where old code and new code easily can be made to work together through a compiler compatibility flag. (The discussion on records/labelled fields spring to mind.) However, I still think it is important to be conservative when it comes to breaking changes and either only consider them when the impact really would be very small, or when it is agreed it is a really important change. Even if there are tools to help with code, effort is still involved to fix the breaks, and thus it ought to be completely clear that the effort is worth it. And there is not only code: there are papers and books too! And finally, unless we're fairly strict, we'll be bogged down in a flood of discussion on gratuitous and ultimately rather superficial changes. The associativity of $ is a case in point. So, the criteria I proposed still seem quite reasonable to me. But I'm biased, of course! :-) /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Infix type and function definitions
Hi, Simon PJ wrote (Re: BangPatterns: probably accept == undecided): Not allowing infix functions on the LHS would be a notable simplification. And a little later (Re: Infix type constructors): What we *want* is to say data a + b = Left a | Right b That is, we want to define the type *constructor* (+) Just to clarify, issues of what names can be used for type constructors aside, are you proposing dropping infix syntax for defining functions, but retaining infix syntax for defining types (and type families etc.)? Or would the last example have to be written data (+) a b = Left a | Right b ? All the best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): proposal: remove string gaps
Mon Mar 31 15:26:03 PDT 2008 Simon Marlow [EMAIL PROTECTED] * proposal: remove string gaps Hm. This has escaped me. I don't find the rationale as documented on the Wikipage http://hackage.haskell.org/trac/haskell-prime/wiki/RemoveStringGaps very convincing at all. I've thus added a few more cons: * string gaps are sometimes really helpful for formatting/pretty printing code neatly; the ++ alternative often necessecitates additional bracketing * the simplification of the lexical syntax is very minor * arguably, the syntax highlighting ought to be fixed as that's what at fault, not the language as such I have to confess I find string gaps rather elegant, and I think any sensible language ought to have them! /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): proposal: remove string gaps
Hi Neil, If you have two features battling each other, you probably need to remove one of them. CPP isn't going to be removed, which kind of forces the issue... Well, for the record, I've used both CPP and string gaps extensively. And all I've done is to be careful to run CPP only where needed (and avoid string gaps there), which seems rather sensible to me anyway, string gaps or not. If various build-systems make selective CPP-ing hard, then I'd definitely argue that the build systems ought to be fixed (I can't believe that would be terribly hard: I've at least done it successfully using make. Not much fun, admittedly, but entirely feasible. Should be much simpler in the context of a more principled, Haskell-oriented build system.) If you have two features battling each other, you probably need to remove one of them. CPP isn't going to be removed, which kind of forces the issue... Well, first of all, I don't think CPP is a feature of Haskell. I do see your point from a pragmatic perspective, but I would argue that auxiliary tool issues (be it CPP, syntax highlighting, or what have you) should be of secondary concern when it comes to language design. As to CPP and Haskell in general, as a matter of principle, I think it's a bad idea to run a preprocessor intended for one very different language on programs of another. Cpphs makes much more sense. However, an advanced Haskell user who thinks CPP is necessary, should understand the implications and take appropriate precautions. So, I still don't find the rationale for removing string gaps very compelling, I'm afraid! Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): proposal: remove string gaps
I wonder if I should suggest removing all those strange ascii esacpe sequences next... Well, in contrast to string gaps, I don't think I've ever used those! /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] Yampa / AFRPVectorSpace.hs
Hi Peter, Oops! Yes, as Paul says, clearly an error. My best guess is that it was commented out at some point for testing something, and then forgotten! The error does not occur in my local copy of the code, so a version skew problem to boot, I'm afraid. Best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
Hi Peter, About continuous time; it is in fact, not really continuous is it, since floats are used to approximate time. So the longer your program runs, the less accurate an absolute time value will become no? Well, yes and no. Yampa, at least, does not use absolute time internally, only time deltas, so the problem you describe only occurs if the programmer *explicitly* choose to accumulate absolute time, or *explicitly* make use of very large relative time intervals (e.g. combinators like after that emits an event after a given, relative, time interval). So, as always with floating point, or with any finite representation of numbers, the programmer has to understand the limitations and implications of the chosen representation. But this is not any inherent flaw of FRP or its Yampa incarnation as such. One could also imagine using some infinite-precision number representation with FRP instead of floating point. The fact that Yampa uses floating point is merely a pragmatic implementation choice. I believe I also saw someone asking about Modelica in this context. Modelica is a hybrid modelling and simulation language. Efficient simulation and accurate results are of key importance, and for that reason Modelica implementations use sophisticated numerical and symbolic methods. Unfortunately, this also limits the expressiveness of the language. In particular, Modelica cannot handle systems with highly dynamic structure like video games. Thus I don't think we'll see video games written purely in languages like Modelica any time soon, even if there is active research on making such languages cope better with structurally dynamic systems. (One could probably imagine using Modelica for handling game physics, though, i.e. as a component of a games programming suite.) Best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] Final APLAS'07 CFP
On Behalf of Zhong Shao. Sorry for any duplicates! /Henrik -- Title: Final APLAS 2007 CFP (Deadline: June 15, 2007) [Recent updates: (1) Submission site is now open: http://www.easychair.org/APLAS2007 (2) New info about invited speakers. (3) Deadline is just 3-week away. ] -- The Fifth ASIAN Symposium on Programming Languages and Systems (APLAS 2007) CALL FOR PAPERS Singapore November 29 - December 1, 2007 http://flint.cs.yale.edu/aplas2007/ APLAS aims at stimulating programming language research by providing a forum for the presentation of recent results and the exchange of ideas and experience in topics concerned with programming languages and systems. APLAS is based in Asia, but is an international forum that serves the worldwide programming languages community. The APLAS series is sponsored by the Asian Association for Foundation of Software (AAFS), which has recently been founded by Asian researchers in cooperation with many researchers from Europe and the USA. The past formal APLAS symposiums were successfully held in Sydney (2006, Australia), Tsukuba (2005, Japan), Taipei (2004, Taiwan) and Beijing (2003, China) after three informal workshops held in Shanghai (2002, China), Daejeon (2001, Korea) and Singapore (2000). Proceedings of the past symposiums were published in Springer-Verlag's LNCS 2895, 3302, 3780, and 4279. TOPICS: The symposium is devoted to both foundational and practical issues in programming languages and systems. Papers are solicited on, but not limited, to the following topics: * semantics, logics, foundational theory * type systems, language design * program analysis, optimization, transformation * software security, safety, verification * compiler systems, interpreters, abstract machines * domain-specific languages and systems * programming tools and environments Original results that bear on these and related topics are solicited. Papers investigating novel uses and applications of language systems are especially encouraged. Authors concerned about the appropriateness of a topic are welcome to consult with the program chair [EMAIL PROTECTED] prior to submission. INVITED SPEAKERS: Vincent Danos(University of Paris VII CNRS, France) Sriram Rajamani (Microsoft Research, India) Vijay Saraswat (IBM TJ Watson Research Lab, USA) IMPORTANT DATES: Paper Submission Deadline: 11:00 AM (in Samoan Time), June 15, 2007 Author Notification: August 17, 2007 Camera Ready:September 7, 2007 Conference: November 29-December 1, 2007 SUBMISSIONS INFORMATION: Papers should be submitted electronically online via the conference submission web page at URL http://www.easychair.org/APLAS2007. Acceptable formats are PostScript or PDF, viewable by Ghostview or Acrobat Reader. Submissions should not exceed 16 pages in LNCS format, including bibliography and figures. Submitted papers will be judged on the basis of significance, relevance, correctness, originality, and clarity. They should clearly identify what has been accomplished and why it is significant. Submitted papers must be unpublished and not submitted for publication elsewhere. The proceedings of the symposium is planned to be published as a volume in Springer-Verlag's Lecture Notes in Computer Science series. GENERAL CHAIR Joxan Jaffar (National University of Singapore, Singapore) PROGRAM CHAIR Zhong Shao (Yale University, USA) PROGRAM COMMITTEE Lars Birkedal (IT University of Copenhagen, Denmark) Martin Hofmann (Univ of Munich, Germany) Kohei Honda(Queen Mary, University of London, UK) Atsushi Igarashi (Kyoto University, Japan) Suresh Jagannathan (Purdue University, USA) Annie Liu (State University of New York at Stony Brook, USA) Shin-Cheng Mu (Academia Sinica, Taiwan) Henrik Nilsson (University of Nottingham, UK) Michael Norrish(NICTA, Australia) Jens Palsberg (University of California, Los Angeles, USA) G. Ramalingam (Microsoft Research, India) Zhong Shao (Yale University, USA) Zhendong Su(University of California, Davis, USA) Martin Sulzmann(National University of Singapore, Singapore) Eijiro Sumii (Tohoku University, Japan) Jérôme Vouillon(CNRS, France) Kwangkeun Yi (Seoul National University, Korea) Jian Zhang (Chinese Academy of Sciences, China) LOCAL ARRANGEMENT CHAIR Wei-Ngan Chin (National University of Singapore, Singapore) -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses
[Haskell] APLAS'07 CFP
Posted on behalf of Zhong Shao - The Fifth ASIAN Symposium on Programming Languages and Systems (APLAS 2007) CALL FOR PAPERS Singapore November 29 - December 1, 2007 http://flint.cs.yale.edu/aplas2007/ APLAS aims at stimulating programming language research by providing a forum for the presentation of recent results and the exchange of ideas and experience in topics concerned with programming languages and systems. APLAS is based in Asia, but is an international forum that serves the worldwide programming languages community. The APLAS series is sponsored by the Asian Association for Foundation of Software (AAFS), which has recently been founded by Asian researchers in cooperation with many researchers from Europe and the USA. The past formal APLAS symposiums were successfully held in Sydney (2006, Australia), Tsukuba (2005, Japan), Taipei (2004, Taiwan) and Beijing (2003, China) after three informal workshops held in Shanghai (2002, China), Daejeon (2001, Korea) and Singapore (2000). Proceedings of the past symposiums were published in Springer-Verlag's LNCS 2895, 3302, 3780, and 4279. TOPICS: The symposium is devoted to both foundational and practical issues in programming languages and systems. Papers are solicited on, but not limited, to the following topics: * semantics, logics, foundational theory * type systems, language design * program analysis, optimization, transformation * software security, safety, verification * compiler systems, interpreters, abstract machines * domain-specific languages and systems * programming tools and environments Original results that bear on these and related topics are solicited. Papers investigating novel uses and applications of language systems are especially encouraged. Authors concerned about the appropriateness of a topic are welcome to consult with the program chair ([EMAIL PROTECTED]) prior to submission. IMPORTANT DATES: Paper Submission Deadline: 11:00 AM (in Samoan Time), June 15, 2007 Author Notification: August 17, 2007 Camera Ready:September 7, 2007 Conference: November 29-December 1, 2007 SUBMISSIONS INFORMATION: Papers should be submitted electronically online via the conference submission webpage. Acceptable formats are PostScript or PDF, viewable by Ghostview or Acrobat Reader. Submissions should not exceed 16 pages in LNCS format, including bibliography and figures. Submitted papers will be judged on the basis of significance, relevance, correctness, originality, and clarity. They should clearly identify what has been accomplished and why it is significant. Submitted papers must be unpublished and not submitted for publication elsewhere. The proceedings of the symposium is planned to be published as a volume in Springer-Verlag's Lecture Notes in Computer Science series. GENERAL CHAIR Joxan Jaffar (National University of Singapore, Singapore) PROGRAM CHAIR Zhong Shao (Yale University, USA) PROGRAM COMMITTEE Lars Birkedal (IT University of Copenhagen, Denmark) Martin Hofmann (Univ of Munich, Germany) Kohei Honda(Queen Mary, University of London, UK) Atsushi Igarashi (Kyoto University, Japan) Suresh Jagannathan (Purdue University, USA) Annie Liu (State University of New York at Stony Brook, USA) Shin-Cheng Mu (Academia Sinica, Taiwan) Henrik Nilsson (University of Nottingham, UK) Michael Norrish(NICTA, Australia) Jens Palsberg (University of California, Los Angeles, USA) G. Ramalingam (Microsoft Research, India) Zhong Shao (Yale University, USA) Zhendong Su(University of California, Davis, USA) Martin Sulzmann(National University of Singapore, Singapore) Eijiro Sumii (Tohoku University, Japan) Jrme Vouillon(CNRS, France) Kwangkeun Yi (Seoul National University, Korea) Jian Zhang (Chinese Academy of Sciences, China) LOCAL ARRANGEMENT CHAIR Wei-Ngan Chin (National University of Singapore, Singapore) -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] PhD Position, the University of Nottingham
Postgraduate Research in Functional Hybrid Modelling School of Computer Science and IT University of Nottingham The University of Nottingham has an open position for a PhD student to work on EPSRC-funded project called Functional Hybrid Modelling, running for three years. This is a project at the intersection of, on the one hand, programming language semantics, design, and implementation, and, on the other, hybrid modelling and simulation. The ideal applicant would have a first- or upper-second class honours degree or equivalent in Computer Science (or possibly other area of direct relevance to the project), along with expertise in one or more of the following: * functional programming; * semantics, design, and implementation of (declarative) languages; * techniques for (hybrid) modelling and simulation, and related fields of mathematics (numerical methods, numerical analysis, calculus, linear algebra); * modelling and simulation of physical systems. The position is open to UK and EU applicants, but particularly strong applicants from outside the EU may also be considered, subject to the possibilities of securing additional funding. The successful applicant will work within the Foundations of Programming group at the School of Computer Science and IT: http://www.cs.nott.ac.uk/Research/fop/ The group currently comprise 7 academic staff, 5 research staff, and 14 research students. The research areas of the group include Algebra of Programming, Functional Programming (theory and practice), and Logic in Computer Science. The group is a founder member of the Midlands Graduate School in the Foundations of Computer Science, which provides postgraduate courses for PhD students in theoretical computer science. For further information on the studentship and the project, please contact Henrik Nilsson: [EMAIL PROTECTED] http://www.cs.nott.ac.uk/~nhn -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] modelling problem
Dear Kurt, I'm trying, more as a first excercise in Haskell than anything else, to code a simulation framework in Haskell. I don't have the time to respond to your mail in detail right now, but you might want to have a look at the work on Fran (functional reactive animation), FRP (Functional Reactive Programming), and Yampa, all very much related to the application area you're interested in. E.g. see http://www.haskell.org/frp/ All the best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GADTs vs arrows/typeclasses
Dear all, S. Alexander Jacobson wrote: I don't think I'm the only one confused here. Henrik Nilson in his paper on adding GADTs to Yampa comments that: ... In particular, GADTs are just what is needed to address the problem discussed above since the key idea is to allow constructors that have more specific types than usual, and to take that extra type information into account in individual case branches. GADTs would no doubt also offer an interesting alternative to the methods described by Baars and Swierstra [1] and Hughes [19]. [1] and [19] are papers about Arrows. I categorically deny being confused! :-) The comment refers to the methods Baars, Swierstra, and Hughes employ to encode type equality in order to be able to perform optimizations along similar lines as outlined in my paper. I was not at all proposing to use GADTs in place of arrows, and I cannot really see how the quote can be read as suggesting that. As Neil has already said: GADTs and arrows are just different kinds of entities. Best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Indentation of If-Then-Else
Dear All, Henning Thielmann wrote: I object strongly to the proposal http://hackage.haskell.org/trac/haskell-prime/wiki/DoAndIfThenElse because it solves problems with syntactic sugar with even more sugar, where no sugar is needed at all. In order to solve the trouble I propose enhancements to teachers, compilers and standard libraries: 1. 'if' syntax should be teached as if a then b else c This indentation makes pretty clear, what is condition, and what is the result in both cases. People obviously have different opinions here, and I'd say there are perfectly reasonable arguments for a number of different styles of indentation. As the discussion following Henning's mail has demonstrated. The background to the proposal was that Haskell 98 prevents an arguably reasonable style of indentation, and that this has turned out to be a problem in practice: i.e. it tends to trip up a lot of unsuspecting people, in particular beginners. Yes, one can argue that they should learn the right way, but this is really a very minor detail that many think would be best if people didn't have to worry about in the first place. The proposal is actually very lightweight (just allow an optional ; in the appropriate place), and thus it is not even a question about new syntactic sugar. At least not according to my understanding of the term. Also, it does not complicate the (already complicated) layout rules further, which is quite important. If I recall correctly, the proposal was implemented in GHC (and JHC?) shortly after it had been put forward, with very little effort indeed, and has not caused any ill side effects that I'm aware of. 3. If a compiler suspects that a parsing problem is related to 'do' and 'if' it should suggest indentation if a then b else c or even better, the usage of if- or (?)-function. As a matter of principle, I don't think a language standard should say much if anything about how a conforming compiler or interpreter should report errors. We can argue the pros and cons of the existing if syntax, but I don't think anyone is seriously proposing that it be dropped from Haskell' (that would break an awful lot of code for very little gain). Having additional functions that accomplish the same thing as if does not seem all that appealing to me at least. So, please add this to the 'Cons' list. Henning, I'm afraid I don't quite understand what the conses are? Could you clarify the concrete ill effects of the proposal, please? Best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Indentation of If-Then-Else
Yes, one can argue that they should learn the right way, but this is really a very minor detail that many think would be best if people didn't have to worry about in the first place. There are too much of these minor details. Yes! Which is why this fix is good, as it means people don't have to worry about that particular detail! I'm currently concerned with HTML - much more exceptions than rules. This is no fun, and Haskell's syntax will go the same way. Let if-then-else in Haskell for compatibility reasons, Many would agree that Haskell is getting large and complicated, but I suspect most people would not blame if-then-else. It is true, of course, that special syntax for if-then-else is not needed. But the same can be said for most of Haskell. One could argue that all you really need is a very small core language. So it boils down to finding the right balance between convenience, readability, size of the language, and many other things. And inevitably, there are going to be very different opinions about what the right balance is. Lisp/Scheme are languages with very little special syntax. I used to use Lisp quite a lot. But I'm not sure the lack of e.g. predefined control structures made Lisp code that much easier to write and understand, to be honest. On the contrary, in fact, as one had to learn libraries of (basic) control-structures on top of the base language. Nor did it necessarily make the life easier for people who built the tools, as e.g. Pretty Printers were expected to identify applications of special functions and lay them out in a different way for the sake of readability. (And probably just by looking at the name of the function, and hoping that it meant what it usually meant ...) But I digress. and try to get rid of it until Haskell-2. But do not endorse its use by new extensions. I don't think an optional semicolon or two counts as an extension. It really just is a trivial fix. Nor do I think leaving things as they are would do anything in itself to deprecate the use of if-then-else, if that indeed turns out to be where we'd like to go. Cons are: The sketched problem with indentation can be solved without touching the language. Well, only if one agrees that a particular style of indenting if-then-else is necessary in the context of a do, but not elsewhere. The syntax extension is unnecessary, thus complicates all language tools without need. I'll add that a recommendation for improved error messages has been suggested as an alternative remedy. /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
[Haskell] Proceedings Haskell Workshop 1995
Dear Haskellers, In celebration of the 10th Haskell Workshop, that took place in Portland, Oregon, on the 17th September 2006, the proceedings of the very first Haskell workshop, in La Jolla 1995, have now been made available off the Haskell Workshop home page: www.haskell.org/haskell-workshop/1995 Thanks to Paul Hudak for helping locating the proceedings and arranging for them to be scanned into PDF. All the best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Yampa Arcade
Hi Dominic, Does anyone know where the source code for Yampa Arcade can be found? It's included with the (now very old) afrp-0.4 distribution available from www.haskell.org/yampa It's in the examples/SpaceInvaders directory. Hope that helps! All the best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Class System current status
Hi all, Stephanie wrote: Simon, Why is an Appendix is better than just a footnote in the Standard that says we aren't sure, one way or the other, whether FDs will stay in the language for ever. Why do we need this extra structure? I'm worried that this extra structure could be confusing. In particular, if someone says this program is pure Haskell' what will that mean? In practice, will it be clear whether pure Haskell' includes the Appendix? I agree with this. If there is a need to make it clear that some features are particularly likely to change, I can't see why that cannot be achieved in the main body of the report. Through a foot note, or through a highlighted paragraph of some kind. I worry that tearing apart closely related topics is going to be difficult as well as resulting in a confusing and somewhat unstructured report. The appendix idea has also been mentioned in other contexts, specifically for records, and I don't like it there either for the same reasons. Best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org//mailman/listinfo/haskell-prime
Re: collecting requirements for FDs
Dear all, Ross Peterson wrote: The favourite customer for FDs has been the monad transformer library. ... What other libraries should Haskell' support, and what are their requirements? Here are some classes from Yampa/earlier versions of FRP. I shouldn't think they're particularly demanding. Also, I'm not saying these classes could not be defined differently/better. They are just examples of what seems to me reasonable uses of FDs. - -- Minimal instance: zeroVector, (*^), (^+^), dot class Floating a = VectorSpace v a | v - a where zeroVector :: v (*^) :: a - v - v (^/) :: v - a - v negateVector :: v - v (^+^):: v - v - v (^-^):: v - v - v dot :: v - v - a norm :: v - a normalize:: v - v -- -- Minimal instance: origin, .+^, .^. class (Floating a, VectorSpace v a) = AffineSpace p v a | p - v, v - a where origin :: p (.+^):: p - v - p (.-^):: p - v - p (.-.):: p - p - v distance :: p - p - a -- From an old version of FRP: FRPCore.lhs: class MixSwitchable s a b | s a - b where FRPCore.lhs: class Switchable s i | s - i where FRPCore.lhs: class RunningIn a b i | a - i where FRPCore.lhs: class ImpAs a b | a - b where FRPTask.lhs: class RunningInTask a t i | a t - i where FRPTask.lhs: class Monad m = StateMonad s m | m - s where FRPTask.lhs: class Monad m = EnvMonad env m | m - env where FRPTask.lhs: class GTask t = MsgTask t m | t - m where FRPTask.lhs: class MsgTaskMap mt m nt n | mt - m, nt - n where /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: MPTCs and functional dependencies
Hi all, Manuel Chakravarty wrote: My conclusion is that we should not include FDs or ATs into the standard at the moment. Standardising FDs as a stopgap measure may easily put us into the same situation that we are having with records at the moment. Nobody is really happy with it, but we don't dare to change it either. Martin Sulzmann The situation here is clearly different. Whatever comes next (after FDs) will be a conservative extension. So, standardising FDs is a good thing because they have proven to be a useful (somewhat essential for MPTCs) feature. Hence, I will go with Simon: H' should have MPTC + FDs, but not ATs. I basically agree with Simon PJ and Martin: MPTCs are necessary for H', and MPTCs pretty much necessitates at least some limited form of FD/AT. Thus I view FD/AT as so important, that I think it is a secondary concern if it ends up being a stop gap measure. Moreover, it seems to me that FD/AT declarations in practical applications amounts to very little code. Thus, the likely work impact if FD/AT is completely replaced with some other mechanism providing the same functionality should be very limited. This is unlike records, say, where record notation is likely to be used pretty much throughout an application. Also, the alternative of NOT having FD/AT would seem to lead to rather convoluted solutions in many cases, so the work of adapting non FD/AT MPTC code to an hypotetical H'' setting where an FD/AT replacement is available, is potentially quite big. But of couse, the above discussion on likely change impact is just my gut feeling. My key argument is that MPTCs and thus some form of FDs/ATs are really important in practice. All the best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: quoting in error messages
What do others think? It'd be dead easy to replace `thing' by thing in GHC's error messages, if that's what a majority want. Double quotes looks preferable to me. All the best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[Haskell] TFP2006: Call for Participation
Dear Colleague, Please find enclosed the call for participation in Trends in Functional Programming (TFP) 2006. Registration deadline: 17 March. My apologies for duplicate copies. Best regards, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. TFP 2006 Seventh Symposium on Trends in Functional Programming Nottingham, UK, 19 - 21 April, 2006 http://www.cs.nott.ac.uk/~nhn/TFP2006 Co-located with Types 2006 and Spring School on Datatype-Generic Programming CALL FOR PARTICIPATION ABOUT TFP 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 papers presented at the symposium for publication in a high-profile volume. 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, in Munich, Germany in 2004, and in Tallinn, Estonia in 2005 (co-located with ICFP and GPCE). For further general information about TFP, see http://www.tifp.org/. PROGRAMME The list of papers accepted for presentation at TFP 2006 is available via the TFP 2006 website: http://www.cs.nott.ac.uk/~nhn/TFP2006/TFP2006-TalkList.html REGISTRATION TFP 2006 takes place Nottingham, UK, 19 - 21 April. It is co-located with Types 2006 (18 - 21 April) and and the Spring School on Datatype-Generic Programming 2006. Registration is open. Deadline: 17 March, 2006 CO-LOCATION WITH TYPES 2006 AND DATATYPE-GENERIC PROGRAMMING 2006 TFP 2006 is co-located with Types 2006 (to be held 18 - 21 April). To take advantage of the synergies offered by these two complementary events, there are joint keynote speakers, joint sessions on topics of mutual interest, such as dependently typed functional programming, and common social events. The schedule will be arranged so that participants may freely move between parallel sessions of the two events. See http://www.cs.nott.ac.uk/types06/ for further details. TFP 2006 and Types 2006 are immediately followed by the Spring School on Datatype-Generic Programming 2006 (24 - 27 April), which should be of direct interest to many of the TFP and Types Participants. See http://www.cs.nott.ac.uk/ssdgp2006/ for further details. ORGANISATION Symposium Chair:Marko van Eekelen, Radboud University Nijmegen, NL Programme Chair:Henrik Nilsson, University of Nottingham, UK Treasurer: Greg Michaelson, Heriot-Watt University, UK Local Arrangements: Joel Wright, University of Nottingham, UK PROGRAMME COMMITTEE: o Kenichi Asai, Ochanomizu University o Gilles Barthes, INRIA, Sophia Antipolis o Olaf Chitil, University of Kent o Catherine Dubois, IIE, Evry o Marko van Eekelen, Radboud Universiteit Nijmegen o Jeremy Gibbons, Oxford University o Kevin Hammond, University of St Andrews o Zoltán Horváth, Eötvös Loránd University o Frank Huch, Christian-Albrechts-University of Kiel o Johan Jeuring, Universiteit Utrecht o Greg Michaelson, Heriot-Watt University o Henrik Nilsson, University of Nottingham o Ricardo Peña, Universidad Complutense de Madrid o Morten Rhiger, Roskilde University o Colin Runciman, University of York o Carsten Schürmann, IT University of Copenhagen o Zhong Shao, Yale University o Phil Trinder, Heriot-Watt University SPONSORS We are actively looking for additional TFP sponsors, who may help to subsidise attendance by research students, for example. 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 Symposium chair: Marko van Eekelen. Your students will be grateful! ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Module System
David Roundby wrote: I'd like to second this. I've been annoyed by the fact that ghc requires extra subdirectories in order to use hierarchical modules, and would be doubly annoyed if the language definition declared that this couldn't be fixed. jhc's behavior sounds nicer, but I'd rather there were the possibility of naming our haskell files whatever we liked. And I'd like to second that! But not a Haskell' issue (I hope). Best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Export lists in modules
Dear all, Malcolm wrote: As far as I can see, there is very little to change. Here is a concrete proposal. [...] Anyone see any difficulties? Georg asked: No, but one question: If the type signature is given in the export lists, is it then necessary (or even allowed) later on? I would vote for _not_ having it twice in the file. I'd in principle welcome the possibility to write type signatures in export lists. (I often write them there anyway, but as comments). But I admit I have not thought about what the caveats might be. If type signatures in export lists are allowed, I would hope it would be possible to put a type signature next to the actual definition as well, though, unless that would be terribly complicated for some reason (in which case I'd personally stick with the unannotated export list). /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Module System
Hi all, Georg Martius wrote: I have some proposals for changes of the hierarchical module system as it is at the moment. [...] The hierarchical name can be derived from the place in the filesystem. This is not a comment about the above proposal in itself, which arguably has its merits, but rather a meta comment. I get very anxious whenever I see the file system being mentioned in the context of a *language* specification (as opposed to, say, a specification of standard language libraries for interfacing with file systems). Some reasons: * File systems have all kinds of quirks one would rather not deal with in a language spec. * File systems can differ radically between different operating systems. In fact, even within an OS, as OS's these days tend to support many file systems simultaneously. * A valid module names in a language is not necessarily the same as a valid file name. (Yes, bijective mappings could be defined, but they would only be valid for a specific set of file systems.) * Even if we assume that the notion of a hierachical module name space always can be mapped to a corresponding file hierarchy in a simple way, why should that assumption be made in a language specification? In my opinion it is the task of the programming environment to locate the source files and interfaces that make up a semantically meaningful unit, and that semantics should be completely independent of where the different pieces happen to be stored. I'm already somewhat unhappy about the way most present Haskell tools map module names to path names (I'd generally prefer to have the possibility to flatten my file hierarchies by, say, using dots in my file names), but at least these assumptions are not in the Haskell 98 language definition. So, please, to the extent possible, let's keep the file system out of the Haskell' definition! All the best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: proposal: standardize interface to Haskell' implementations
Dear all, Claus Reinke wrote: what I have in mind are things to come, which would be quite different from the initial steps we could reasonably expect Haskell' to take. initially, a separate libary may be an acceptable start; but ultimately, I don't want two separate Haskell implementations shipped for each installation. for the moment, I'd like the Haskell' committe to say this is useful, and commit to making a start, then see how far we can get. I don't think anyone is saying a library like this would not be useful. at the very least, Language.Haskell needs to be expanded on, to cope with modules, to provide type information, and to cope with language extensions [...] But ultimately, there will be ramifications for future language definitions (how to pass from programs to representations and back? how to type these things? how to extend programs at runtime? [...] Simon M adds extensible data types to the list. I'm sure there's more, once we start looking. I find it interesting to note the the folks who claim this is a libary-only problem are willing to put up with lots of non-Haskell' hacks [...] I'd prefer to flush out these secret hacks hidden in so-called libraries, and to call a language feature a language feature. Point taken. However: 1. I'm sorry, but it seems to me that the scope of the project you are suggesting is just way beyond what possibly could fit within the Haskell' effort. 2. It seems the language features you would need standardized to be able to design suitably comprehensive and flexible library (like extensible data types) are also way beyond what we can hope to cover within the Haskell' effort. At this point it is not even clear what these features really are. Thus, if it at this point is can be convincingly argued that there is a small, well-defined set of some minor extensions that, if they were part of Haskell', would make it possible to do a substantially better job than the present Haskell.Language, then that case should be made. But, in my opinion, arguing that case must not amount to a complete library design: there just isn't time for that. Otherwise, I'm sure a separate effort to standardize an interface to Haskellwhatever, would yield some very valuable input to design of the next major version of Haskell. Yes, not doing that work as part of the Haskell' effort or in parallel with it, might mean that Haskell' isn't as future proof as it ideally should be. However, I think the next major Haskell revision is likely to include some changes that breaks backwards compatibility seriously anyway, so I am not too worried about that. All the best, /Henrik Ideals are like stars. You may never be able to reach them, but you can navigate by them. Not terribly accurately though, which is why they invented GPS. :-) -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: pattern synonyms
Dear all,
Conor wrote:
You forgot to define the term behaviour also. Pattern synonyms may be
used to construct as well as to match values.
Conor and I discussed this over lunch.
Specifically, we talked about whether the right hand side of a pattern
synonym would be any Haskell pattern (including _, ~, possibly !),
or restricted to the intersection between the patterns and terms, as
Conor propose that pattern synonyms also be used for construction.
By adopting some simple conventions, like replacing _ by undefined
when a synonym is used as a term for construction, it is clear that one
can be a bit more liberal than a strict intersection between the pattern
and current expression syntax.
Incidentally, this would be consistent with the way record patterns
and record construction currently works. E.g.
data Foo = MkFoo {l1 :: T1, l2 :: T2}
A pattern MkFoo {} expands to MkFoo _ _, a term MkFoo {} expands
to MkFoo undefined undefined.
Moreover, didn't someone (John Mecham?) propose that _ be a valid
term anyway, standing for undefined (with an explicit requirement
of keeping track of the source code position)?
Maybe ~ (and !) wouldn't cause much trouble either.
I like the idea, but it would be nice if the RHS of a pattern
synonym definition really coudl be any Haskell pattern, without any
additional restriction (except that it has to be acyclic).
All the best,
/Henrik
--
Henrik Nilsson
School of Computer Science and Information Technology
The University of Nottingham
[EMAIL PROTECTED]
This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
[Haskell] TFP2006: Last CFP
Dear Colleague, Please find enclosed the third call for papers for Trends in Functional Programming (TFP) 2006. Just one week to go tp the abstract submission deadline of 17 February! Please note that registration for TFP 2006 is now open! My apologies for duplicate copies. Best regards, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. TFP 2006 Seventh Symposium on Trends in Functional Programming Nottingham, UK, 19 - 21 April, 2006 http://www.cs.nott.ac.uk/~nhn/TFP2006 Co-located with Types 2006 and Spring School on Datatype-Generic Programming CALL FOR PAPERS 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 papers presented at the symposium for publication in a high-profile volume. TFP 2006 is going to be held in Nottingham, UK, 19 - 21 April. Note that this is significantly earlier in the year than past TFPs that generally were held in August - September. TFP 2006 is co-located with Types 2006 (18 - 21 April). 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, in Munich, Germany in 2004, and in Tallinn, Estonia in 2005 (co-located with ICFP and GPCE). For further general information about TFP, see http://www.tifp.org/. SCOPE OF THE SYMPOSIUM The Symposium recognises that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five categories of paper. High-quality papers are solicited in any of these categories: Research Papers: leading-edge, previously unpublished research work Position Papers: on what new trends should or should not be Project Papers:descriptions of recently started new projects Evaluation Papers: what lessons can be drawn from a finished project Overview Papers: summarising work with respect to a trendy subject Papers must be original, and not submitted for simultaneous publication in any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or more experience-oriented. Also applications of functional programming techniques to other languages may be considered. Papers on the following subject areas are particularly welcome: 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 and formally motivated computing o functional languages for telecommunications applications o functional languages for embedded systems o functional programming applied to global computing o functional GRIDs o functional languages for reasoning about imperative/object- oriented programs o interoperability with imperative programming languages o any new emerging trend in the functional programming area If you are in doubt on whether your paper is within the scope of TFP, please contact the TFP 2006 programme chair, Henrik Nilsson, [EMAIL PROTECTED] BEST STUDENT PAPER AWARD TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. To acknowledge this, a prize for the best student paper is awarded each year. CO-LOCATION WITH TYPES 2006 AND DATATYPE-GENERIC PROGRAMMING 2006 TFP 2006 is co-located with Types 2006 (to be held 18 - 21 April). To take advantage of the synergies offered by these two complementary events, we will invite a number of joint keynote speakers, hold joint sessions on topics of mutual interest, such as dependently typed functional programming, and run common social events. The schedule will be arranged so that participants may freely move between parallel sessions of the two events. See http://www.cs.nott.ac.uk/types06/ for further details. TFP 2006 and Types 2006 are immediately followed by the Spring School on Datatype-Generic Programming 2006
Re: MPTCs and functional dependencies
Dear all, Simon PJ wrote: Multi-parameter type classes, yes. Functional dependencies, no. My experience is that even with very simple applications of MPTCs, I often end up needing functional dependencies to make things work. Thus, if my hunch is right, and other people have a similar experience, my fear would be that omitting FDs or something similar would result in a Haskell' standard that ends up being out of date even before it is finalised, in that a large number of real world applications and libraries would fail to be standard compliant and could not easily be adapted to be. I think that would be very unfortunate, even though I do agree that the Haskell' effort should strive to be as conservative as possible. Might it be possible to at least allow some simple forms of FDs that would cover the most common cases, e.g. like what's described in Mark's original paper? I personally would not be too worried about adopting a possibly non future-proof solution in this respect, as I would expect that the amount of code that would have to be change would be fairly small if some scheme like associated types later are adopted as a replacement. What would worry me is the lack of ANY functionality like FDs, as having to work without them means that code often would have to be too type specific, which in the end might result in lots of code duplication. Refactoring such code later would seem to be much more work (even if it might not be strictly necessary to do so, as the code would continue to work). But maybe other people have a somewhat difference experience, and feel that this is less of an issue than I believe it is? All the best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
[Fwd: Re: Haskell-prime Digest, Vol 2, Issue 6]
Hmm. Seems I missed sending this to haskell-prime. Sorry. /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ---BeginMessage--- Dear all, Simon PJ wrote: Now, someone can try to define a conservative version of FDs, as has been suggested; perhaps it could even be kind-of-isomorphic to associated types. Perhaps something *very* conservative would be enough for most applications. (It would hurt to standardise FDs if we think we're going to discard them subsequently, but if the spec was somewhat crisp maybe it would not hurt too much.) What about the FD Conditions as defined in the paper by Sulzman, Duck, Peyton-Jones and Stuckey you referred to? (Mark Jones original conditions + a so called bound variable condition). If those conditions are imposed, one gets sound, complete, and decidable type inference according to the said paper. I had a quick look at the monadic libraries and a vector space class in Yampa, and my impression is that the FDs used there would be compatible with the FD conditions. But I emphasize that's just an impression. Or are the FD conditions considered too restrictive? Clearly, as exemplified in the above paper, they do rule out a number of reasonable programs. But as long as the adopted version of FDs allow the basic usage of FDs for applications like monad transformers, I don't think I personally would be too unhappy. Best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] ---End Message--- ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Comment Syntax
Hi all, To corroborate Wadler's law further. Josef wrote: Oh yes, it does happen that a single line comment begins with a special symbol. It has happened to me on several occations when using haddock annotation to my source code. It is all to easy to forget that extra space. With incomprehensible error messages as a result. But might that not just mean that the error messages ought to be improved? I don't know how hard that would be, but after having played around a bit with GHC, the messages I get are either of the type parse error on input '--|' or of the type Not in scope: `--' (followed by lots of other stuff not being in scope etc). If this really is a big problem for beginners, it would not seem totally infeasible to add some special code that helpfully suggests that a space perhaps ought to be inserted? Or have you seen significantly worse error messages? Best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
[Haskell] TFP2006: Third Call for Papers
Dear Colleague, Please find enclosed the third call for papers for Trends in Functional Programming (TFP) 2006. Please note that the abstract submission deadline is fast approaching: 17 Feb. Also note the co-location with Types 2006 and the Spring School on Datatype-Generic Programming. My apologies for duplicate copies. Best regards, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. TFP 2006 Seventh Symposium on Trends in Functional Programming Nottingham, UK, 19 - 21 April, 2006 http://www.cs.nott.ac.uk/~nhn/TFP2006 Co-located with Types 2006 and Spring School on Datatype-Generic Programming CALL FOR PAPERS 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 papers presented at the symposium for publication in a high-profile volume. TFP 2006 is going to be held in Nottingham, UK, 19 - 21 April. Note that this is significantly earlier in the year than past TFPs that generally were held in August - September. TFP 2006 is co-located with Types 2006 (18 - 21 April). 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, in Munich, Germany in 2004, and in Tallinn, Estonia in 2005 (co-located with ICFP and GPCE). For further general information about TFP, see http://www.tifp.org/. SCOPE OF THE SYMPOSIUM The Symposium recognises that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five categories of paper. High-quality papers are solicited in any of these categories: Research Papers: leading-edge, previously unpublished research work Position Papers: on what new trends should or should not be Project Papers:descriptions of recently started new projects Evaluation Papers: what lessons can be drawn from a finished project Overview Papers: summarising work with respect to a trendy subject Papers must be original, and not submitted for simultaneous publication in any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or more experience-oriented. Also applications of functional programming techniques to other languages may be considered. Papers on the following subject areas are particularly welcome: 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 and formally motivated computing o functional languages for telecommunications applications o functional languages for embedded systems o functional programming applied to global computing o functional GRIDs o functional languages for reasoning about imperative/object- oriented programs o interoperability with imperative programming languages o any new emerging trend in the functional programming area If you are in doubt on whether your paper is within the scope of TFP, please contact the TFP 2006 programme chair, Henrik Nilsson, [EMAIL PROTECTED] BEST STUDENT PAPER AWARD TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. To acknowledge this, a prize for the best student paper is awarded each year. CO-LOCATION WITH TYPES 2006 AND DATATYPE-GENERIC PROGRAMMING 2006 TFP 2006 is co-located with Types 2006 (to be held 18 - 21 April). To take advantage of the synergies offered by these two complementary events, we will invite a number of joint keynote speakers, hold joint sessions on topics of mutual interest, such as dependently typed functional programming, and run common social events. The schedule will be arranged so that participants may freely move between parallel sessions of the two events. See http://www.cs.nott.ac.uk/types06/ for further details. TFP 2006 and Types 2006 are immediately followed
