October 2005 - Haskell

Petri Nets 2006 CFP
by P S Thiagarajan 28 Oct '05

28 Oct '05

Apologies if you receive multiple copies. ------------------------------------------------------------------------ Call for Papers and Announcement Petri Nets 2006 27th INTERNATIONAL CONFERENCE ON APPLICATION AND THEORY OF PETRI NETS AND OTHER MODELS OF CONCURRENCY Turku, Finland, June 26-30, 2006 Additional information about the conference will be published via http://www.cs.abo.fi/atpn2006/ Contact e-mail: atpn2006(a)abo.fi In 2006 the Petri Nets conference is co-located with the ACSD'06. Important Dates: Submission of Papers & Tool Presentations: November 15, 2005 Notification: March 1, 2006 Final Version Due: April 1, 2006 Tutorials & Workshops: June 26-27, 2006 Conference: June 28-30, 2006 The deadline for submission of papers and tool presentations is STRICT. However, if you submit the title page before Nov. 15 it is sufficient to submit the full paper/tool presentation before Nov. 22. The title page must contain a short abstract, classification of the paper, and tell whether it is a theory paper, application paper, or tool presentation. The 27th annual international Petri Net conference and tutorials will be organised by ùÕ÷o Akademi University, Department of Computer Science. Papers presenting original contributions in any area of application and theory of Petri nets are sought. The language of the conference is English. Topics System design and verification using nets, Analysis and synthesis, structure and behaviour of nets, Relationships between net theory and other approaches, Causality/partial order theory of concurrency, Net-based semantical, logical and algebraic calculi, Symbolic net representation (graphical or textual), Computer tools for nets, Experience with using nets, case studies, Educational issues related to nets, Higher-level net models, Timed and stochastic nets, Standardisation of nets, Applications of nets to different kinds of systems and application fields, e.g.: flexible manufacturing systems, real-time systems, embedded systems, defence systems, biological systems, health and medical systems, environmental systems, hardware structures, telecommunications, railway networks, office automation, workflows, supervisory control, protocols and networks, Internet, e-commerce and trading, programming languages, performance evaluation, operations research. The conference takes place under the auspices of EATCS and GI SIG "Petri Nets and Related System Models". Paper Submissions Submissions for papers must: * Contain original contributions that have not been published or submitted to other conferences/journals in parallel with this conference. * Clearly state the problem being addressed, the goal of the work, the results achieved, and the relation to other work. * Be in the Springer LNCS-format: http://www.springer.de/comp/lncs/authors.html. * Have a length that does not exceed 20 pages. * Be in English and in a form that can be immediately included in the proceedings without major revision. * Be sent electronically (as a PostScript or PDF file) using the website http://sttt.cs.uni-dortmund.de/atpn06/servlet/Conference no later than November 15, 2005. The title page must: * Contain a short abstract and a classification of the topics covered, preferably using the list of topics above. * Clearly indicate whether the paper is submitted as a theory paper, an application paper, or both. A typical application paper is a paper that describes one or more projects in which Petri net models and tools have been used in practice. An application paper may also describe a tool, a methodology, or other developments that demonstrate the applicability of Petri nets to industrial systems. Submissions received too late and submissions sent by fax will be immediately rejected. The same will happen with papers which are not in English or exceed the page limit. Authors will be notified of acceptance/rejection by March 1, 2006. The proceedings will be published by Springer-Verlag in Lecture Notes in Computer Science. The final camera-ready version of accepted papers must be received by Susanna Donatelli no later than April 1, 2006. The page limit is 20 pages. Program Committee Co-Chair (Theory Papers) P. S. Thiagarajan School of computing, NUS 3 Science Drive 2 Singapore 117543 Phone: +65-6874 7998 Fax: +65-6779 4580 Program Committee Co-Chair (Application Papers) Susanna Donatelli Università degli Studi di Torino Dipartimento di Informatica Corso Svizzera 185 I-10149 Torino Italy Phone: +39 011 6706746 Fax: +39 011 751603 Organising Committee Chair Johan Lilius ùÕ÷o Akademi University Department of Computer Science Lemminkú¿ènengatan 14 A FIN-20540 Turku FINLAND Phone: +358 40 5440741 Fax: +358 2 215 4732 Tools Demonstration Chair Jerker Bjúä·kqvist ùÕ÷o Akademi University Department of Computer Science Lemminkú¿ènengatan 14 A FIN-20540 Turku FINLAND Phone: +358 2 215 3348 Fax: +358 2 215 4732 Tutorials and Workshops The conference takes place Wednesday to Friday. However, the surrounding days also offer a large variety of Petri net activities. The Introductory Tutorial is offered to participants who have little or no prior experience with Petri nets. The talks give an overview of the area, and they will help new-comers to understand the basic ideas in many of the conference contributions. The Advanced Tutorials and Workshops are offered to those who already have some knowledge of Petri nets. They are divided into several strands covering different subjects. A detailed description of the tutorials and workshops will be available via the conference Web pages. Finally, it will be possible to arrange meetings for different groups, e.g., participants in international Petri net projects. It will also be possible to arrange small educational courses, e.g., with respect to some of the Petri net tools. Submissions for such activities must contain a 2-5 page description. They must be received by one of the PC-chairs no later than January 15, 2006. Tools for Petri Nets As part of the conference, there will be an exhibition of computer tools for Petri nets together with a limited number of tool presentations, i.e., talks about tools. For tool presentations a rotation principle will be enforced. This means that the same tool cannot be presented year after year -- unless it has been significantly enhanced. Submissions for tool presentations must: * Focus on the description of a computer tool for Petri Nets (not an application of the tool or the theory behind the tool). * Be in the Springer LNCS-format: http://www.springer.de/comp/lncs/authors.html. * Have a length that does not exceed 10 pages. * Be in English and in a form that can be immediately included in the proceedings without major revision. * Be sent electronically (as a PostScript or PDF file) using the website http://sttt.cs.uni-dortmund.de/atpn06/servlet/Conference no later than November 15, 2005. Submissions for tool demonstrations must: * Be in English and contain a 3-10 pages description of the tool. * Be received by the tool demonstration chair Jerker Bjúä·kqvist no later than April 1, 2006. Participants wishing to demonstrate tools are encouraged to bring their own machines, as only a limited number of local machines will be available for this purpose, with limited support for installation. Program Committee J. Billington, Australia D. Buchs, Switzerland N. Busi, Italy G. Ciardo, USA J.M. Colom, Spain P. Darondeau, France S. Donatelli, Italy (co-chair, applications) G. Franceschinis, Italy B. Haverkort, The Netherlands X. He, USA K. van Hee, The Netherlands M. Heiner, Germany J. Hillston, UK K. Hiraishi, Japan P. Jancar, Czech Republic G. Juhas, Germany M. Koutny, UK L.M. Kristensen, Denmark J. Lilius, Finland M. Mukund, India W. Penczek, Poland L. Petrucci, France L. Pomello, Italy L. Recalde, Spain K. Schmidt, Germany P.S. Thiagarajan, Singapore (co-chair, theory) T. Ushio, Japan R. Valk, Germany F. Vernadat, France Steering Committee W. van der Aalst, The Netherlands J. Billington, Australia J. Desel, Germany S. Donatelli, Italy S. Haddad, France K. Jensen, Denmark (chair) H.C.M. Kleijn, The Netherlands M. Koutny, UK S. Kumagai, Japan T. Murata, USA C.A. Petri, Germany (honorary member) L. Pomello, Italy W. Reisig, Germany G. Rozenberg, The Netherlands M. Silva, Spain

1 0

Re: Instances That Ignore Type Constraints? (HList-related)
by oleg＠pobox.com 27 Oct '05

27 Oct '05

Just to add one more example to Ralf's reply: We get exactly the same kind of problem if we try *Main> null [fromEnum] <interactive>:1:6: Ambiguous type variable `a' in the constraint: `Enum a' arising from use of `fromEnum' at <interactive>:1:6-13 Probable fix: add a type signature that fixes these type variable(s) Indeed, fromEnum is a polymorphic function |fromEnum :: (Enum a) => a -> Int| The expression [fromEnum] has the type |(Enum a) => [a -> Int]| that carries the constraint Enum a. That constraint has to be eventually resolved somehow. For a top-level expression (not a function), the constraint must be resolved. Granted, the function 'null' could care less what the list is made of, and whether all constraints are resolved. But Haskell does. One may say that instead of inferring the type [fromEnum] :: forall a. (Enum a) => [a -> Int] Haskell should have inferred [fromEnum] :: [forall a. (Enum a) => a -> Int] and the problem would have been solved. There is no longer an (outermost, top-level) constraint to resolve. When GHC does implement MLF and start explicitly supporting impredicative types, the problem would be fixed indeed... Currently, the only way to achieve the same effect is to do this manually: newtype W = W (forall a. (Enum a) => a -> Int) *Main> null [W fromEnum] False Perhaps indeed we should move to Cafe...

1 0

RE: [Haskell] Instances That Ignore Type Constraints? (HList-related)
by Ralf Lammel 27 Oct '05

27 Oct '05

Hi, 'isBoxed (Carton func)' fails because there is no way whatsoever that any expression context will disambiguate the x y type variables of func's type. That is, the type of `isBoxed (Box func)` does not expose x (and y -- the latter being irrelevant because of the fundep); so there is no way that the type system could ever figure out which x (and y) was meant; hence overloading will never ever get resolved (check out the hugs type error, which tells you exactly that). One could argue in favor of incoherent choice of instances. (I don't!) Say, if you had: {-# OPTIONS -fallow-undecidable-instances #-} {-# OPTIONS -fallow-incoherent-instances #-} instance Func x x -- or some other generic instance It will work fine: ghci> isBoxed (Carton func) HFalse However, why would you want to wrap such a function anyhow, if you are not going to use it? :-) Perhaps, this is a case of superficial, say unintended polymorphism. If you *really* wanted to box (or to carton) a polymorphic type-class bounded function, then you may need to do something like this: data WFunc = WFunc (forall x y. Func x y => (x -> y)) hugs-or-ghci> isBoxed (Carton (WFunc func)) HFalse This works fine ... but this is probably *not* what you wanted in the first place. Also, this technique is extremely limiting because now you would need to fabricate wrappers like WFunc for each new polymorphic expression (when the constraints or the type differ). I am keen to hear more about your problem, and to help accordingly. (Haskell-café?) Regards, Ralf > -----Original Message----- > From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On > Behalf Of Jared Warren > Sent: Wednesday, October 26, 2005 7:01 PM > To: Haskell Mailing List > Subject: [Haskell] Instances That Ignore Type Constraints? (HList-related) > > > > data Box x = Box x > > data Carton x = Carton x > > class Func x y | x -> y where func :: x -> y > > > class IsBoxed f b | f -> b where isBoxed :: f -> b > > instance IsBoxed (Box x) HTrue where isBoxed _ = hTrue > > instance IsBoxed (Carton x) HFalse where isBoxed _ = hFalse > > `isBoxed (Box func)` fails in GHC with "Ambiguous type variables > `x', `y' in the constraint: `Func x y' arising from use of `func'...".

1 0

Instances That Ignore Type Constraints? (HList-related)
by Jared Warren 27 Oct '05

27 Oct '05

I'm working with data structures that contain class methods from the HList library (classes with functional dependencies). What I want to be able to do is operate on high-level parts of the structure while ignoring the type constraints of the lower-level components. For example, say I have two data types and a class method: > data Box x = Box x > data Carton x = Carton x > class Func x y | x -> y where func :: x -> y I want to define a function 'isBoxed' that identifies whether a function is in a Box or in a Carton that I can use like `isBoxed (Carton func)`. Naively: > class IsBoxed f b | f -> b where isBoxed :: f -> b > instance IsBoxed (Box x) HTrue where isBoxed _ = hTrue > instance IsBoxed (Carton x) HFalse where isBoxed _ = hFalse (Where hTrue is a constructorish thing for the empty datatype HTrue.) But `isBoxed (Box func)` fails in GHC with "Ambiguous type variables `x', `y' in the constraint: `Func x y' arising from use of `func'...". I realise that it's solvable if I have a finite number of instances for Func, but what I actually want to box is functions with recursive constraints like HList's hLookupByLabel.* I tried to borrow some ideas (like TypeCast and empty data types) from the examples that come along with HList (like keyword-arguments.hs) to no avail. Can anybody give me a hand? Thanks, Jared Warren <warren(a)cs.queensu.ca> * I could satisfy the type constraints with the infinite HList Record: {Label hZero -> undefined, Label (hSucc hZero) -> undefined, ...} ...but that obviously runs into an infinite type.

1 0

OCaml-intensive summer internships at trading firm
by Yaron Minsky 27 Oct '05

27 Oct '05

Jane Street Capital (http://janestcapital.com) is a proprietary trading company located in Manhattan. We're looking for students interested in internships for the summer of 2006. Jane Street is an open and informal environment (you can wear shorts and a t-shirt to the office), and the work is technically challenging, including systems programming, machine learning, statistical analysis, parallel processing, and anything that crosses our path that looks useful. One unusual attraction of the job is that the large majority of our programming is done in OCaml. Here's what we're looking for from candidates: - A commitment to the practical. Both development and research are tightly integrated with our trading operation, and we work very hard to keep our work relevant. One of the big attractions of the job is the opportunity to apply serious ideas to real-world problems. - Great communication skills. We need people who can explain things clearly and cogently, who can read dense academic papers and write clear documentation. - Strong programming skills. Most of our programming is in OCaml, so being a solid Caml hacker is a big plus. Extra points for deep knowledge of OCaml internals and experience wrapping thorny libraries. But we're also interested in great programmers who we are convinced will be able to pick up OCaml quickly, so anyone with high-level of proficiency with functional languages would be a good match. - Top-notch mathematical and analytic skills. We want people who can solve difficult technical problems, and think clearly and mathematically about all sorts of problems. - Strong Unix/Linux skills --- We're looking for someone who knows their way around the standard Unix tools, can write makefiles, shell scripts, etc. We're also very interested in people with serious systems administration and architecture experience. Summer interns are paid quite well, and we can help out with housing costs if you don't live nearby. If you're interested, please send a cover-letter and resume to: yminsky(a)janestcapital.com -- Yaron Minsky <yminsky(a)janestcapital.com>

1 0

RE: [Haskell] multiple occurence of the same type variable in instancehead
by Simon Peyton-Jones 26 Oct '05

26 Oct '05

Quite right. I've fixed the documentation (in CVS). Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Wolfgang | Jeltsch | Sent: 17 October 2005 14:04 | To: Haskell ML | Subject: [Haskell] multiple occurence of the same type variable in instancehead | | Hello, | | the following is not Haskell 98: | | class C a | | instance C (a,a) | | Well, GHC allows this with the -fglasgow-exts flag. Surprisingly, I cannot | find a section in the GHC User's Guide which states that -fglasgow-exts can | be used to allow this kind of instance declarations. Well, in the section on | undecidable instances (7.4.4.3), one can read: | | Note that instance heads may contain repeated type variables. For example, | this is OK: | | instance Stateful (ST s) (MutVar s) where ... | | But one has to note that in this expample, the different occurences of s | aren't in the same type. Furthermore, multiple occurences of the same type | variable cannot result in undecidability (as far as I understand). The | above-mentioned statement talks about the things that are allowed *without* | -fallow-undecidable-instances, and premises that multiple occurences of a | type variable are okay. | | So am I missing something? | | Best wishes, | Wolfgang | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

logic problem
by michael＠schmong.org 26 Oct '05

26 Oct '05

Hi, My name is Michael. I'm new to Haskell. I'm working through The Craft of Functional Programming by Simon Thompson. I'm having problems with a few exercises from chapter 4. I will present one per post. This one is from 4.9 Given a function f of type Int -> Int give a recursive definition of a function of type Int -> Int which on input n returns the maximum values f 0, f 1, ... , f n I defined f as follows f 0 = 0 f 1 = 44 f 2 = 5 f 9 = 8 this works except when f n > n. In that case I get an "illegal instruction" error and hugs exits. I'm pretty sure this is a logic problem. Could someone point me in the right direction so I can think about this problem correctly. Here is my code maxOverf :: Int -> Int maxOverf m | f m > m = (f m) | otherwise = (maxOverf m-1) Any hints/help/flames welcome. Thanks Michael Litchard

5 4

[mini-announce] Attribute grammars in happy
by Robert Dockins 26 Oct '05

26 Oct '05

Fellow Haskellers, I have hacked up Happy (http://www.haskell.org/happy/) to support attribute grammars. Attribute grammars are a way of annotating context-free grammars to support syntax directed translation and the checking of context-sensitive properties. What we have: * Support for attribute grammars using a slight modification to the Happy grammar syntax * Haskell 98! No language extensions required. * Support for all well-defined attribute grammars (conjecture, but I'm pretty sure) What we don't have: * Support for GLR parsing (mostly because I don't completely understand it) * Checks for proper attribute usage There is a darcs repo at based on the Happy 1.15 source distribution at: http://www.eecs.tufts.edu/~rdocki01/happy-ag/ And documentation for the extension can be found at: http://www.eecs.tufts.edu/~rdocki01/happy-ag-docs/sec-AttributeGrammar.html If there is sufficient interest I can clean up the code and write test cases and submit an official patch to Happy. Let me know what you think. Comments and suggestions are welcome. Thanks, Robert Dockins P.S. Discussion should probably move to haskell-cafe.

1 0

REMINDER: Contributions to the HC&A Report (November 2005 edition)
by Andres Loeh 25 Oct '05

25 Oct '05

Dear Haskellers, the deadline for the November 2006 edition of the Haskell Communities and Activities Report is only a few days away -- but this is still enough time to make sure that the report contains a section on *your* project, on the interesting stuff that you've been doing; using or affecting Haskell in some way. Many projects that have been included in former reports have not yet updated their entries. Please have a look at http://haskell.org/communities/topics.html and at the May 2005 edition for reference. * Has your project been listed in previous Reports, but is not yet updated? Please write a short update! * Are you no longer working on a project that was included in the Report? Write up what you are working on instead, and tell me if someone else has picked up the project. * Is some project you have heard about not included in any previous Report? Please let me know ... There is still time to write a completely new entry, on a new compiler, tool, library, company, user group, idea, ... -- as long as there is a connection to the Haskell language, there is a place for it in the Report! Submissions are due by next Tuesday, that is Tuesday, 01 November 2005. Please mail your entries to <hcar at haskell dot org>, in plain text or pseudo-(La)TeX format. More information can be found in the original Call for Contributions at http://www.haskell.org/pipermail/haskell/2005-October/016575.html I look forward to receiving your contributions. Thanks a lot, Andres (current editor) -- Haskell Communities and Activities Report (http://haskell.org/communities) 11/2005 edition submission deadline: 01 November 2005 <hcar(a)haskell.org>

1 0

getArgs, maxBound, float division: pure functions?
by oleg＠pobox.com 24 Oct '05

24 Oct '05

The question of getArgs as a pure function has already been debated on this list back in January: http://www.haskell.org/pipermail/haskell/2005-January/015184.html The topic seems worth revisiting as it expands to a bigger, and perhaps, a bleaker picture. To recap, there were two arguments for getArgs to remain with the IO [String] type: 1. getArgs is the function of the environment and does not have a clear denotation. The value of getArgs may change from one program run to another. 2. The existence of System.Environment.withArgs Regarding argument 1: the value of |maxBound :: Int| is also the function of the environment. Haskell98 Report says [p82, Section 6.4] The finite-precision integer type Int covers at least the range [ - 2^29 , 2^29 - 1 ]. As Int is an instance of the Bounded class, maxBound and minBound can be used to determine the exact Int range defined by an implementation. Thus, the value of |maxBound :: Int| may conceivably change from on program run (under runhugs32 on an AMD64 platform) to another (under runghc64 on the same platform). The Haskell98 Report, in section 6.4.6 defines other implementation-dependent functions: floatRadix, floatDigits, and floatRange. The GHC documentation [ghc6/libraries/base/Prelude.html#t%3ARealFloat] is particularly revealing: floatRadix :: a -> Integer a constant function, returning the radix of the representation (often 2) Some may find the phrase ``constant function that often [sic!] has the value 2'' to be incompatible with the notion of a pure function. Regarding argument 2: the existence of System.Environment.withArgs seems to doom getArgs to remain with the IO type. It cannot be a pure function. The simple extension of the argument points however to inconsistency with the floating-point facility. Haskell98 Report permits an implementation to use IEEE FP for Haskell Floats and Doubles. The Report specifically provides the class RealFrac to give a program access to some aspects of the IEEE FP system. IEEE FP computations are sensitive to the rounding mode, which is observable in pure code. The rounding mode can be changed. The following simple program shows > {-# OPTIONS -fglasgow-exts #-} > -- Tested on GHC 6.4 on on i686/Linux > > module FP where > import Foreign.C > > eps ::Float = 2^^(1-24) > > -- from /usr/include/bits/fenv.h > > type FP_RND_T = CInt -- fenv.h > > eFE_TONEAREST = 0 > eFE_DOWNWARD = 0x400 > eFE_UPWARD = 0x800 > eFE_TOWARDZERO = 0xc00 > > foreign import ccall "fenv.h fegetround" fegetround > :: IO FP_RND_T > > foreign import ccall "fenv.h fesetround" fesetround > :: FP_RND_T -> IO FP_RND_T > > test1 = do > let tf () = 1 + eps/2 > let tfe = tf () > putStrLn "Rounding mode and the result" > fegetround >>= print > print $ tf () > print $ tfe > > old <- fesetround eFE_UPWARD > putStrLn "Rounding mode and the result" > fegetround >>= print > print $ tf () > print $ tfe > > fesetround old > putStrLn "Rounding mode and the result" > fegetround >>= print > print $ tf () > print $ tfe > print "Done" that the supposedly pure computation "1 + eps/2" is not, in fact, referentially transparent. Should all floating-point computations be put in the IO monad? Granted, FP addition, among other operations, is not associative; so one may even wonder if FP can be done in any monad at all. OTH, when it comes to IO, the monad laws are usually stretched.

5 4