November 2005 - Haskell

CfP: Applied Semantics, Special Issue of J of TCS
by Hans-Wolfgang Loidl 03 Nov '05

03 Nov '05

[ -- apologies for multiple copies of this CfP -- HWL ] CALL FOR PAPERS Special Issue on APPLIED SEMANTICS of the Journal of Theoretical Computer Science http://lionel.tcs.ifi.lmu.de/APPSEM05/journal_call.php We invite the submission of full papers on the topic of Applied Semantics, as described below, for publication in a special issue of the Journal of Theoretical Computer Science (TCS). Papers should be revised versions of those papers submitted to and presented at the APPSEM05 Workshop, Frauenchiemsee, Germany, September 12-15. However, we will consider submissions of papers not presented there, provided they fall into the scope of the call and clearly work out a novel contribution to the field that wasn't mature enough to be presented at the aforementioned workshop. Programming languages are the basic tools with which all applications of computers are built. It is important, therefore, that they should be well designed and well implemented. Achieving these goals requires both a good theoretical understanding of programming language designs, and practical skills in the development of high quality compilers. This special issue will cover all these areas and will focus on the formal basis for programming languages. The general areas covered by this special issue are as follows: 1. Program structuring: object-oriented programming, modules, 2. Proof assistants, functional programming, and dependent types, 3. Program analysis, generation, and configuration, 4. Specification and verification methods, 5. Types and type inference in programming, 6. Games, sequentiality, and abstract machines, 7. Semantic methods for distributed computing, 8. Resource models and web data, 9. Continuous phenomena in Computer Science. 10. Industrial applications. This list is non-exclusive, but contributions that do not clearly fall into one of these topics should carefully work out their relationship. We particularly invite industrial contributions covering the areas above. This could mean development of a novel language, a novel compiler, program analysis tools, or indeed, just a semantic model for a new kind of application. Again, this list is not exclusive and we welcome papers on any kind of industrial work which is informed by the science of programming languages, clearly states the problem being solved and elaborates on the main techniques of the above research areas being used to solve it. Programme committee: . Gavin Bierman, Microsoft Research . Olivier Danvy, University of Aarhus . Peter Dybjer, Chalmers University of Technology . Martin Hofmann, Ludwig-Maximilians-Universität München (Chair) . Neil Jones, University of Copenhagen . Hans Wolfgang Loidl, Ludwig-Maximilians-Universität München . Peter O'Hearn, Queen Mary College, University of London . Uday Reddy, University of Birmingham . Didier Remy, INRIA Rocquencourt . Ian Stark, University of Edinburgh . Thomas Streicher, Technische Universität Darmstadt . Peter Thiemann, Universität Freiburg Format of submission (see links below): Papers should be formatted according to Elsevier's elsart document style, used for articles in the Journal of Theoretical Computer Science. Submission should be electronically in .pdf format via the APPSEM Workshop page. Papers should have 20-25 pages, including appendices. Papers exceeding the upper bound may be rejected without refereeing. Important dates: . Paper submission: 8.1.2006 . Notification: 27.2.2006 . Camera-ready copy: 27.3.2006 Links: . APPSEM05 page and paper submissions: http://lionel.tcs.ifi.lmu.de/APPSEM05/ . TCS page: http://www.elsevier.com/wps/find/journaldescription.cws_home/505625/descrip… . Document style (elsart.cls): http://authors.elsevier.com/latex

1 0

RE: [Haskell] specification of sum
by Simon Marlow 03 Nov '05

03 Nov '05

On 02 November 2005 17:06, Scherrer, Chad wrote: >> Surely not... sum is defined by Haskell 98 as: >> >> sum = foldl (+) 0 >> >> and this is exactly what GHC provides. Furthermore we have >> specialised strict versions for Int and Integer. >> > > I'd been using ghci for testing along the way and getting terrible > results; does the specialization only apply to ghc per se? Yes, you need 'ghc -O' to get the optimised versions. The performance characteristics of unoptimised (including interpreted) code are often quite different. You can load the optimised module into GHCi, of course. Cheers, Simon

1 0

RE: [Haskell] specification of sum
by Simon Marlow 03 Nov '05

03 Nov '05

On 02 November 2005 00:20, Lennart Augustsson wrote: > Furthermore, ghc has a WRONG definition of sum. Surely not... sum is defined by Haskell 98 as: sum = foldl (+) 0 and this is exactly what GHC provides. Furthermore we have specialised strict versions for Int and Integer. Also, we shouldn't be turning overloaded functions into class methods purely for the purposes of providing optimised versions; that's what the SPECIALISE pragma is for. Cheers, Simon

3 2

The next langauage definition version will be ``Haskell 1.6''
by kahl＠cas.mcmaster.ca 02 Nov '05

02 Nov '05

Hi all, somebody wrote something which reminds me: ******************************************************************** * * * The ``next stable version'' of the Haskell language definition * * should be called ``Haskell 1.6''. * * * ******************************************************************** This follows the numbering scheme used before the current stable version. Some will still remember that during the discussion for the name of that version, a ballot was put out, and ``somehow'' the logical name ``Haskell 1.5'' was missing from that ballot --- it still received the second-most votes after ``Haskell 98'': as a free-form fill-in choice! But ``somehow'' nobody drew the consequence to do a corrected ballot... Add to that, that ``Haskell 98'' did of course not come out at a point of time that had any obvious relation with the number 98. Choosing ``Haskell 2006'' would therefore be equally unwise. And choosing something like ``Haskell 06'' would send a message that is completely wrong for a language that actually provides arbitrary-precision integers as its default integer number type. (It would also make version comparison even harder...) I therefore encourage everybody to refer to the current stable version as ``Haskell 1.5'', and stick with ``Haskell 1.6'' as the name for the next stable version. Wolfram

2 1

pattern matching on record fields and position
by David Roundy 02 Nov '05

02 Nov '05

Hello fellow haskellers, I have a couple of related (almost conjugate) proposals/questions. Basically, I've been thinking about how to make code more robust with respect to changes in the data types. Pattern matching based on positions is very fragile (I don't think this is a surprise to anyone). When you add a new field to a data type, you have to modify every bit of code that uses positional pattern matching, such as lengthPS (PS _ _ l) = l I'd like to be able export a data type with constructors in such a way that positional pattern matching isn't possible--but field-based pattern matching *is* possible. One could just use a coding policy, but I like the compiler enforcing things like this for me. Perhaps there's already a trick to do this? In particular, this would be relevant if I had the following data type: data FPS = PS { fp :: ForeignPtr Word8, my_start :: Int, my_length :: Int } I would like to be able to export this data constructor (in actual FastPackedString, the constructor isn't exported at all--and shouldn't be--but I'm taking this as a simple hypothetical example). I would like users (who import this module) to be able to write case fps of { PS { my_start = s } -> print s } but not to write case fps of { PS _ s _ -> print s } If I could enforce this, then I could change the definition of FPS to data FPS = PS { fp :: ForeignPtr Word8, my_start :: Int, my_length :: Int, extra_argument :: String } or data FPS = PS { fp :: ForeignPtr Word8, my_length :: Int, my_start :: Int } and have a guarantee that no code that imports the module will be broken. In the first example, all positional-matching code would fail to compile. The second is even more insidious, since code would continue to compile, but would be wrong! The second feature I'd like (and even better if it's something that already exists, although I've been told that it isn't) would be to be able to have record field names that are exported so as to not allow them to be used as accessor functions if those functions might lead to failure. For example: data Foo = AB { a :: String, b :: Int } | B { b :: Int } I would like "a" to be useable for pattern matching, but not as the function "a :: Foo -> String", which is dangerous, in that it really ought (in my opinion) to have the type Foo -> Maybe String. Actually, a compiler warning when using dangerous functions of this sort (as we can get when we use non-comprehensive pattern-matching) would satisfy me, although I'd really prefer to be able to have these accessor functions not be generated, or at least have an option to not export them. As you can probably tell, I've been thinking about how one can export constructors and yet still maintain flexibility in the implementation of data structures. Pattern matching is very nice, and often one wouldn't want to give it up, but it seems to completely tie down the implementation of data type, which is annoying, and seems to be a tradeoff that we could avoid by a combination of using field descriptors for pattern matching constructors. The catch being that for data types with multiple constructors, field descriptors always introduce "unsafe" functions that I'd really prefer didn't exist. -- David Roundy http://www.darcs.net

3 2

RE: [Haskell] specification of sum
by Scherrer, Chad 02 Nov '05

02 Nov '05

> Surely not... sum is defined by Haskell 98 as: > > sum = foldl (+) 0 > > and this is exactly what GHC provides. Furthermore we have > specialised strict versions for Int and Integer. > I'd been using ghci for testing along the way and getting terrible results; does the specialization only apply to ghc per se? > > Cheers, > Simon > Also, Cale, I was thinking about your comment about formal power series, and I don't see that (+) should not be strict in this case. In particular, if they are represented as infinite lists, I agree that zipWith (+) works just fine, though it is strict but lazy. Here is the strictness: zipWith (+) undefined [1,2,3] == undefined zipWith (+) [1,2,3] undefined == undefined And here is the laziness: head $ zipWith (+) (1:undefined) (2:undefined) == 3 Or am I missing something? -Chad

2 1

Haskell Workshop Steering Committee
by Johan Jeuring 02 Nov '05

02 Nov '05

At the Haskell workshop in Tallinn in September it was decided to set up a Haskell Workshop Steering Committee. The main purpose of the Haskell Workshop Steering Committee is to provide continuity of the workshop and to offer help and advice to the current organizer(s) of the workshop. I'm pleased to announce the Haskell Workshop Steering Committee, which has been approved by ACM SIGPLAN. You can find more information about the Haskell Workshop and its Steering Committee on http://www.haskell.org/haskell-workshop/ -- Johan Jeuring

1 0

RE: specification of sum
by Scherrer, Chad 02 Nov '05

02 Nov '05

> The solution would be to bring 'sum' and 'product' into the Num class so > the most efficient version for each type can be used and the default is > no worse than the current non-class versions. (this is even pretty much > completly backwards compatable so could be considered for haskell 06) > > I'd also like to see 'join' and 'ap' added to Monad while we are at it. > > John Ooo, that's much better. I'll retract my sum' suggestion in that case.

1 0

specification of sum
by Scherrer, Chad 02 Nov '05

02 Nov '05

I was wondering... In my experience, it's worked much better to use sum' = foldl' (+) 0 than the built-in "sum" function, which leaks memory like crazy for large input lists. I'm guessing the built-in definition is sum = foldr (+) 0 But as far as I know, (+) is always strict, so foldl' seems much more natural to me. Is there a case where the build-in definition is preferable? Chad Scherrer Computational Mathematics Group Pacific Northwest National Laboratory "Time flies like an arrow; fruit flies like a banana." -- Groucho Marx

5 7

RE: [Haskell] specification of sum
by Scherrer, Chad 02 Nov '05

02 Nov '05

> > You don't always want (+) to be strict. Consider working with > the ring of formal power series over, say, the integers. You > don't want (+) to force the evaluation of an infinite formal > summation which is passed to it, since that's an infinite > loop, so it will have to be non-strict, somewhat like zipWith > (+) over the lists of coefficients. > > - Cale Hmm, this is a good point, but for most people, It seems like the most common usage would be to add up a list of actual concrete numbers, and the resulting memory leak in the code using sum is at least a minor annoyance. It's hard to say how much time a given newbie will take to catch this nuance. Since sum' = foldl' (+) 0 (like foldl', the ' means "strict" ) is so often preferable, I'll go so far as to suggest it be included it in upcoming versions of Data.List. That way it would be hard to miss, and would remove what could otherwise be a very common stumbling block for anyone doing numerical work with Haskell. I haven't used product so extensively, but I suspect there may be similar issues with it? -Chad

1 0