- Haskell - Haskell.org

CFP : ASIA-PEPM 2002
by Chin Wei Ngan 20 Feb '02

20 Feb '02

CALL FOR PAPERS ACM SIGPLAN ASIAN Symposium on Partial Evaluation and Semantics-Based Program Manipulation (ASIA-PEPM'02) Aizu, JAPAN, September 12-14 2002 (co-located with FLOPS2002) http://www.comp.nus.edu.sg/asia-pepm02 Submission deadline: 1st March 2002 The ASIA-PEPM'02 symposium will bring together researchers working in the areas of semantics-based program manipulation, partial evaluation, and program analysis. The symposium focuses on techniques, supporting theory, and applications for the analysis and manipulation of programs. Technical topics include, but are not limited to: * Program manipulation techniques: transformation, specialization, normalization, reflection, rewriting, run-time code generation, multi-level programming. * Program analysis techniques: abstract interpretation, static analysis, binding-time analysis, type-based analysis. * Related issues in language design and models of computation: imperative, functional, logical, constraint-based, object-oriented, parallel, concurrent, secure, domain-specific. * Programs as data objects: staging, meta-programming, incremental computation, mobility, tools and techniques, prototyping and debugging. * Applications: systems programming, scientific computing, embedded systems, graphics, security, model checking, compiler generation, compiler optimization, decompilation. Original results that bear on these and related topics are solicited. Papers investigating novel uses and applications of program manipulation are especially encouraged. Authors concerned about the appropriateness of a topic are welcome to consult with the program chair prior to submission. SUBMISSION INFORMATION Papers should be submitted electronically via the workshop's Web page. Exceptionally, submissions may be emailed to the program chair: asiapepm(a)comp.nus.edu.sg. Acceptable formats are PostScript or PDF, viewable by gv. Submissions should not exceed 5000 words, excluding 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. The work described should not have been previously published in a major forum. Authors must indicate if a closely related paper is also being considered for another conference or journal. The proceeding of the symposium will be published by ACM Press. A special issue of Higher-Order Symbolic Computation is also planned. LOCAL ARRANGEMENT Mizuhito Ogawa (NTT, Japan) GENERAL CHAIR Kenichi Asai (Ochanomizu University, Japan) PROGRAM CHAIR Wei-Ngan Chin (National University of Singapore, Singapore) PROGRAM COMMITTEE Manuel Chakravarty (University of New South Wales, Australia) Tyng-Ruey Chuang (Academia Sinica, Taiwan) Charles Consel (ENSEIRB, France) Oege de Moor (University of Oxford, UK) Masami Hagiya (University of Tokyo, Japan) Nevin Heintze (Agere Systems, USA) Neil Jones (Univ of Copenhagen, Denmark) Yanhong Annie Liu (SUNY at Stony Brook, USA) Atsushi Ohori (JAIST, Japan) Alberto Pettorossi (University of Roma, Italy) Simon Peyton Jones (Microsoft, UK) Carolyn Talcott (Stanford University, USA) Zhe Yang (University of Pennsylvania, USA)

2 1

Haskell 98 Report
by David Feuer 20 Feb '02

20 Feb '02

Is the revised Haskell98 report going to be put in its proper place on the web site any time soon? As it is, it is sitting off to the side while the old Report sits in the seat of honor. David Feuer

1 0

RE: foralls in class assertions
by Ashley Yakeley 20 Feb '02

20 Feb '02

At 2002-02-19 09:21, Simon Peyton-Jones wrote: >I don't know if it makes sense. You've written down some syntax, >but it's not clear to me what you intend by it. Hmm... it should be straightforward... > instance (forall a. Eq a => Eq (f a)) => Eq (Rose f a) where.. I assume that the 'a' quantified in (forall a. ...) is not the same as the 'a' in 'Rose f a'? >| instance >| ( >| forall a. HasIdentity (m a a), >| forall a b c. Composable (m b c) (m a b) (m a c) >| ) => >| Category m; This means 'if for all a, "HasIdentity (m a a)", and also for all a b c, "Composable (m b c) (m a b) (m a c)", then "Category m"'. "(forall a. HasIdentity (m a a))" as a class assertion declares a property of m. It says that for all types a, there's an instance "HasIdentity (m a a)". >| Or even allow the foralls their own context: >| >| foo :: (forall a. (C a b) => D a c) => T b c; This means foo has type (T b c), where for every type a for which there's an instance "C a b", there's an instance "D a c". >| class >| ( >| forall a. HasIdentity (m a a), >| forall a b c. Composable (m b c) (m a b) (m a c) >| ) => >| Category m; Personally I think the 'superclass' arrow in class declarations should point the other way, as in '<='. After all, instances of the class imply instances of the superclasses, not the other way around. But that aside, this means '"Category" is a class on m, provided that for all types a, there's an instance "HasIdentity (m a a)", and also for all types a b c, there's an instance "Composable (m b c) (m a b) (m a c)"'. -- Ashley Yakeley, Seattle WA

1 0

forcing IO operations
by Andre W B Furtado 20 Feb '02

20 Feb '02

Curious problem... Suppose MyMonad is a Monad other than the IO Monad. Consider the following piece of code: > f :: MyMonad () > f = action1 Now suppose also that ioToMyMonad converts an IO Monad to a MyMonad Monad: > ioToMyMonad :: IO a -> MyMonad a > ioToMyMonad = return . unsafePerformIO Suppose also that action1 needs to perform some IO operation (called IO_op), which returns IO (). In other words, action1 would be: > action1 :: MyMonad () > action1 = do > -- MyMonad operations > ioToMyMonad $ IO_op > -- other MyMonad operations When I run f (via runMyMonad or something like that), I noticed that the io operation (IO_op) is not executed. I guess that this happens because of laziness properties, since the value returned by IO_op is useless to MyMonad. I have then two questions: 1. Does this really happen because of laziness properties? 2. Which is the best way to force IO_op to be performed? I tried the following approach: Step1: Change the type of IO_op from "IO ()" to "IO Bool" and make it returns True. Step2: Change action1 to > action1 :: MyMonad Bool > action1 = do > -- MyMonad operations > b <- ioToMyMonad $ IO_op > -- other MyMonad operations > return b Step3: Change the type of f to MyMonad Bool Step4: Finally, use this boolean somewhere after calling "runMyMonad", e. g., printing it on the screen. I'm sure this is not the best approach, so I'd really appreciate any suggestions. [I'm sending this mail to the HOpenGL list also because runMyMonad is being called inside the display callback, so perhaps it may have something to do with the problem] Thanks a lot, -- Andre

1 0

RE: foralls in class assertions
by Simon Peyton-Jones 19 Feb '02

19 Feb '02

I don't know if it makes sense. You've written down some syntax, but it's not clear to me what you intend by it. The instance decls remind me somewhat of the generalisation described towards the end of a paper Ralf Hinze and I wrote, "Generic type classes". There we describe why instance decls of the form instance (forall a. Eq a => Eq (f a)) => Eq (Rose f a) where.. might be useful. Simon | -----Original Message----- | From: Ashley Yakeley [mailto:ashley@semantic.org] | Sent: 16 February 2002 10:48 | To: Haskell List | Subject: foralls in class assertions | | | It would be nice to be able to put foralls in class assertions. For | instance: | | class HasIdentity a where | { | identity :: a; | }; | | class Composable a b ab | a b -> ab where | { | compose :: a -> b -> ab; | }; | | class | ( | forall a. HasIdentity (m a a), | forall a b c. Composable (m b c) (m a b) (m a c) | ) => | Category m; | | instance | ( | forall a. HasIdentity (m a a), | forall a b c. Composable (m b c) (m a b) (m a c) | ) => | Category m; | | Or even allow the foralls their own context: | | foo :: (forall a. (C a b) => D a c) => T b c; | | Does this make sense? Would it have unpleasant consequences? | | | -- | Ashley Yakeley, Seattle WA | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

1 0

a universal printer for Haskell?
by Bernard James POPE 19 Feb '02

19 Feb '02

Hi all (warning long post), Sorry to dredge up past discussions, but this has been burning in my mind and I wanted to get further opinions. I, and I assume many other Haskell programmers would from time to time like a universal print mechanism, something that can turn an arbitrary value into a String. According to Wadler and others [1], this gives a language designer nightmares. It certainly gives me headaches. So I want: toString :: a -> String We all know you can't do that in Haskell (without some fancy primitive), so maybe: toString :: ToString a => a -> String (of course I've just asked for the Show class). But the problem is not solved (drum roll please). Even first time programmers know the pitfalls of trying to show the empty list: show [] ---> kapow! But you ought to be able to print the empty list, without having to make some bogus type qualification (which is in general not a solution to the problem of printing arbitrary values). Previous discussions [2], have considered passing bottom dictionaries for variables like the 'a' in 'forall a . [a]', in cases where the "a does not matter". The approach discussed was converting such "don't matter" variables into an Empty type which is magically an instance of every class, or at least the Show class. Arguments were raised against this showing that it is quite hard to determine when such variables really do not matter. Subtyping was also considered, but I don't see that coming to Haskell in the short term. What if only the compiler could instantiate the ToString class? What I mean is, imagine the class ToString being avilable in every program, but restricted so that the programmer could not make their own instances of the class, only the compiler. Lets generalise a bit. We have a type: data Meta = MApp String [Meta] | MInt Int | MChar Char ... | MFunction and a class: class Reify a where reify :: a -> Meta thus: toString :: Reify a => a -> String toString x = metaToString $ reify x where metaToString x = ... {- easy enough -} The compiler is required to generate instances of Reify for all types in the program (instances for built in types are hand-coded in a Standard Library). Instances should be derived directly from the syntax of each algebraic data type. So for example: data List a = Nil | Cons a (List a) The compiler derives: nilStr = "Nil" consStr = "Cons" instance (Reify a) => Reify (List a) where reify Nil = MApp nilStr [] reify (Cons h t) = MApp consStr [reify h, reify t] Deriving could be done ala Drift, but in the compiler itself. Since it is impossible for the programmer to define their own Reify instance, it should be possible to adopt the 'defaulting to Empty' rule for "type variables that don't matter", as in: reify Nil ---> Mapp "Nil" [] and so: toString Nil ---> "Nil" No matter which type of list Nil belongs to it always and only reifies to the one representation. The problem with defaulting to Empty with Show is that Show can be user-defined. What about overloaded constants? class Boo a where constant :: a reify constant ---> unresolved constraint '(Reify a, Boo a) => a' We could make Reify a superclass of Boo: class (Reify a) => (Boo a) where ... Does this mean we have to modify the Prelude? class Reify a => Num a ... ... I'm not sure. If we take for granted that EVERY type in the program is an instance of Reify, perhaps there is a way to modify the dictionary transformation to insert Reify dictionaries where needed, without having to modify the text of the Prelude and user classes and so on - as if the superclass relationship was implicit in the program. Okay, so this is very hazy. The mechanism breaks abstraction boundaries, but when I am debugging my program and all I want to do is see what the data looks like, I don't care much about the abstraction boundaries, I just want to print something meaningful out. I can't print functions with this, except to get "Function". But I can live with that. Cheers, Bernie. [1] A Second Look at Overloading, Wadler, Odersky, Wehr. [2] (see http://www.mail-archive.com/haskell%40haskell.org/msg09292.html)

4 6

UNKB 2002 - ICLP'02 Workshop on "Updating Non-Monotonic Knowledge Bases"
by Luis Moniz Pereira 19 Feb '02

19 Feb '02

We apologize for multiple postings _____________________________________________________________________________ UNKB 2002 http://floc02.diku.dk/UNKB/ Workshop on "Updating Non-Monotonic Knowledge Bases" Copenhagen, Denmark, July 28, 2002 Affiliated with ICLP 2002 http://floc02.diku.dk/ICLP/ Significant advances have been made recently in the area of updates of logic programs, and, more generally, updates of non-monotonic knowledge bases and their applications. Numerous papers were published on this subject and the journal Theory and Practice of Logic Programming (TPLP) has decided to publish its Special Issue on Change in Knowledge Bases, tentatively scheduled to appear at the beginning of 2003, to which extended versions of the workshop papers might be submitted. Given the strong activity and extensive work in this area, the present workshop, scheduled for July 28 during the 2002 Federated Logic Conference, will help provide a further boost to and enhance visibility of the recent active research on non-monotonic KB updates and its applications. The workshop seeks high-quality contributions containing original research results or offering an insightful synthesis of past work on various aspects of updating non-monotonic knowledge bases. Topics will include, but are not limited to: Updates of knowledge bases, in single and multi-agent contexts Revision, contradiction removal, preferring, approximating, and other dynamic changes to knowledge bases Relationship and/or applications to software development, theory of actions, multi-source knowledge combination, abductive update planning, model-based diagnosis, agent architectures, and others Implementation issues and systems. Organizers Luís Moniz Pereira <lmp(a)di.fct.unl.pt> Universidade Nova de Lisboa, Monte da Caparica, Portugal Teodor C. Przymusinski <teodor(a)cs.ucr.edu> University of California, Riverside, CA, USA Program Committee José Alferes <jja(a)di.fct.unl.pt>, New University of Lisbon, Monte da Caparica, Portugal Chitta Baral, <chitta(a)asu.edu> Arizona State University, Tempe, AZ, USA Thomas Eiter <eiter(a)kr.tuwien.ac.at> Technical University of Vienna, Vienna, Austria Katsumi Inoue <inoue(a)eedept.kobe-u.ac.jp> Kobe University, Kobe, Japan Nicola Leone <leone(a)dbai.tuwien.ac.at> Technical University of Vienna, Vienna, Austria Luís Moniz Pereira <lmp(a)di.fct.unl.pt>, New University of Lisbon, Monte da Caparica, Portugal Teodor C. Przymusinski <teodor(a)cs.ucr.edu>, University of California, Riverside, CA, USA Chiaki Sakama, <sakama(a)sys.wakayama-u.ac.jp> Wakayama University, Wakayama, Japan Mirek Truszczynski <mirek(a)cs.engr.uky.edu> University of Kentucky, Lexington, KY, USA Important Dates Paper submission: Sun March 31, 2002 Author notification: Fri May 10, 2002 Final papers due: Fri May 31, 2002 Send PS or PDF files to both organizers. Local proceedings are foreseen. ______________________________________________________________________ Luís Moniz Pereira, Professor http://centria.di.fct.unl.pt/~lmp/ ______________________________________________________________________ Director AI Centre CENTRIA http://centria.fct.unl.pt/ Departamento de Informática Ph (+351) 21 294 8533 Fax 21 294 8541 Universidade Nova de Lisboa Secretary: (+351) 21 294 8536 2829-516 Caparica, Portugal Email: lmp(a)di.fct.unl.pt ____________________________________________________________________ Teodor C. Przymusinski, Professor http://www.cs.ucr.edu/~teodor/ ____________________________________________________________________ Office Phone: (909)787-5015 College of Engineering Department: (909)787-5639 Computer Science Fax: (909)787-4643 University of California E-mail: teodor(a)cs.ucr.edu Riverside, CA 92521, USA WWW: ____________________________________________________________________

1 0

Scheme in Haskell?
by Ashley Yakeley 19 Feb '02

19 Feb '02

Has anyone attempted any kind of Scheme interpreter in Haskell? -- Ashley Yakeley, Seattle WA

2 1

Re: Scheme in Haskell?
by Benderjgdefault＠aol.com 19 Feb '02

19 Feb '02

One of the interesting things about implementing Scheme in Haskell could be capturing Scheme's dynamic typing in an efficient way. For a "simple" interpreter of a fairly closed language, maybe this wouldn't be a problem. I have a vague recollection of a paper on compiling Scheme to SML that deal with this issue. Oddly enough, this is not in the Scheme bibliography at present. If I can find it, I will add it soon. (Of course, if someone knows the project I am thinking of: please send me a link!) Jim Bender http://readscheme.org

1 0

Re: Scheme in Haskell?
by Ashley Yakeley 19 Feb '02

19 Feb '02

At 2002-02-18 20:23, David Feuer wrote: >I would be very surprised if no one had written a Scheme interpreter in >Haskell. It is an obvious project for an undergrad like myself. Good >practice playing with monads and such. I'm planning to try it at some >point. Jolly good. Please license it to me under GPL when you're R5RS-compliant. >Query: Aside from learning about Scheme and about writing interpreters, >what purpose would this serve? The natural language for writing Scheme >interpreters is Scheme, and the language that would probably be desired >for efficiency is C. I want to use Scheme as a general "user scripting language" for such things as transforming XML documents, etc., as part of my project ("Truth") to provide a user interface to all information [insert maniacal Bond villain laugh here]. A bit like Guile, I suppose. -- Ashley Yakeley, Seattle WA

1 0