RE: foralls in class assertions
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 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
forcing IO operations
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 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: foralls in class assertions
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:[EMAIL PROTECTED]]
| 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
| [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
|
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: a universal printer for Haskell?
Hi, Doesn't Hugs basically do just this when you don't have +u set? Why not simply mimick their approach? I mean, sure, it's not written in haskell, but does that really matter for the printing for debugging issue? - Hal -- Hal Daume III "Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume On Tue, 19 Feb 2002, Bernard James POPE wrote: > Hi Christoph and all, > > > > Bernie: talking about universal printer... > > > yes, I'm such a Haskell programmer that would like such a mechanism but > > it only makes sense for me if you also have the inverse function. > > For the simple scheme I presented the inverse is easy enough. > > > In this case, you could save the state of your computation on disk and > > recover it later, send run-time functions to a remote machine > > and execute them on that machine with full control by the programmer. > > This marshalling/unmarshalling mechanism is provided partially by > > some Haskell tools. > > Handling functions is always going to be hard. Actually, a related issue > in Haskell is what do you do with partially evaluated structures? > Certainly in some circumstances you don't want to force the value just so > that you can write it out. If you compiled to byte code, life would be a lot > easier, however everything will get a lot messier if you want to mix > machine code and byte code. urgh... > > I carefully avoided functions, because they require a lot more effort. > > > Probably the reason that this mechanism doen't exist in Haskell yet is that > > it is difficult to implement. > > It is especially difficult if you want to make persistent data across > different implementations of the language. It would be nice if you > could write out some data to file from GHC and then read it in using NHC :) > There are obviously various degress of "persistence". > > I think Clean has a prototype persistence mechanism, I saw a short demo > late last year. I'm not sure how they represent functional values. > I think you can only read the data from within the same program that wrote > the data. > > Cheers, > Bernie. > ___ > Haskell mailing list > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/haskell > ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
UNKB 2002 - ICLP'02 Workshop on "Updating Non-Monotonic Knowledge Bases"
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 <[EMAIL PROTECTED]> Universidade Nova de Lisboa, Monte da Caparica, Portugal Teodor C. Przymusinski <[EMAIL PROTECTED]> University of California, Riverside, CA, USA Program Committee José Alferes <[EMAIL PROTECTED]>, New University of Lisbon, Monte da Caparica, Portugal Chitta Baral, <[EMAIL PROTECTED]> Arizona State University, Tempe, AZ, USA Thomas Eiter <[EMAIL PROTECTED]> Technical University of Vienna, Vienna, Austria Katsumi Inoue <[EMAIL PROTECTED]> Kobe University, Kobe, Japan Nicola Leone <[EMAIL PROTECTED]> Technical University of Vienna, Vienna, Austria Luís Moniz Pereira <[EMAIL PROTECTED]>, New University of Lisbon, Monte da Caparica, Portugal Teodor C. Przymusinski <[EMAIL PROTECTED]>, University of California, Riverside, CA, USA Chiaki Sakama, <[EMAIL PROTECTED]> Wakayama University, Wakayama, Japan Mirek Truszczynski <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] Riverside, CA 92521, USA WWW:
Re: a universal printer for Haskell?
I foolishly wrote: > For the simple scheme I presented the inverse is easy enough. Oops. I mean, if you have a dynamic type test. Cheers, Bernie. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: a universal printer for Haskell?
Hi, > >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). > > But how about the difference between > show ([] :: [Int] ) == "[]" > show ([] :: [Char]) == "\"\"" > > You probably want the first, but I want the > second in the cases I'm working with strings. There is a reason why I want the first and not the second. Imagine a debugger for Haskell that prints values from computations, so that the user can inspect what is happening. How is the debugger to present these values? The danger of using user defined print mechanisms is that they might have bugs in them. Okay so the user of the debugger can say: "I really really trust my print mechanisms, so please use them". But there ought to be some fallback strategy where the debugger can always print something which is meaningful. The most basic representation I can think of that would make any sense is something derived directly from the definition of the type. Sure, the abstraction boundary is broken, but sometimes you just might need to do that to debug your program. There are also other uses for such canonical printing. Somtimes you want to write out a data structure and read it back in again, and you want to be sure that what you write will always be readable again. It is quite an annoying maintenance problem when you have to keep the printer and reader in sync. If such synchronisation can be handled by the compiler, then all the better. If you want something prettier, then you can always resort to the usual techniques and put up with the odd unresolved overloading. The basic problem with type classes for this is that there are too many possible meanings for the one program, hence the example with show []. Of course there should only be one meaning, which is why I suggested making the printing mechanism defineable only by the compiler. You don't have to use the type class system to provide generic printing. It could just be a primitive, Hugs has (or at least used to have) this. Such a primitive is going to be a lot harder for something like the STG machine however. > It's not clear to me how much your proposal > differs from extending the default meganism > (http://www.haskell.org/onlinereport/decls.html#default-decls) > to allow arbitrary classes, rather than only > class Num, which would be more consistent > with the current Haskell 98. Perhaps you could extend defaulting to include classes outside the Num hierarchy, but I suspect this is a minefield. I was hoping to avoid this by just making printing a special case, since at least I think it is quite useful. If we want to be really adventurous we might want to look at alternative overloading schemes that do not suffer the same restrictions as type classes do. I think type classes are here to stay, can we put up with more than one overloading mechanism in Haskell, I don't know? Cheers, Bernie. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Scheme in Haskell?
On Mon, 18 Feb 2002, Ashley Yakeley wrote: > Has anyone attempted any kind of Scheme interpreter in Haskell? > Yep. Some years ago a certain Abe Seika <[EMAIL PROTECTED]> posted to comp.lang.functional announcing that he had written a r4rs compliant Scheme interpreter in Haskell. I mailed him and asked for the code and got it. I don't know if the email address is still valid but I think you should give it a try. Best wishes, /Josef ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Extended deadline: Workshop on Generative Programming (GP2002)
Workshop on Generative Programming 2002 (GP2002) Austin (Texas), April 15, 2002 http://www.cwi.nl/GP2002 (extended) Submission deadline: February 28, 2002 Satelite of the 7th International Conference on Software Reuse (ICSR7) Background -- The goal of generative programming is to replace manual search, adaptation, and assembly of components with the automatic generation of needed components on demand. Generative technology has been in practical use for decades (e.g., compiler development, application generation, automatic configuration management, preprocessing, meta-programming). However, developing new domain-specific languages (DSLs), application generators, and component generators has been extremely hard, as it requires being knowledgeable and experienced both in language design and compiler development. Recent developments such as XML technologies and template meta-programming revived the interest in generative programming by making it more accessible to developers. Objectives -- The workshop aims to bring together practitioners, researchers, academics, and students to discuss the state-of-the-art of generative techniques and their impact on software reuse. The goal is to share experience, consolidate successful techniques, and identify the most promising application areas and open issues for future work. Topics of interest -- * impact of generative techniques on component-based development and software reuse. * assessing risks and benefits of deploying generative techniques; * maintenance of generators. * reuse of generic components, generators, generator components, configuration languages, and other generative programming assets across boundaries of projects and/or organizations. * styles of generative programming (application generators, generators based on XML technologies, template languages (e.g., JSP), template meta-programming, transformational systems, intentional languages, aspects, subjects, etc), particularly their uses and limitations. * generation of code artifacts, such as application logic, UIs, database schemas, and middleware integration. * generation of non-code artifacts such as test cases, documentation, tutorials, and help systems. * capturing configuration knowledge, for example, in DSLs, and extensible languages. * influence on software architecture (e.g., building and customizing frameworks and applying patterns). * testing generic and generative models. * industrial applications of generative technology. Submissions --- Potential participants are asked to submit a two-page position paper detailing their experience with generative techniques, their perspective on one or more of the above topics, and their planned contribution to the workshop. We seek concrete case studies, and potential topics of discussion in order to ground the workshop in real-world issues. Please mail your submission (in PDF or PS) to Joost Visser ([EMAIL PROTECTED]) by February 28, 2002. Important Dates --- * Workshop submission deadline: February 28, 2002 * Notification of acceptance: March 14, 2002 * Workshop at ICSR7: April 15, 2002 Workshop format --- The workshop will aim to foster discussion and interaction rather than presentations. Presentations will serve to introduce a case study, provoke discussion by presenting a controversial point of view, or introduce new points of view. However, all participants will be given a chance to make a short presentation. All accepted position papers will be published on the workshop page prior to the workshop and the participants will be asked to read the papers prior to the workshop. Tentative schedule -- Morning session: * Introductory talk on GP by the organizers. * First block of presentations, each consisting of a 10 minute talk by the author of an accepted paper followed by 5 minutes of answering questions from the audience. The questions are meant only for clarification; discussion is postponed to the afternoon sessions. * Second block of presentations. Afternoon session: * Short invited talk. * Pro-and-contra session where each paper is discussed by two volunteers that defend opposing views. The audience is invited to provide additional arguments. * Open discussion session aimed at identifying and summarizing open issues and topics for future work. Dissemination of results The results of the workshop will be summarized in a workshop report. The workshop report and the position papers will be available form the workshop website after the workshop. Related event
Re: a universal printer for Haskell?
Hi Christoph and all, > > Bernie: talking about universal printer... > yes, I'm such a Haskell programmer that would like such a mechanism but > it only makes sense for me if you also have the inverse function. For the simple scheme I presented the inverse is easy enough. > In this case, you could save the state of your computation on disk and > recover it later, send run-time functions to a remote machine > and execute them on that machine with full control by the programmer. > This marshalling/unmarshalling mechanism is provided partially by > some Haskell tools. Handling functions is always going to be hard. Actually, a related issue in Haskell is what do you do with partially evaluated structures? Certainly in some circumstances you don't want to force the value just so that you can write it out. If you compiled to byte code, life would be a lot easier, however everything will get a lot messier if you want to mix machine code and byte code. urgh... I carefully avoided functions, because they require a lot more effort. > Probably the reason that this mechanism doen't exist in Haskell yet is that > it is difficult to implement. It is especially difficult if you want to make persistent data across different implementations of the language. It would be nice if you could write out some data to file from GHC and then read it in using NHC :) There are obviously various degress of "persistence". I think Clean has a prototype persistence mechanism, I saw a short demo late last year. I'm not sure how they represent functional values. I think you can only read the data from within the same program that wrote the data. Cheers, Bernie. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
