FM03 CFP- Deadline is approaching
Title: FM03 CFP- Deadline is approaching Sorry if some of you receive multiple copies of this message. Stefania Gnesi (FM2003 General Chair) == Call for Papers -- The 12th International FME Symposium Pisa, Italy - September 8-14, 2003 http://fme03.isti.cnr.it - [EMAIL PROTECTED] -- FM 2003 is the twelfth in a series of symposia organized by Formal Methods Europe, an independent association whose aim is to stimulate the use of, and research on, formal methods for software development. These symposia have been notably successful in bringing together a community of users, researchers, and developers of precise mathematical methods for software development as well as industrial users. Formal methods have been controversial throughout their history, and the realization of their full potential remains, in the eyes of many practitioners, merely a promise. Have they been successful in industry? If so, under which conditions? Has any progress been made in dispelling the skepticism that surrounds them? Are they worth the effort? Which aspects of formal methods have become so well established in the industrial practices to loose the "formal method" label in the meanwhile? FM 2003 aims to answer these questions, by seeking contributions not only from the Formal Methods community but also from outsiders and even from skeptical people who are most welcome to explain, document, and motivate the source of their reluctance. We are confident that a wide spectrum of experiences and a loyal contrasting of opinions will foster a better and deeper understanding, if not a wider adoption of Formal Methods. Far from restricting the focus of the conference, however, FM 2003 also welcomes papers with strong theoretical content that establish a connection with the practice of formal methods. Therefore, FM 2003 welcomes papers in all aspects of formal methods for computer systems, including the following: introducing formal methods in the practice of industrial processes (technical, organizational, social, psychological aspects) concerns and risks for potential adopters of formal methods; cost-benefit analysis reports on practical use and case studies (reporting positive or negative experiences) formal methods in hardware and system design reusable domain theories theoretical foundations (specification and modeling, refining, verification, etc.) tool support and software engineering environments for formal methods method integration Papers Full papers should be submitted electronically via the Web by March 7, 2003. Full submission details will be published on the conference web site. Papers will be evaluated by the Program Committee according to their originality, significance, soundness, quality of presentation and relevance with respect to the main issues of the symposium. Papers should have not been submitted elsewhere for publication. Accepted papers will be published in the symposium proceedings in the LNCS series by Springer Verlag. Papers should not exceed twenty pages, although longer papers will be considered if their content justifies it. LNCS format should be used. Please include a short list of keywords on a separate line at the end of the abstract, beginning with the word "Keywords:" in boldface. Other symposium activities In addition to presentations of submitted papers, the symposium will offer half-day or full-day tutorials, one-day or two-days workshops, invited speakers, and tool demonstrations with presentations. Please send your proposals for tutorials/workshops/tool exhibitions to the related chairs by the deadlines indicated below. For full details of what is required, whom to contact, etc, see the web site http://fme03.isti.cnr.it, or send your query to [EMAIL PROTECTED] Submission Deadlines March 7, 2003: Papers (firm deadline) March 7, 2003: Workshop/tutorial proposals May 9, 2003: Tool Exhibition proposals June 8, 2003: Papers' final version Acceptance Notifications March 20, 2003: Tutorials/workshops May 9, 2003: Papers June 8, 2003: Tool Exhibition
Re: type classes vs. multiple data constructors
G'day.
On Mon, Feb 17, 2003 at 01:44:07AM -0500, Mike T. Machenry wrote:
> I was wondering if it's better to define them as type classes with the
> operations defined in the class. What do haskellian's do?
I can't speak for other Haskellians, but on the whole, it depends.
Here's the common situation: You have a family of N abstractions. (In
your case, N=2.) The abstractions are similar in some ways and
different in some ways. The most appropriate design depends largely
on what those similarities and differences are.
>From your definitions, it seems clear that there is some common
structure. That suggests that a vanilla type class solution may
not be appropriate, because type classes do not directly support
common structure, only related operations.
Your solution wasn't bad:
> data PlayerState =
> FugitiveState {
> tickets :: Array Ticket Int,
> fHistory :: [Ticket] } |
> DetectiveState {
> tickets :: Array Ticket Int,
> dHistory :: [Stop] }
If the operations on the "tickets" field are different, or the
algorithms which operate on PlayerState are different for the
FugitiveState case and the DetectiveState case, this may be a good
design, because by not sharing structure, you're explicitly denying
any similarity (i.e. just because look the similar, that doesn't mean
they are similar).
If they are similar, then this may not be an appropriate design.
Ideally, you want to use language features and/or idioms which expose
the similarities (where they exist) and the differences (where they
exist).
Here's one design where the structural similarity is explicit:
data PlayerState
= PlayerState {
tickets :: Array Ticket Int,
role:: RoleSpecificState
}
data RoleSpecificState
= FugitiveState { fHistory :: [Ticket] }
| DetectiveState { dHistory :: [Stop] }
Depending on how similar the operations on the RoleSpecificState are
(say, if they are related by a common type signature, but have little
code in common), or if you want a design which is extensible to other
kinds of player (possibly at dynamic-link time) you may prefer to use
type classes to implement the role-specific states instead:
-- Warning: untested code follows
class RoleSpecificState a where
{- ... -}
data FugitiveState = FugitiveState { fHistory :: [Ticket] }
instance RoleSpecificState FugitiveState where
{- ... -}
data DetectiveState = DetectiveState { fHistory :: [Ticket] }
instance RoleSpecificState DetectiveState where
{- ... -}
data PlayerState
= forall role. (RoleSpecificState role) =>
PlayerState {
tickets :: Array Ticket Int,
role:: role
}
(If you know anything about design patterns, you may recognise this as
being similar to the "Strategy" pattern. This is no accident.)
It's hard to say what is the most appropriate design without looking at
the algorithms and operations which act on the PlayerState type and
analysing their similarities and differences.
> Oh and if I say
> Instance Foo Baz where
> ...
>
> and only define a few of the operations in Foo... bdoes Baz take on some
> default methods?
If you've declared default methods, yes.
Cheers,
Andrew Bromage
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
WRS 2003 - Second Call for Papers
** ** second call for papers and participation *** ** Third International Workshop on Reduction Strategies in Rewriting and Programming (WRS 2003) http://www.dsic.upv.es/~rdp03/wrs part of the Federated Conference on Rewriting, Deduction and Programming (RDP 2003) Valencia, Spain, June 8, 2003 -- BACKGROUND AND AIMS Reduction strategies in rewriting and programming have attracted an increasing attention within the last years. New types of reduction strategies have been invented and investigated, and new results on rewriting / computation under particular strategies have been obtained. Research in this field ranges from primarily theoretical questions about reduction strategies to very practical application and implementation issues. The need for a deeper understanding of reduction strategies in rewriting and programming, both in theory and practice, is obvious, since they bridge the gap between unrestricted general rewriting (computation) and (more deterministic) rewriting with particular strategies (programming). Moreover, reduction strategies provide a natural way to go from operational principles (e.g., graph and term rewriting, narrowing, lambda-calculus) and semantics (e.g., normalization, computation of values, infinitary normalization, head-normalization) to implementations of programming languages. Therefore any progress in this area is likely to be of interest not only to the rewriting community, but also to neighbouring fields like functional programming, functional-logic programming, and termination proofs of algorithms. The workshop wants to provide a forum for the presentation and discussion of new ideas and results, recent developments, new research directions, as well as of surveys on existing knowledge in this area. Furthermore we aim at fostering interaction and exchange between researchers and students actively working on such topics. The workshop is part of the Federated Conference on Rewriting, Deduction and Programming (RDP 2003) to be held in Valencia (Spain) on June 8, 2003. The workshop is (co-)organized by TU Valencia and TU Wien. TOPICS OF INTEREST Topics of interest include, but are not restricted to: - theoretical foundations for the definition and semantic description of reduction strategies - strategies in different frameworks (term rewriting, graph rewriting, infinitary rewriting, lambda calculi, higher order rewriting and explicit substitutions, conditional rewriting, rewriting with built-ins, narrowing, constraint solving, etc.) and their application in (equational, functional, functional-logic) programming (languages) - properties of reduction strategies / computations under strategies (e.g., completeness, computability, decidability, complexity, optimality, (hyper-)normalization, cofinality, fairness, perpetuality, context-freeness, neededness, laziness, eagerness, strictness) - interrelations, combinations and applications of reduction under different strategies (e.g., equivalence conditions for fundamental properties like termination and confluence, applications in modularity analysis, connections between strategies of different frameworks, etc.) - program analysis and other semantics-based optimization techniques dealing with reduction strategies - rewrite systems / tools / implementations with flexible / programmable strategies as essential concept / ingredient - specification of reduction strategies in (real) languages - data structures and implementation techniques for reduction strategies. SUBMISSIONS We solicit papers on all aspects of reduction strategies in rewriting and programming. Submissions should describe unpublished work, except for survey papers which are explicitly welcome, too. Submissions should not exceed 10 pages (however, survey papers may be longer) and be sent in postscript or PDF format to the PC co-chairs at [EMAIL PROTECTED] before March 23, 2003. Submissions should include the title, authors' names, affiliations, addresses, and e-mail. Selection of papers by the PC will be based on originality, significance, and correctness. Final versions will be due by May 11, 2003. PUBLICATION Accepted papers will be included in the preliminary workshop proceedings that will be available at the workshop. The final workshop proceedings will be published in the Electronic Notes in Theoretical Computer Science (ENTCS) series of Elsevier. PROGRAM COMMITTEE Sergio Antoy Portland (USA) Zena M. Ariola Eugene (USA) Roberto Di Cosmo Paris VII (France) Juergen GieslAachen (Germany) Bernhard Gramlich (co-chair) Wien (Austria) Salvador Lucas
RE: Yet another weakly defined bug report
> You should do the counting strictly: > > Just n -> case n+1 of n1 -> addToFM f w n1 Careful - that case expression doesn't actually force n to be evaluated. It's exactly equivalent to let n1 = n+1 in addToFM f w n1 You need to use seq to force evaluation. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Yet another weakly defined bug report
Dean Herington <[EMAIL PROTECTED]> writes: > Yes, getting the right amount of strictness--and in the right places--can be > tricky. Tell me about it! > You should do the counting strictly: > > Just n -> case n+1 of n1 -> addToFM f w n1 Thanks for the tip. Just performing this change didn't perceptibly change anything, though. It seems to be working all right now, but to my amazement, it may have been upgrading to 5.04.2 that did it?! (I had a lot of heapCensus trouble) Is this at all possible? > Right, except that, as Simon M. mentioned, the file is opened so that any opening > exceptions are triggered. Yeah. I keep forgetting the IO monad is imperative. > Perhaps. You're only demanding the head of the list. Conceivably, the FM logic > might be able to determine the lowest key/element pair without evaluating the > entire map. > I find the above approach a bit risky, as you are closing the file after having > only shallowly demanded the result of addHist. My earlier suggestion, return $! > addHist fm x, makes exactly the same shallow demand, but if that demand is > insufficient, loses performance but not correctness. ..but then I could equally well use readFile, couldn't I? Anyway, thanks for all the suggestions, all of you. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
CFP: GMAG'03
International Conference on Geometric Modeling & Graphics (GMAG 2003) (Previously, Computer Aided Geometric Design Symposium) in co-operation with IEEE Computer Society JULY 16-18, 2003 London, UK. Aims and Scope: === Computer-Aided (CA) techniques for Geometric Modeling (GM) and Computer Graphics (CG) are extremely useful tools in a number of industrial settings. Specifically, the applications of computational geometry and graphical modeling to current problems of designing and manufacturing have grown at a large scale. In addition to its critical importance in the traditional fields of automobile and aircraft manufacturing, shipbuilding, and general product design, more recently, these methods have also proven to be indispensable in a variety of modern industries, including computer vision, robotics, medical imaging, visualization, and even media. The purpose of the GMAG conference is to focus on interdisciplinary methods and affiliate research done among various disciplines with the goal of stimulating views and providing a forum where academicians, researchers, and practitioners can discuss the latest developments linked to Geometric Modeling and Computer Graphics. Papers presenting original research with the theme of "Geometric Modeling and Graphics" are being sought. Scope of the conference topics include (but are not limited to): * Curve and Surface Design * Geometric Modeling * Solid Modeling * Physically Based Modeling * Autonomous Agents * Computer Graphics * Geometric Algorithms * Manufacturing Geometry * Computational Geometry * Reverse Engineering * Computer Aided Design (CAD) * Computer Aided Manufacturing (CAM) * Font Design * Character Design * Multiresolution Methods * Geometric Transformations * Mesh Processing * Shape Abstraction and Modeling * Shape Analysis and Description * Scientific Visualization * Internet Applications * Computer Animation * Rendering * Multimedia * Non Photo-Realistic Rendering * Virtual Reality * Virtual Environments * Illumination Models * Texture Models * Computer Graphics and the Internet (VRML, Java, etc.) * Artificial Intelligence for Computer Graphics * Softwares * Education, Engineering, Medical, and other Applications Important Dates: * 17 January 2003 - Submission of proposal for symposium * 07 March 2003 - Submission of papers and Submission of tutorials * 05 May 2003 - Submission of camera-ready and Early registration closes * 14 June 2002 - Tutorial Registration Cancellation & Refund date (Last day to register for tutorial sessions - Registration after this is subject to availability) * 09 July 2003 - Pre-Registration date * 15 July 2003 - Tutorial Day * 16-18 July 2003 - Conference Days Program Committee = Muhammad Sarfraz (Chairman), King Fahd University of Petroleum and Minerals, Saudi Arabia. Varol Akman, Bilkent University, Turkey. Jamaludin Ali, Universiti Sains Malaysia, Malaysia Ebad Banissi, South Bank University, UK. Gordon Clapworthy, De Montfort University, UK. John Cowell, De Montfort University, UK Jinan A. W. Faidhi, Lakehead University, Canada. Stefan Gumhold, University of Tübingen, Germany Hans Hagen, University of Kaiserslautern, Germany Fiaz Hussain, University of Luton, UK. Jihad Mohamad JAAM, University of Qatar, Qatar. Ali Jaoua, University of Qatar, Qatar. Deok-Soo Kim, Hanyang University, Korea. Myoung-Hee Kim, Ewha Womans University, South Korea Sabah M.A. Mohammed, Lakehead University, Canada. Ahmad Nasri, American University of Beirut, Lebanon. Yoshihiro Okada, Kyushu University, Japan Juan Manuel Pena, Universidad de Zaragoza, Spain Abd. Rahni Mt. Piah, Universiti Sains Malaysia, Malaysia Andres Iglesias Prieto, University of Cantabria, Spain Manabu Sakai, Kagoshima University, Japan. Nickolas Sapidis, University of the Aegean, Greece. Leonardo Traversoni, Universidad Autonoma, Mexico. Keith Unsworth,Lincoln University, New Zealand. Markus Wacker, Universitaet Tuebingen, Germany Fujiichi Yoshimoto, Wakayama University, Japan Submission of Papers: Prospective authors are invited to submit their draft papers electronically by the due date. The length of the Camera-Ready papers (if accepted) will be limited to 7 (IEEE style) pages. Papers must not have been previously published or currently submitted for publication elsewhere. The first page of the draft paper should include: title of the paper, name, affiliation, postal address, E-mail address, telephone number, and Fax number for each author. The first page should also include the name of the author who will be presenting the paper (if accepted) and a maximum of 5 keywords. Proposal for Organizing Technical Sessions Each technical session will have at least 6 paper presentations. The session chairs will be responsible for all aspects of their sessions; including, soliciting papers, reviewing, selecting, etc. THE NAMES OF SESSION CHAIRS WILL APPEAR AS ASSOCIATE EDITORS
Last Call: SCP Special Issue on Program Transformation; Deadline 1.4.2003
Program Transformation Special Issue in the Science of Computer Programming Deadline is 1.4.2003 Find CFC attached or at http://www.cwi.nl/~ralf/pt-scp/ (Program transformation is of interest for many subscribers of this list because program transformation is crucial for the implementation of functional languages, and it is also a typical application domain of functional programming. Other keywords: Meta-programming, XML processing, refactoring.) -- Ralf Laemmel VU & CWI, Amsterdam, The Netherlands http://www.cs.vu.nl/~ralf/ http://www.cwi.nl/~ralf/ Special Issue on Program Transformation Science of Computer Programming Guest Editor Ralf Lämmel Call for contributions The special issue is devoted to `program transformation' in the sense of automated program adaptation by executable transformations. Such transformations are used in software development and especially in software maintenance in various ways, e.g., for refactoring, software migration, mass maintenance, change logging, schema evolution, program specialisation, software configuration, aspect weaving, and others. The special issue seeks high-quality contributions studying the following dimensions of transformations: * formal aspects such as operator suites for transformations and their properties; * language design issues such as suitable language setups and meta-programming frameworks; * infra-structural issues such as the relation to front-ends, program analysis, interfaces; * software engineering aspects such as scaling, testing and maintaining transformations; * emerging fields such as unanticipated software evolution; * case studies such as lessons learned in large-scale transformation projects. Deadline for paper submissions: 1 April 2003 Author's notification: 1 July 2003 Special issue's publication:End of 2003 The submissions should be sent in PS or PDF to the guest editor via email. If you are not sure about the suitability of a given subject, or if you want to know more details about the special issue's intent, do not hesitate to contact the guest editor. The guest editor's email address is [EMAIL PROTECTED];or see the URL http://www.cwi.nl/~ralf/. For details about the policy of the Science of Computer Programming journal and the requirements for prospective authors, see a recent issue of the journal and check the journal's web site http://www.elsevier.com/locate/issn/01676423.
