November 2005 - Haskell

ANNOUNCE: hm p3 - an ncurses mpeg layer 3 player
by dons＠cse.unsw.edu.au 22 Nov '05

22 Nov '05

hmp3 : an ncurses music player written in Haskell hmp3 is an ncurses-based music player, for MPEG Layer 3 audio files, written in Haskell. It uses mpg321 or mpg123 for its decoding backend. It is designed to be simple, fast and robust. By web (screenshot): http://www.cse.unsw.edu.au/~dons/hmp3.html By darcs: darcs get --partial http://www.cse.unsw.edu.au/~dons/code/hmp3 Thanks go to Stefan Wehr and Samuel Bronson for testing. In particular Sam burnt many cpu cycles testing stability. Thanks! Cheers, Don

1 0

Re: Type Class Question
by oleg＠pobox.com 22 Nov '05

22 Nov '05

Paul Govereau wrote: > BTW, The above program is a translation of an idiomatic use of > functors in ML (pardon my syntax): > > module A : sig type t = ... end > module B : funsig(X:SHOW where t = A.t) sig bar : A.t -> string end > module C : SHOW where t = A.t > open A > open B(C) ML modules poorly correspond to Haskell modules. Rather, they correspond to Haskell typeclasses: {-# OPTIONS -fglasgow-exts #-} {-# OPTIONS -fallow-undecidable-instances #-} module Foo where -- module A : sig type t = ... end -- A is a constraint on type t class A t -- different instances of A will define what t actually means -- module B : funsig(X:SHOW where t = A.t) sig bar : A.t -> string end class (A t, Show t) => B t where bar :: t -> String -- module C : SHOW where t = A.t -- A restriction on Show such that its type parameter is constrained to -- be in A class (A t, Show t) => C t instance (A t, Show t) => C t -- open A -- Perhaps some implementation of A must be provided somewhere... -- open B(C) instance C t => B t where bar = show -- Eventually we need to give a structure that implements signature A data X = X instance A X instance Show X where show _ = "X" test = bar X

1 0

RE: [Haskell] Type Class Question
by Simon Peyton-Jones 22 Nov '05

22 Nov '05

GHC insists that every type class constraint mentions a type variable that is quantified just outside the constraint. E.g. forall a b c. (C a c, D b) => ... The constraints (C a c), (D b) must each mention at least one of a,b,c. Why? Because it makes it much easier to know when a constraint must be solved. Consider f :: K a => ... g :: E b => b -> b g x = let h :: D b => ... h x = ....(f e).... in ... Notice that there is no 'forall' on the type sig for h, so it disobeys GHC's rule. Suppose the call to f is at type (Tree [b]). That gives rise to the constraint (K (Tree [b])). Now, can the constraint (K (Tree [b])) be satisfied by the (D b)? Or by the enclosing constraint (E b)? Or by a combination of the two? At the moment GHC's rule means it can use the rule "a constraint C floats outwards until it hit a 'forall' that binds one of the type variables mentioned in C. Then C must be solved using the constraints bound at that forall". All this makes solving easier. Everything would work fine without the restriction, but inference would be a bit harder. So far, solving that harder inference problem hasn't seemed important enough, but it's certainly soluble. (Martin Sulzmann's implication constraints suggest how.) Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Paul Govereau | Sent: 22 November 2005 07:56 | To: haskell(a)haskell.org | Subject: Re: [Haskell] Type Class Question | | | Ah yes, but this forces me to write my instance of Show right away. I | cannot write: | | module A where data X = X | module B where | import A | bar x = show x -- here is the problem | moduel C where | import A | instance Show X where show x = "X" | module Main where | import A | import B -- Show instance used | import C -- Show instance defined | | I am not saying that this is terribly useful, I am just wondering why | it is a problem to allow it? | | Paul | | BTW, The above program is a translation of an idiomatic use of | functors in ML (pardon my syntax): | | module A : sig type t = ... end | module B : funsig(X:SHOW where t = A.t) sig bar : A.t -> string end | module C : SHOW where t = A.t | open A | open B(C) | | | On Nov 21, Cale Gibbard wrote: | > data X = X deriving Show | > | > bar :: X -> String | > bar x = show x | > | > There's no need for the class constraint at all. If it's an instance | > of Show, then you're okay with just applying show to it. There's no | > need to actually assert that it's actually an instance of Show again. | > | > The only purpose of class constraints is to restrict polymorphism. If | > a function isn't polymorphic to begin with, you should never need | > them. | > | > - Cale | > | > On 21/11/05, Paul Govereau <govereau(a)eecs.harvard.edu> wrote: | > > Hello, | > > | > > I was hoping that someone could answer a question I have about the | > > type class system. In Haskell, I cannot write a term with an exact | > > constraint: | > > | > > > data X = X | > > > bar :: Show X => X -> String | > > > bar x = show x | > > | > > According to the Haskell 98 report, a qualifier can only be applied to | > > type variables, but I don't see where the trouble is. The term seems | > > to have reasonable type, and I don't see any reason why the | > > dictionary-passing translation shouldn't work out; I am wondering what | > > problems you run into if this restriction is lifted? | > > | > > Note, with GHC and Glasgow extensions you can write this program: | > > | > > > data Y a = Y | > > > foo :: Show (Y a) => Y a -> String | > > > foo x = show x | > > | > > However, the first program is still ruled out. Are there any | > > type-class experts out there that can offer an explanation? | > > | > > Thanks, | > > Paul | > > _______________________________________________ | > > Haskell mailing list | > > Haskell(a)haskell.org | > > http://www.haskell.org/mailman/listinfo/haskell | > > | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

Type Class Question
by Paul Govereau 22 Nov '05

22 Nov '05

Hello, I was hoping that someone could answer a question I have about the type class system. In Haskell, I cannot write a term with an exact constraint: > data X = X > bar :: Show X => X -> String > bar x = show x According to the Haskell 98 report, a qualifier can only be applied to type variables, but I don't see where the trouble is. The term seems to have reasonable type, and I don't see any reason why the dictionary-passing translation shouldn't work out; I am wondering what problems you run into if this restriction is lifted? Note, with GHC and Glasgow extensions you can write this program: > data Y a = Y > foo :: Show (Y a) => Y a -> String > foo x = show x However, the first program is still ruled out. Are there any type-class experts out there that can offer an explanation? Thanks, Paul

2 2

PADL 2006 Call for Participation
by Logic Programming Rsrch Association 21 Nov '05

21 Nov '05

-------------------------------------------------------------------------------- CALL FOR PARTICIPATION CALL FOR PARTICIPATION [ - Apologies for multiple messages; - Deadline for early registration: Dec 15th] Eighth International Symposium on Practical Aspects of Declarative Languages PADL 06 Charleston Place Hotel Charleston, South Carolina January 9-10, 2006 http://www.cs.brown.edu/people/pvh/PADL06.html Co-located with ACM's Principles of Programming Languages, (POPL Dates: January 11-13, 2006) You are cordially invited to attend the 8th Symposium on Practical Aspects of Declarative Languages to be held in Charleston, SC. PADL has a very interesting program that includes invited speakers as well contributed papers. Contributed papers range over diverse topics: from bioinformatics to music modeling to semantic web. Invited Speakers: Phil Wadler, University of Edinburgh, speaking on Links: Linking Theory to Practice for the Web David Roundy, Cornell University Implementing and verifying the darcs patch formalism Erik Meijer, Microsoft Research (title TBA) Contributed papers: Using CHRs to generate functional test cases for the Java Card Virtual Machine Sandrine-Dominique GOURAUD and Arnaud GOTLIEB. Generic Cut Actions for External Prolog Predicates Tiago Soares, Ricardo Rocha and Michel Ferreira. Controlling search space materialization in a practical declarative debugger Ian MacLarty and Zoltan Somogyi. Automatic Verification of a Model Checker by Reflection Bow-Yaw Wang. Probabilistic-logical Modeling of Music Jon Sneyers, Joost Vennekens and Danny De Schreye. Using Dominators for Solving Constrained Path Problems Luis Quesada, Peter Van Roy, Yves Deville and Raphakl Collet. JQuery: A Generic Code Browser with a Declarative Configuration Language Kris De Volder. A Hybrid BDD and SAT Finite Domain Constraint Solver Peter Hawkins and Peter Stuckey. Adding constraint solving to Mercury Ralph Becket, Maria Garcia de la Banda, Kim Marriott, Zoltan Somogyi, Peter Stuckey and Mark Wallace. Modeling Genome Evolution with a DSEL for Probabilistic Programming Martin Erwig and Steve Kollmansberger. Tabling in Mercury: Design and Implementation Zoltan Somogyi and Konstantinos Sagonas. Translating Description Logic Queries to Prolog Zsolt Nagy, Gergely Lukacsy and Piter Szeredi. Efficient top-down set-sharing analysis using cliques Jorge Navas, Francisco Bueno and Manuel Hermenegildo. Querying Complex Graphs Yanhong A. Liu and Scott D. Stoller. Incremental Evaluation of Tabled Prolog: Beyond Pure Logic Programs Diptikalyan Saha and C. R. Ramakrishnan.

1 0

postdoc at Oxford
by Oege de Moor 21 Nov '05

21 Nov '05

Samson Abramsky, Luke Ong, Tom Melham and myself have just founded the "Centre for Metacomputation" at Oxford. We are looking for a 4-year senior postdoc to help coordinate the activities: http://web.comlab.ox.ac.uk/oucl/jobs/platform.html Topics of interest include types for quotation, termination analysis, model checking of higher-order programs, and games semantics for aspect-orientation. Please bring this to the attention of anyone who might be interested; naturally I'd be delighted to discuss the particulars on an informal basis, especially with members of this list. Many thanks, -Oege Oege de Moor, DPhil Professor of Computer Science Fellow of Magdalen College University of Oxford http://progtools.comlab.ox.ac.uk

1 0

ANNOUNCE: Haskell Communities & Activities Report (9th ed., November 2005)
by Andres Loeh 20 Nov '05

20 Nov '05

On behalf of the many, many contributors, I am pleased to announce that the Haskell Communities and Activities Report (9th edition, November 2005) http://www.haskell.org/communities/ is now available from the Haskell Communities home page in several formats: PDF, for screenreading as well as printing, HTML, for those of you who prefer not to deal with plugins or external viewers, and PostScript, for those of you who have nice quick printers that do not grok PDF. Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. I hope you will find it as interesting a read as we did. If you haven't encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and well in time for the actual deadline ;) ) to the call. The editor collects all the contributions into a single report and feeds that back to the community. When we try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: ---------------------------------------- End of April 2006: target deadline for contributions to the May 2006 edition of the HC&A Report ---------------------------------------- Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to `register' with the editor for a simple e-mail reminder in the middle of April (you could point me to them as well, and we can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! Andres Loeh <hcar at haskell.org> -- Haskell Communities and Activities Report (http://haskell.org/communities)

1 0

Improvements to GHC
by John Lask 19 Nov '05

19 Nov '05

I would like to sound out the Haskell community on what the feeling are most desirable to improve the "commerciality" (i.e. its general use) of ghc and Haskell in general (as distinct from feature set) my pick would be to 1) GHC runtime to be dynamically loaded. Enable the ghc runtime system to be loaded as a shared object/dll rather than being statically compiled in. I think the reason this has yet to be done is because it is a rather tricky issue, perhaps those in the know can comment. 2) Improving Haskell support for records. There has been much discussion over the years, some experimentation, but which alas has amounted to no change or improvement in Haskell record support. Again in my opinion the area that Haskell compares least favourably with other languages is in the area of record support particularly a) no distinct namespace for record fields (forcing people to resort to the module system to resolve name space clashes) b) subclassing on records would be great. All these things have been discussed before. The most important is (a) as it would obviate some of the tortured coding that currently appears in many Haskell modules. Additionally c) first class labels would be nice 3) Macro / conditional compilation / compiler meta language / additional binding forms These are perhaps distinct issues but can be discussed together. The prevalent use of #ifdef and the cpp is indicative of the general need to have some standard means by which differences between compilers ghc/hugs/nhc can be accommodated for in the source code. To date this issue has not been tackled in any meaningful way, perhaps we can continue to use cpp but for the sake of portability A means of defining additional binding forms would be nice as it would further facilitate embedded dsl for which Haskell is pre-eminent, and which use is a great motivator for venturing into Haskell in the first place. 4) Taking up the issue of portability and byte codes in a recent thread. The lvm used in the helium compiler perhaps offers the opportunity of defining a standard Haskell byte code platform which other compilers can target for instance ghc/hugs (hugs has in its code base the possibility of writing out a compiled form aka compiler) - thereby separating the compile time and run time platforms, providing a standard Haskell target platform.

10 12

Invitation: AICCSA '06 -- 5th International Workshop on Software Stability: Methodologies, Applications and Tools
by m.fayad＠sjsu.edu 19 Nov '05

19 Nov '05

Greetings, You are invited to submit a position paper for this workshop. Enclosed please find the call for papers. Would you please send the following announcement to all possible e-mail lists that you currently have or have access to. I appreciate your publicizing this workshop to as many people in computing as possible. Thank you. Looking forward to hearing from you soon. Cheers, M. Fayad

1 0

CFP: IEEE WoWMoM 2006 (Extended Deadline)
by Mainak Chatterjee 18 Nov '05

18 Nov '05

We apologize in advance if you receive multiple copies of this CFP. ----------------------------------------------------------------------------------------- CALL FOR PAPERS (Extended Submission Deadline) IEEE WOWMOM 2006 The 7th IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks June 26-29, 2006, Niagara-Falls/Buffalo, New York, USA (Sponsored by IEEE Computer Society, IEEE TCCC and Univ. of Texas at Arlington). http://ieee-wowmom.cse.buffalo.edu/ ****Extended Submission Deadline - November 26, 2005 11:59 PM PST-----*** *** Paper Registration Deadline - November 19, 2005 11:59 PM PST------*** (While papers may be submitted till Nov. 26, all papers MUST be registered by the original deadline of November 19, 2005. Register papers via EDAS, providing the title, abstract and author list of the paper). ----------------------------------------------------------------------------------------- The emergence of broadband wireless access standards, such as 3G/UMTS, 802.16, 802.11a/g and UWB, offers exciting new possibilities for delivering rich multimedia content over wireless networks. The delivery and transport of rich multimedia in such wireless environments, including sensor and mesh networks, requires innovation and advances in better MAC and routing protocols, session establishment and signaling architectures, QoS provisioning and adaptive transmission techniques, autonomic network management capabilities and middleware frameworks, among others. *** Topics of Interest *** The IEEE WoWMoM 2006 technical program committee is soliciting papers addressing the research challenges and advances towards a world of wireless, mobile, and multimedia pervasive communications. Papers must present original and previously unpublished work, validated by experimentation, simulation, or analysis. Practical experiences and experimental efforts, including submissions from industry, are also welcome. Topics of interest include, but are not limited to, the following: - System prototypes and experiences - QoS for voice.video in wireless networks - Middleware support for QoS provision - Differentiated services for wireless multimedia - IP-based wireless multimedia services - Multimedia session signaling in wireless environments - Networking services for pervasive systems - Multicasting and broadcasting issues - Handoff and mobility management - Seamless internetworking - Energy-efficient protocols and power management - Network management and troubleshooting- IP-based mobile networks - Context-aware wireless multimedia application - Location mechanism and services - Wireless BAN, PAN, LAN, and MAN - Ad hoc and sensor networks - Wireless mesh networks - Vehicular wireless networks - Third and fourth generation systems - Wireless security and dependability - Content Management and Distribution - Pricing and billing - Modeling and Performance evaluation Two types of papers will be considered. "Full Papers" must present original, previously unpublished, complete work, validated by experimentation, simulation, or analysis. "Position Papers" must be visionary, innovative and forward-looking, and offer new perspectives on future research directions. Only a limited number of slots will be available for position papers that will be reviewed primarily for relevance and originality. ***Submission Dates and Guidelines**** Submission Deadline (extended): November 26, 2005 11:59 PM PST (Papers must be registered with abstract by November 19, 2005.) Acceptance Notification: February 21, 2006 Camera Ready Due: March 17, 2006. Submitted manuscripts should adhere to the IEEE double-column standard format, except the font size, which must be Times Roman 11pt (or greater). Authors should use only standard fonts, i.e., Times Roman, Courier, Symbol, and Helvetica, or equivalent. For full papers, the maximum length of the manuscript is 12 pages. For "position" papers, the maximum length of the manuscript is 6 pages. This limit includes figures, appendix, bibliography, etc. Papers that will be significantly exceed this limit will be automatically rejected. **Contact Details**** For any questions or clarifications, please contact either of the TPC Chairs below: Marwan Krunz, Univ. of Arizona, USA (krunz(a)ece.arizona.edu) Archan Misra, IBM Research, USA (archan(a)us.ibm.com) For more information, please visit http://ieee-wowmom.cse.buffalo.edu/

1 0