From wlux at uni-muenster.de Wed Aug 1 01:57:48 2007 From: wlux at uni-muenster.de (Wolfgang Lux) Date: Wed Aug 1 01:50:39 2007 Subject: [Haskell] Type Lambdas in Gofer In-Reply-To: References: Message-ID: <3BB5A198-5C4F-455A-BBF1-8908DB60DD36@uni-muenster.de> Jim Apple wrote: > data Rec f = In (f (Rec f)) > type P f a = f (Rec f, a) > > mapP :: Functor f => (a -> b) -> P f a -> P f b > mapP g = fmap (\(x,a) -> (x, g a)) > > instance Functor f => Functor (P f) where > fmap = mapP > > Why did Gofer have this power while Haskell does not? Haskell does have the same power as Gofer, it simply does not allow you to define instances for type synonyms (just in order to prevent overlapping instances, I guess). If you use a newtype instead of a type synonym everything works fine: data Rec f = In (f (Rec f)) newtype P f a = P (f (Rec f, a)) unP (P x) = x mapP :: Functor f => (a -> b) -> P f a -> P f b mapP g = P . fmap (\((x,a)) -> (x, g a)) . unP instance Functor f => Functor (P f) where fmap = mapP Wolfgang From stefanor at cox.net Wed Aug 1 02:15:20 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Wed Aug 1 02:07:46 2007 Subject: [Haskell] Type Lambdas in Gofer In-Reply-To: <3BB5A198-5C4F-455A-BBF1-8908DB60DD36@uni-muenster.de> References: <3BB5A198-5C4F-455A-BBF1-8908DB60DD36@uni-muenster.de> Message-ID: <20070801061520.GC6033@localhost.localdomain> On Wed, Aug 01, 2007 at 07:57:48AM +0200, Wolfgang Lux wrote: > Jim Apple wrote: > >> data Rec f = In (f (Rec f)) >> type P f a = f (Rec f, a) >> >> mapP :: Functor f => (a -> b) -> P f a -> P f b >> mapP g = fmap (\(x,a) -> (x, g a)) >> >> instance Functor f => Functor (P f) where >> fmap = mapP >> >> Why did Gofer have this power while Haskell does not? > > Haskell does have the same power as Gofer, it simply does > not allow you to define instances for type synonyms (just > in order to prevent overlapping instances, I guess). If > you use a newtype instead of a type synonym everything > works fine: Quite probably they never bothered to test it. stefan@stefans:/usr/local/src/gofer$ tail -15 standard.prelude openfile f = primFopen f (error ("can't open file "++f)) id -- End of Gofer standard prelude: -------------------------------------------- class Functor f where fmap :: (a -> b) -> f a -> f b data Rec f = In (f (Rec f)) type P f a = f (Rec f, a) mapP :: Functor f => (a -> b) -> P f a -> P f b mapP g = fmap (\(x,a) -> (x, g a)) instance Functor f => Functor (P f) where fmap = mapP stefan@stefans:/usr/local/src/gofer$ src/gofer Gofer Version 2.30b Copyright (c) Mark P Jones 1991-1995 Reading script file "standard.prelude": ERROR "standard.prelude" (line 874): Not enough arguments for type synonym "P" FATAL ERROR: Unable to load prelude stefan@stefans:/usr/local/src/gofer$ Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell/attachments/20070731/d83bd2c7/attachment.bin From simonpj at microsoft.com Wed Aug 1 04:11:06 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Aug 1 04:03:29 2007 Subject: [Haskell] type class instance selection & search In-Reply-To: References: Message-ID: Conal It certainly makes sense to do backward chaining, but I don't know any Haskell implementation that's tried it. It'd be more complicated in the presence of functional dependencies, since we must "undo" any unifications done as a result of discarded searches, much like the "trail" in a Prolog implementation. To be honest I can't see myself trying this anytime soon. Because of the unification part, it'd be a significant structural change. And one would need to dig into the theory to make sure that the algorithm was both sound and complete (finds all solutions). Simon From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Conal Elliott Sent: 31 July 2007 20:09 To: haskell@haskell.org Subject: [Haskell] type class instance selection & search I keep running into situations in which I want more powerful search in selecting type class instances. One example I raised in June, in which all of the following instances are useful. > instance (Functor g, Functor f) => Functor (O g f) where > fmap h (O gf) = O (fmap (fmap h) gf) > instance (Cofunctor g, Cofunctor f) => Functor (O g f) where > fmap h (O gf) = O (cofmap (cofmap h) gf) > instance (Functor g, Cofunctor f) => Cofunctor (O g f) where > cofmap h (O gf) = O (fmap (cofmap h) gf) > instance (Cofunctor g, Functor f) => Cofunctor (O g f) where > cofmap h (O gf) = O (cofmap (fmap h) gf) My understanding is that this sort of instance collection doesn't work together because instance selection is based only on the matching the head of an instance declaration (part after the "=>"). I'm wondering why not use the preconditions as well, via a Prolog-like, backward-chaining search for much more flexible instance selection? Going further, has anyone investigated using Prolog as a model for instance selection? Better yet, how about LambdaProlog ( http://www.lix.polytechnique.fr/Labo/Dale.Miller/lProlog), which generalizes from Horn clauses to (higher-order) hereditary Harrop formulas, including (restricted but powerful) universals, implication, and existentials? Once search is in there, ambiguity can arise, but perhaps the compiler could signal an error in that case ( i.e., if the ambiguity is not eliminated by further search pruning). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20070801/463a5305/attachment-0001.htm From ccshan at post.harvard.edu Wed Aug 1 04:22:56 2007 From: ccshan at post.harvard.edu (Chung-chieh Shan) Date: Wed Aug 1 04:51:56 2007 Subject: [Haskell] Re: type class instance selection & search References: Message-ID: <0gs5o4-a1g.ln1@mantle.rutgers.edu> If only for those watching from home, here are some references. jeff p wrote in article in gmane.comp.lang.haskell.general: > >Better yet, > > how about LambdaProlog ( > > http://www.lix.polytechnique.fr/Labo/Dale.Miller/lProlog), > > which generalizes from Horn clauses to (higher-order) hereditary Harrop > > formulas, including (restricted but powerful) universals, implication, and > > existentials? > Having hereditary Harrop formulas at the type level would be cool. It > would also probably require type level lambdas. On that note: Trifonov, Valery. 2003. Simulating quantified class constraints. In Proceedings of the 2003 Haskell workshop, 98-102. New York: ACM Press. http://flint.cs.yale.edu/trifonov/papers/sqcc.pdf http://flint.cs.yale.edu/trifonov/papers/sqcc.ps.gz > There was a recent discussion about type level lambdas in Haskell > which ended with the observations that 1) it would mess up unification > (i.e. make it undecidable and/or too hard) to have explicit type level > lambdas; and 2) they are already implicitly there (this was pointed > out by Oleg) since one can define a type level application and type > level functions. I think 1) is a bit of a cop-out since you could > always restrict to pattern unification (L-lamda unification) which is > decidable and has MGUs. On that note: Neubauer, Matthias, and Peter Thiemann. 2002. Type classes with more higher-order polymorphism. In ICFP '02: Proceedings of the ACM international conference on functional programming. New York: ACM Press. http://www.informatik.uni-freiburg.de/~neubauer/papers/icfp02.pdf http://www.informatik.uni-freiburg.de/~neubauer/papers/icfp02.ps.gz -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig "Injustice is happening now; suffering is happening now. We have choices to make now. To insist on absolute certainty before starting to apply ethics to life decisions is a way of choosing to be amoral." -Richard Stallman From himself at poczta.nom.pl Wed Aug 1 07:46:43 2007 From: himself at poczta.nom.pl (Andrzej Jaworski) Date: Wed Aug 1 06:37:38 2007 Subject: [Haskell] type class instance selection & search Message-ID: <008c01c7d431$a5ad6a00$5b66ce57@bzdryk> Simon Peyton-Jones wrote: > It certainly makes sense to do backward chaining, but I don't know any Haskell implementation > that's tried it. It'd be more complicated in the presence of functional dependencies, since we > must "undo" any unifications done as a result of discarded searches, much like the "trail" in a > Prolog implementation. Perhaps linear logic search could make this easier. LolliMon http://www.cs.cmu.edu/~fp/lollimon shows how it can be done; additional ideas like memory management and concurrency might avail form this too. I believe that it is high time to revisit logic and Haskell is an excellent ground for this (e.g. multicore is essentially signal processing that can be elegantly solved probably only by multivalued logic). > To be honest I can't see myself trying this anytime soon. Because of the unification part, it'd > be a significant structural change. And one would > need to dig into the theory to make sure that > the algorithm was both sound and complete (finds all solutions). Not much of help but a refreshing read: http://www.cs.cmu.edu/~fp/papers/tocl07.pdf Regards, -Andrzej From claus.reinke at talk21.com Wed Aug 1 08:25:50 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Aug 1 08:18:15 2007 Subject: [Haskell] type class instance selection & search References: Message-ID: <00fe01c7d437$19e2c410$933b8351@cr3lt> |My understanding is that this sort of instance collection doesn't work together because instance selection is based only on the matching the head of an instance declaration (part after the "=>"). I'm wondering why not use the preconditions as well, via a Prolog-like, backward-chaining search for much more flexible instance selection? >It certainly makes sense to do backward chaining, but I don't know any Haskell implementation >that's tried it. It'd be more complicated in the presence of functional dependencies, since we >must "undo" any unifications done as a result of discarded searches, much like the "trail" in a >Prolog implementation. there was some discussion of this on the haskell-prime list some time ago, indicating that there is some room for exploration between the current no-context and a full backtrack-over-all-contexts. in particular, since type class semantics these days are based on constraint handling rules, it would be useful to provide haskell-syntax access to chr guards. one could then, as in chr, restrict the kind of type predicates permitted in guards (no backtracking, no unification), and take guards into account for instance selection, but still "ignore" the full context. that way, one remains in a committed-choice language, with no unification before commit, so no need to undo unifications (chr implementations tend to provide 'unifiable' as well as 'unify', and the former may be used in guards). in many of the cases i'd like to use the context for instance selection, the decision comes down to a simple 'unifiable'/'not unifiable', which could be handled via guards. that is why TypeCast is so central in HList, or why a more cumbersome encoding via newtypes is often possible. claus From apfelmus at quantentunnel.de Wed Aug 1 08:41:22 2007 From: apfelmus at quantentunnel.de (apfelmus) Date: Wed Aug 1 08:33:45 2007 Subject: [Haskell] Re: type class instance selection & search In-Reply-To: References: Message-ID: Conal Elliott wrote: > I keep running into situations in which I want more powerful search in > selecting type class instances. One example I raised in June, in which all > of the following instances are useful. > >> instance (Functor g, Functor f) => Functor (O g f) where >> fmap h (O gf) = O (fmap (fmap h) gf) > >> instance (Cofunctor g, Cofunctor f) => Functor (O g f) where >> fmap h (O gf) = O (cofmap (cofmap h) gf) > >> instance (Functor g, Cofunctor f) => Cofunctor (O g f) where >> cofmap h (O gf) = O (fmap (cofmap h) gf) > >> instance (Cofunctor g, Functor f) => Cofunctor (O g f) where >> cofmap h (O gf) = O (cofmap (fmap h) gf) > > My understanding is that this sort of instance collection doesn't work > together because instance selection is based only on the matching the head > of an instance declaration (part after the "=>"). I'm wondering why not use > the preconditions as well, via a Prolog-like, backward-chaining search for > much more flexible instance selection? There are some fundamental problems/design choices for type classes in conjunction with separate compilation/modularity that need to be researched before trying anything like that. In particular, any ad-hoc Prolog, CHR or -fallow-undecidable-instances just ignores these problems and doesn't solve them. The problem with the Functor/Cofunctor instances is that they are ambiguous as soon as a type constructor X is made an instance of both Functor and Cofunctor . Of course, such an X cannot exist in a mathematically useful way (really ?) but the current system doesn't allow to tell this to the compiler. Alas, we can always say instance Functor F where fmap = undefined instance Cofunctor F where cofmap = undefined The problem is not so much that there might be ambiguities, but how to detect and when to report them. Consider: module F where class Functor f class Cofunctor f module O where import F data O f g a instance (Functor g, Functor f ) => Functor (O g f) instance (Cofunctor g, Cofunctor f) => Functor (O g f) module X where import F data X a instance Functor X instance Cofunctor X module Unsound where import F import O import X type Unsound a = O X X a The current design rejects module O. - Another possible design choice is to reject only module Unsound, i.e. when the conflicting instance declarations both come into scope. But it may be tricky/undecidable to to detect such conflicting instances. - A third possibility is to reject module X based on hypothetical information from module F that states that the instances of Functor and Cofunctor are disjoint. - The fourth choice is to not reject any module but to wait until a function really uses the type Unsound a and to reject this function. This is probably a bad idea since this may delay the error even further to modules that import Unsound. While we're at it, another rather often requested feature of type classes that needs considerable thinking is explicit instance import/export. With this one, we could make module X "locally sound" by simply not exporting either the Functor or the Cofunctor instance. module X (X, instance Functor X) where ... Currently, all instances are globally visible. The problem with explicit import/export is that program correctness depends on global visibility! Consider the following example (due to Bertram Felgenhauer): module A where newtype A = A Int deriving (Eq) module OrdA1 (lookup1) where import A import Data.Map -- don't export this instance instance Ord A where compare (A x) (A y) = compare x y lookup1 :: A -> Data.Map A a -> Maybe a lookup1 = Data.Map.lookup module OrdA2 (lookup2, m) where import A import Data.Map -- don't export this instance instance Ord A where compare (A x) (A y) = compare y x lookup2 :: A -> Data.Map A a -> Maybe a lookup2 = Data.Map.lookup m = Data.Map.fromList $ zip [1..] [1,2,3,4] module Wrong where import Data.Map import OrdA1 import OrdA2 wrong = lookup1 1 m == lookup2 1 m Here, the module Wrong has two lookup functions with different invariants on one and the same map type. In other words, the different Ord instances for A will mess up the invariants of the Map A a implementation and will eventually even lead to pattern match failures. Being able to mess up invariants by class export/import is quite dangerous. Regards, apfelmus From g9ks157k at acme.softbase.org Wed Aug 1 09:41:33 2007 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Wed Aug 1 09:50:20 2007 Subject: [Haskell] Re: type class instance selection & search In-Reply-To: References: Message-ID: <200708011541.34128.g9ks157k@acme.softbase.org> Am Mittwoch, 1. August 2007 14:41 schrieb apfelmus: > [?] > The problem with the Functor/Cofunctor instances is that they are > ambiguous as soon as a type constructor X is made an instance of both > Functor and Cofunctor . Of course, such an X cannot exist in a > mathematically useful way (really ?) I think, it can: newtype Const a b = MkConst a instance Functor (Const a) where fmap fun (MkConst a) = MkConst a instance Cofunctor (Const a) where cofmap fun (MkConst a) = MkConst a > [?] Best wishes, Wolfgang From stefan at cs.uu.nl Wed Aug 1 13:47:00 2007 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Wed Aug 1 13:39:21 2007 Subject: [Haskell] Type Lambdas in Gofer In-Reply-To: <20070801061520.GC6033@localhost.localdomain> References: <3BB5A198-5C4F-455A-BBF1-8908DB60DD36@uni-muenster.de> <20070801061520.GC6033@localhost.localdomain> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wolfgang, >>> Why did Gofer have this power while Haskell does not? > Quite probably they never bothered to test it. More probably ;-) they did test it and just swept it under the carpet in order not to pollute the paper with this detail. From a theoretical point of view, one could argue that it indeed does not matter all that much here. Cheers, Stefan - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGsMcQX0lh0JDNIpwRAsGfAJ9q01MGgxY0/xuQSVuEVcIbrdMvmgCffYrS OVgdcXXgDpcneXGxAw+VF4g= =EeQ2 - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGsMcUX0lh0JDNIpwRAicdAKCA66w62+V+yKRpYjV86BbnNSMQpwCcDghZ t+G0sPzvIfdVaSO5pLLwNos= =H1MX -----END PGP SIGNATURE----- From conal at conal.net Wed Aug 1 16:10:32 2007 From: conal at conal.net (Conal Elliott) Date: Wed Aug 1 16:02:51 2007 Subject: [Haskell] Re: type class instance selection & search In-Reply-To: References: Message-ID: On 7/31/07, jeff p wrote: > Hello, > > My understanding is that this sort of instance collection doesn't > > work together because instance selection is based only on the > > matching the head of an instance declaration (part after the > > "=>"). I'm wondering why not use the preconditions as well, via a > > Prolog-like, backward-chaining search for much more flexible > > instance selection? Going further, has anyone investigated using > > Prolog as a model for instance selection? > I have also wanted more powerful, Prolog-like search for instance > selection; it would be particularly convenient to think of type > variables as logic variables. > I think the main argument against this is that it fundamentally > changes the interpretation of constraints; in particular, if you > really used a Prolog-style search, the order in which you place > constraints can affect type checking. Is there a sensible way for > instance selection to depend on the "body" which doesn't result in > this? How could constraint order affect type checking? Via "cut" ("!")? I'd omit cut. I see how order of constraints or instance declarations might determine order of solutions produced (as in Prolog). If the compiler rejects ambiguity (existence of multiple solutions), then I'd wouldn't expect the order to have any visible effect. > > Better yet, how about LambdaProlog ( > > http://www.lix.polytechnique.fr/Labo/Dale.Miller/lProlog), which > > generalizes from Horn clauses to (higher-order) hereditary Harrop > > formulas, including (restricted but powerful) universals, > > implication, and existentials? > Having hereditary Harrop formulas at the type level would be > cool. It would also probably require type level lambdas. Type level lambdas may not be necessary for HHFs. For simplicity, LambdaProlog encodes its universals and existentials via lambdas. I think we could use type lambdas if we wanted but wouldn't have to. Personally, I'd like to have type level lambdas, assuming we can implement them soundly. > There was a recent discussion about type level lambdas in Haskell > which ended with the observations that 1) it would mess up > unification (i.e. make it undecidable and/or too hard) to have > explicit type level lambdas; and 2) they are already implicitly > there (this was pointed out by Oleg) since one can define a type > level application and type level functions. I think 1) is a bit of a > cop-out since you could always restrict to pattern unification > (L-lamda unification) which is decidable and has MGUs. 2) is true, > but these implicit lambdas don't play very well with instance > selection and require that all reductions are spelled out via an > Apply type class. > I think it might be useful/interesting to have type level lambdas, > and pattern unification, even without turning instance selection > into proof search. Agreed. And vice versa. > > Once search is in there, ambiguity can arise, but perhaps the > > compiler could signal an error in that case ( i.e., if the > > ambiguity is not eliminated by further search pruning). > This seems like a slippery slope to me. > Although I would like having a full fledged (higher-order) logic > programming language in which to write type level programs, I am not > sure it's a good idea for Haskell in general. I tend to get > concerned when type class constraints get too big/complicated to be > obviously correct-- what good is the type checker saying something > satisfies a constraint if we're not sure that the specification of > the constraint itself is correct? > -Jeff I like this goal of and motivation for simplicity in type specifications. My hope is that a Lambda-Prolog (or some such, and minus cut) would provide a simpler (and more expressive) basis than the very tricky encodings available now (type level function application, backtracking with type-level numeral annotations, etc). - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20070801/3c5e4d4c/attachment-0001.htm From conal at conal.net Wed Aug 1 16:23:00 2007 From: conal at conal.net (Conal Elliott) Date: Wed Aug 1 16:15:21 2007 Subject: [Haskell] Re: type class instance selection & search In-Reply-To: References: Message-ID: On 8/1/07, apfelmus wrote: > There are some fundamental problems/design choices for type classes > in conjunction with separate compilation/modularity that need to be > researched before trying anything like that. In particular, any > ad-hoc Prolog, CHR or -fallow-undecidable-instances just ignores > these problems and doesn't solve them. > The problem with the Functor/Cofunctor instances is that they are > ambiguous as soon as a type constructor X is made an instance of > both Functor and Cofunctor . Of course, such an X cannot exist in a > mathematically useful way (really ?) but the current system doesn't > allow to tell this to the compiler. Alas, we can always say > instance Functor F where > fmap = undefined > instance Cofunctor F where > cofmap = undefined > The problem is not so much that there might be ambiguities, but how > to detect and when to report them. I agree: and my intent is that the compiler would detect and report the ambiguity as an error. > Consider: > module F where > class Functor f > class Cofunctor f > module O where > import F > data O f g a > instance (Functor g, Functor f ) => Functor (O g f) > instance (Cofunctor g, Cofunctor f) => Functor (O g f) > module X where > import F > data X a > instance Functor X > instance Cofunctor X > module Unsound where > import F > import O > import X > type Unsound a = O X X a > The current design rejects module O. > - Another possible design choice is to reject only module Unsound, i.e. > when the conflicting instance declarations both come into scope. But it > may be tricky/undecidable to to detect such conflicting instances. > - A third possibility is to reject module X based on hypothetical > information from module F that states that the instances of Functor and > Cofunctor are disjoint. > - The fourth choice is to not reject any module but to wait until a > function really uses the type Unsound a and to reject this function. > This is probably a bad idea since this may delay the error even further > to modules that import Unsound. I'd be much happier with any of the latter three options than with the current design. - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20070801/db9833ce/attachment.htm From malexand at wu-wien.ac.at Wed Aug 1 19:42:03 2007 From: malexand at wu-wien.ac.at (Michael Alexander) Date: Wed Aug 1 19:34:31 2007 Subject: [Haskell] Call for Book Chapters: Process Algebra/Algebraic Languages/Specification-based AD Message-ID: <46B11A4B.9090107@wu-wien.ac.at> Apologies if you received multiple copies of this message CALL FOR BOOK CHAPTERS BOOK TITLE: Process Algebra for Parallel and Distributed Processing: Algebraic Languages in Specification-Based Software Development EDITORS: Michael Alexander, WU Wien Bill Gardner, University of Guelph The book will be published in the Computational Science Series by Chapman and Hall/CRC Press in 2008 INTRODUCTION: Programming today's multi-core processor architectures, clusters, and grids is hard. Compiler research -- despite years of effort -- has still not produced implicit instruction parallelism detection that goes much beyond that of basic loop-parallelism. In addition, parallel programming in the past two decades has seen only measured improvements in parallel algorithms, languages with parallel expressivity, frameworks, and distributed validation support. As compilers have failed to deliver on their original promises, the objective of easing fine-grained parallel application programmability remains. As a consequence, new and additional paradigms are being looked at to solve what amounts to an emerging "parallel software development crisis". The approach that looks most promising is that of specification-based software development. It has its origins 3 decades ago, and it has been in a holding state for many years, only to re-emerge to a wider audience with the advent of the Object Management Group's Model Driven Architecture (MDA). Yet, specification-based software development can only deliver correct, parallel and distributed programs if the specification is precise, sufficiently expressive, and complete. Here, algebraic languages and process algebras are the paradigm that could catalyze solutions to many problems hampering efficient multi-core processor, cluster, and grid programmability problems. They are moving into a wide realm, as evidenced by the recent release of an interpreter for the algebraic Sun Fortress Language. The book is targeted to bring together the state-of-the-art in research on the application of algebraic languages and process algebras to parallel and distributed processing. It will be written to the problem statement of programming today's multi-core processor architectures, clusters, and grids. RECOMMENDED TOPICS INCLUDE BUT ARE NOT LIMITED TO THE FOLLOWING: The book aims to extensively treat algebraic languages/process algebras in parallel processing, embodying the state-of-the-art in many of the following non-inclusive list of subtopics, emphasizing an algebraic approach in each. Parallelism-oriented algebraic languages Process calculi as catalysts to solving the concurrent programming challenge Challenges in parallel programming Formal models in distributed and parallel processing Model checking, verification techniques Program transformation Axiomatizations Concurrent languages Formal semantics Formal object-oriented languages Algebras in the theory of parallel processing and distributed computing (Object oriented) distributed systems algebras Algebras and library-based approaches Frameworks supporting algebraic implementations MPI and process algebras Algebraic treatments of parallel and distributed databases (relational algebras/calculi) Concurrent composition Program generation Specification methods, notations and languages (Z, VDM-SL, B, etc.) Model and algebra transformation Operational semantics of distributed/parallel algebraic languages Parallel and distributed system specification Process algebra compilers Timed algebras Actor models CCS/CSP/ACP/Pi-Calculus/etc. in parallel-and distributed processing Equational Reasoning Software reliability/safety-critical systems Proofs Compositional/noncompositional methods Formal software development Integrated development environments for formal software Tools Case studies The editors invite the submission of abstracts (300-600 words) for proposed chapters, not under consideration elsewhere. Format and preparation instructions for full chapter submissions will be supplied to authors of accepted abstracts. Submitted chapters will undergo peer review. IMPORTANT DATES: Abstracts deadline, August 6, 2007 Notify accepted abstracts, August 13, 2007 Chapters deadline, Sep. 3, 2007 Notify accepted chapters, Dec. 17, 2007 Final manuscripts with index word lists, Feb. 18, 2008 HOW TO SUBMIT: Please post an abstract of your planned submission via EDAS at http://edas DOT info/newPaper.php?c=5487 There, create an EDAS account and paste the abstract text into the paper registration form. The book's website can be found at: http://carmel.cis.uoguelph.ca/paBook Editor Contacts Dr. Michael Alexander Wirtschaftsuniversitaet Wien Department of Information Systems and Process Management Augasse 2-6 A-1090 Vienna, Austria Email: malexand@wu-wien.ac.at Telephone: +43.1.31336.4467 Dr. William Gardner University of Guelph Department of Computing and Information Science 50 Stone Rd E Guelph, ON, N1G 2W1, Canada Email: wgardner@cis.uoguelph.ca Telephone: +1.519.824.4120 x52696 From conal at conal.net Wed Aug 1 20:29:19 2007 From: conal at conal.net (Conal Elliott) Date: Wed Aug 1 20:21:39 2007 Subject: [Haskell] Quantified class constraints (& back-chaining) Message-ID: I'm developing a type constructor class and want the constraint forall a. Monoid (m a) (where m :: * -> *), which is neither legal Haskell, nor supported by GHC. As a work-around, I used the first encoding suggested in "Simulating Quantified Class Constraints" (Valery Trifonov, Haskell Workshop '03). Add a type class class Monoid_f m where mempty_f :: forall a. m a mappend_f :: forall a. m a -> m a -> m a and an instance *schema* -- instance Monoid_f f where { mempty_f = mempty ; mappend_f = mappend } to instantiate manually wherever necessary. For instance, instance Monoid_f [] where { mempty_f = mempty ; mappend_f = mappend } The paper's second approach is to replace the schema and multiple instantiations with a single instance. instance Monoid_f f => Monoid (f a) where { mempty = mempty_f ; mappend = mappend_f } As the paper points out, Unfortunately, due to the type variable f in the head of the instance type, > this declaration is not in Haskell 98; however, at least two implementations > support extensions allowing such declarations. > Sadly, this solution runs into the problem of instance selection based only on head-matching, not back-chaining into constraints. For instance, I'd like also to use the following "conflicting" declaration. instance (Applicative f, Monoid a) => Monoid (f a) where mempty = pure mempty mappend = liftA2 mappend What's the state of thinking & doing with regard to universally quantified class constraints? Note that hereditary Harrop formulas do include universally quantified goals. Less ambitiously, I think GHC's type-checker already deals with universally-quantified variables, so perhaps quantified constraints are not a great reach (just guessing). Cheers, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20070801/dfbb0c6f/attachment.htm From stefanor at cox.net Wed Aug 1 20:57:32 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Wed Aug 1 20:49:54 2007 Subject: [Haskell] Quantified class constraints (& back-chaining) In-Reply-To: References: Message-ID: <20070802005732.GA4425@localhost.localdomain> On Wed, Aug 01, 2007 at 05:29:19PM -0700, Conal Elliott wrote: > Sadly, this solution runs into the problem of instance selection based only > on head-matching, not back-chaining into constraints. For instance, I'd > like also to use the following "conflicting" declaration. > > instance (Applicative f, Monoid a) => Monoid (f a) where > mempty = pure mempty > mappend = liftA2 mappend No quotes - [] is both Applicative and Monoid. Should [String] ["ab","cd"] `mappend` ["ef","gh"] give ["ab","cd","ef","gh"] or ["abef","abgh","cdef","cdgh"]? > What's the state of thinking & doing with regard to universally quantified > class constraints? > > Note that hereditary Harrop formulas do include universally quantified > goals. Less ambitiously, I think GHC's type-checker already deals with > universally-quantified variables, so perhaps quantified constraints are not > a great reach (just guessing). It's something I've wanted... Got a link for hereditary Harrop formulas so I can add them to my to-implement-when-Qhc-is-good-enough list? Google isn't telling me much about them except how to add support for constaints, which isn't terribly helpful. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell/attachments/20070801/0410c559/attachment.bin From mutjida at gmail.com Wed Aug 1 23:59:22 2007 From: mutjida at gmail.com (jeff p) Date: Wed Aug 1 23:51:40 2007 Subject: [Haskell] Quantified class constraints (& back-chaining) In-Reply-To: <20070802005732.GA4425@localhost.localdomain> References: <20070802005732.GA4425@localhost.localdomain> Message-ID: Hello, > It's something I've wanted... Got a link for hereditary Harrop formulas > so I can add them to my to-implement-when-Qhc-is-good-enough list? > Google isn't telling me much about them except how to add support for > constaints, which isn't terribly helpful. > This paper has a good description; it focuses on how to make a logic programming language based on them. http://www.lix.polytechnique.fr/Labo/Dale.Miller/papers/apal91.pdf -Jeff From simonpj at microsoft.com Thu Aug 2 03:34:50 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Aug 2 03:27:12 2007 Subject: [Haskell] Quantified class constraints (& back-chaining) In-Reply-To: References: Message-ID: See also the paper that Ralf and I wrote about "Derivable type classes" (on my pubs page) which uses quantified constraints. Quantified constraints would be another perfectly sensible extension. GHC does not support them at the moment though. I'm really not too sure how much work it'd be to add them; quite significant I suspect. Simon From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Conal Elliott Sent: 02 August 2007 01:29 To: haskell@haskell.org Subject: [Haskell] Quantified class constraints (& back-chaining) I'm developing a type constructor class and want the constraint forall a. Monoid (m a) (where m :: * -> * ), which is neither legal Haskell, nor supported by GHC. As a work-around, I used the first encoding suggested in "Simulating Quantified Class Constraints" (Valery Trifonov, Haskell Workshop '03). Add a type class class Monoid_f m where mempty_f :: forall a. m a mappend_f :: forall a. m a -> m a -> m a and an instance *schema* -- instance Monoid_f f where { mempty_f = mempty ; mappend_f = mappend } to instantiate manually wherever necessary. For instance, instance Monoid_f [] where { mempty_f = mempty ; mappend_f = mappend } The paper's second approach is to replace the schema and multiple instantiations with a single instance. instance Monoid_f f => Monoid (f a) where { mempty = mempty_f ; mappend = mappend_f } As the paper points out, Unfortunately, due to the type variable f in the head of the instance type, this declaration is not in Haskell 98; however, at least two implementations support extensions allowing such declarations. Sadly, this solution runs into the problem of instance selection based only on head-matching, not back-chaining into constraints. For instance, I'd like also to use the following "conflicting" declaration. instance (Applicative f, Monoid a) => Monoid (f a) where mempty = pure mempty mappend = liftA2 mappend What's the state of thinking & doing with regard to universally quantified class constraints? Note that hereditary Harrop formulas do include universally quantified goals. Less ambitiously, I think GHC's type-checker already deals with universally-quantified variables, so perhaps quantified constraints are not a great reach (just guessing). Cheers, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20070802/454d4727/attachment-0001.htm From h.guenther at tu-bs.de Thu Aug 2 06:22:56 2007 From: h.guenther at tu-bs.de (Henning =?ISO-8859-1?Q?G=FCnther?=) Date: Thu Aug 2 06:14:08 2007 Subject: [Haskell] ANN: encoding-0.1 release Message-ID: <1186050176.5778.27.camel@pandemonium.gnet> Dear fellow Haskellers, I'm proud to announce the release of "encoding", a Haskell library to cope with many character encodings found on modern computers. This (probably) bug-ridden release should mainly be used to critize it and to find out if it could be actually useful for anyone. At the moment it supports (much more is planned): ASCII (lame, I know) UTF-8, -16, -32 ISO 8859-* (alias latin-*) CP125* (windows codepages) KOI8-R Bootstring (base for punycode) You can find the darcs repository on [1] and a tarball on [2]. So please, send comments, bugs, suggestions and code! Henning [1] http://code.haskell.org/encoding/ [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/encoding-0.1 From bortzmeyer at nic.fr Thu Aug 2 07:50:37 2007 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu Aug 2 07:42:55 2007 Subject: [Haskell] Re: ANN: encoding-0.1 release In-Reply-To: <1186050176.5778.27.camel@pandemonium.gnet> References: <1186050176.5778.27.camel@pandemonium.gnet> Message-ID: <20070802115037.GA3111@nic.fr> On Thu, Aug 02, 2007 at 12:22:56PM +0200, Henning G?nther wrote a message of 26 lines which said: > UTF-8, -16, -32 Thanks, but this is only the sixth or seventh free library to do UTF-8 in Haskell :-) Yes, I recognize that you also handle other encodings, but wouldn't it be better to have one standard library, available with every Haskell compiler, out of the box? Specially, the fact there is no one standard Haskell UTF-8 I/O library is a real problem. From h.guenther at tu-bs.de Thu Aug 2 08:22:48 2007 From: h.guenther at tu-bs.de (Henning =?ISO-8859-1?Q?G=FCnther?=) Date: Thu Aug 2 08:13:59 2007 Subject: [Haskell] Re: ANN: encoding-0.1 release In-Reply-To: <20070802115037.GA3111@nic.fr> References: <1186050176.5778.27.camel@pandemonium.gnet> <20070802115037.GA3111@nic.fr> Message-ID: <1186057368.5778.36.camel@pandemonium.gnet> Am Donnerstag, den 02.08.2007, 13:50 +0200 schrieb Stephane Bortzmeyer: > On Thu, Aug 02, 2007 at 12:22:56PM +0200, > Henning G?nther wrote > a message of 26 lines which said: > > > UTF-8, -16, -32 > > Thanks, but this is only the sixth or seventh free library to do UTF-8 > in Haskell :-) Yes, but it uses ByteStrings for conversion, unlike most others which use Strings. I think this approach is much more cleaner. > Yes, I recognize that you also handle other encodings, but wouldn't it > be better to have one standard library, available with every Haskell > compiler, out of the box? Well, all haskell compilers are of course free to adopt my library (or parts of it) into their standard library. See it as a standard proposal. > Specially, the fact there is no one standard Haskell UTF-8 I/O library > is a real problem. There could be one now :) Question is, do you like the API? That's the most crucial question in adopting something like this as a standard, the rest is implementation detail. From conal at conal.net Thu Aug 2 10:35:30 2007 From: conal at conal.net (Conal Elliott) Date: Thu Aug 2 10:27:48 2007 Subject: [Haskell] Quantified class constraints (& back-chaining) In-Reply-To: <20070802005732.GA4425@localhost.localdomain> References: <20070802005732.GA4425@localhost.localdomain> Message-ID: > On Wed, Aug 01, 2007 at 05:29:19PM -0700, Conal Elliott wrote: > > Sadly, this solution runs into the problem of instance selection based only > > on head-matching, not back-chaining into constraints. For instance, I'd > > like also to use the following "conflicting" declaration. > > > > instance (Applicative f, Monoid a) => Monoid (f a) where > > mempty = pure mempty > > mappend = liftA2 mappend > No quotes - [] is both Applicative and Monoid. Should [String] > ["ab","cd"] `mappend` ["ef","gh"] give ["ab","cd","ef","gh"] or > ["abef","abgh","cdef","cdgh"]? > Sure enough - a genuine conflict. Thanks for the simple counter-example, Stefan. > > What's the state of thinking & doing with regard to universally quantified > > class constraints? > > > > Note that hereditary Harrop formulas do include universally quantified > > goals. Less ambitiously, I think GHC's type-checker already deals with > > universally-quantified variables, so perhaps quantified constraints are not > > a great reach (just guessing). > It's something I've wanted... Got a link for hereditary Harrop formulas > so I can add them to my to-implement-when-Qhc-is-good-enough list? > Google isn't telling me much about them except how to add support for > constaints, which isn't terribly helpful. In addition to the "uniform proofs" paper Jeff P mentioned, here's a paper that describes a progression of interpreters in ML, including HHFs. The culmination is a somewhat efficient implementation of a language very like LambdaProlog. http://citeseer.ist.psu.edu/elliott90semifunctional.html Cheers, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20070802/dda680cf/attachment.htm From demis at dimi.uniud.it Thu Aug 2 11:01:30 2007 From: demis at dimi.uniud.it (Demis) Date: Thu Aug 2 10:53:49 2007 Subject: [Haskell] CFP: 3rd Int'l Workshop on Automated Specification and Verification of Web Systems (WWV'07) Message-ID: [ We apologize for multiple copies ] ******************************************************************* Preliminary Call For Papers 3rd International Workshop on Automated Specification and Verification of Web Systems (WWV'07) San Servolo island, Venice (Italy) December 14, 2007 http://wwv07.dimi.uniud.it/ ******************************************************************* SCOPE The increased complexity of Web sites and the explosive growth of Web-based applications has turned their design and construction into a challenging problem. Nowadays, many companies have diverted their Web sites into interactive, completely-automated, Web-based applications (such as Amazon, on-line banking, or travel agencies) with a high complexity that requires appropriate specification and verification techniques and tools. Systematic, formal approaches to the analysis and verification can address the problems of this particular domain with automated and reliable tools that also incorporate semantic aspects. We solicit original papers on formal methods and techniques applied to Web sites, Web services or Web-based applications, such as: * rule-based approaches to Web site analysis, certification, specification, verification, and optimization * formal models for describing and reasoning about Web sites * model-checking, synthesis and debugging of Web sites * abstract interpretation and program transformation applied to the semantic Web * intelligent tutoring and advisory systems for Web specifications authoring * Web quality and Web metrics * Web usability and accessibility * Testing and evaluation of Web systems and applications The WWV series provides a forum for researchers from the communities of Rule-based programming, Automated Software Engineering, and Web-oriented research to facilitate the cross-fertilization and the advancement of hybrid methods that combine the three areas. LOCATION WWV'07 will be held in December in the convention centre of the island of San Servolo, Venice, Italy. SUBMISSION PROCEDURE Submissions must be received by October 21, 2007. In addition, an ASCII version of the title and abstract must have been submitted by October 14, 2007. Submitted papers should be at most 15 pages in the Electronic Notes in Theoretical Computer Science (ENTCS) style, and should include an abstract and the author's information. See the author's instructions of ENTCS style at http://www.entcs.org. PUBLICATION Accepted papers will be published in a preliminary proceedings volume, which will be available during the workshop. Publication of the workshop post-proceedings in the Elsevier series Electronic Notes in Theoretical Computer Science (ENTCS) is envisaged. PROGRAM CO-CHAIRS Santiago Escobar (Technical University of Valencia, Spain) Massimo Marchiori (University of Padova, Italy) WORKSHOP CHAIR Demis Ballis (University of Udine, Italy) PROGRAM COMMITTEE (to be announced) IMPORTANT DATES Abstract Submission October 14, 2007 Full Paper Submission October 21, 2007 Acceptance Notification November 12, 2007 Camera Ready November 23, 2007 Workshop December 14, 2007 (temptative) From g9ks157k at acme.softbase.org Thu Aug 2 12:44:40 2007 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Aug 2 12:37:12 2007 Subject: [Haskell] ANN: encoding-0.1 release In-Reply-To: <1186050176.5778.27.camel@pandemonium.gnet> References: <1186050176.5778.27.camel@pandemonium.gnet> Message-ID: <200708021844.40272.g9ks157k@acme.softbase.org> Am Donnerstag, 2. August 2007 12:22 schrieb Henning G?nther: > [?] > ISO 8859-* (alias latin-*) Not every ISO-8859-* encoding is a Latin-* encoding. > [?] Wouldn?t it be good to use some already existing library like iconv or do you think, this is not feasible (because you want to support lazyness, for example)? > [?] Best wishes, Wolfgang From wss at cs.nott.ac.uk Thu Aug 2 13:29:29 2007 From: wss at cs.nott.ac.uk (Wouter Swierstra) Date: Thu Aug 2 13:22:11 2007 Subject: [Haskell] The Monad.Reader (8) - Extended Deadline Message-ID: <842883BD-297C-4814-9287-188081EBBA4A@cs.nott.ac.uk> Call for Copy The Monad.Reader - Issue 8 I would like to welcome articles for the next issue of The Monad.Reader. Due to a lack of submissions, I have extended the deadline for the next issue to ** September 1st, 2007 ** Please consider writing something for this issue to help The Monad.Reader over the summer! * The Monad.Reader * The Monad.Reader is an electronic magazine about all things Haskell. It is less formal than a journal, but somehow more enduring than a wiki-page. There have been a wide variety of articles including: puzzles, book reviews, code snippets, tutorials, and half-baked research ideas. * Submission Details * Get in touch with me if you intend to submit something -- the sooner you let me know what you're up to, the better. Please submit articles for the next issue by e-mail (wss at cs.nott.ac.uk) to me before September 1st, 2007. Articles should be written according to the guidelines available from: http://www.haskell.org/haskellwiki/The_Monad.Reader Please submit a .pdf of your article, together with your source files. The sources will be released together with the magazine under a BSD license. If you would like to submit an article, but have trouble with LaTeX please let me know and we'll sort something out. Looking forward to your submission, Wouter From bjorn.buckwalter at gmail.com Thu Aug 2 16:27:47 2007 From: bjorn.buckwalter at gmail.com (=?ISO-8859-1?Q?Bj=F6rn_Buckwalter?=) Date: Thu Aug 2 16:20:06 2007 Subject: [Haskell] ANNOUNCE: Dimensional 0.6 -- Statically checked physical dimensions Message-ID: <8b2a1a960708021327u39dc798dga71913c40553def5@mail.gmail.com> Dear all, I am pleased to announce version 0.6 of the Dimensional library. Dimensional is a library providing data types for performing arithmetic with physical quantities and units. Information about the physical dimensions of the quantities/units is embedded in their types and the validity of operations is verified by the type checker at compile time. The boxing and unboxing of numerical values as quantities is done by multiplication and division with units. The library is designed to, as far as is practical, enforce/encourage best practices [1] of unit usage. Noteworthy changes/additions since the previous formal announcement (version 0.4) are: - All quantities and SI units from [1] have been added. - A Prelude replacement with the SI units and dimensional operators (+, *, ^...) is provided for convenience. - Interface to Data.Time using 'fromDiffTime' and 'toDiffTime'. - Phantom type tags make extended dimensions safer. - Experimental CGS units with type safe conversions to/from SI. See appended literate Haskell module for details. Additional information and code is available from the project web site [3]. Thank you, Bjorn Buckwalter [1] http://physics.nist.gov/Pubs/SP811/ [2] http://www.haskell.org/pipermail/haskell/2007-May/019496.html [3] http://code.google.com/p/dimensional/ ~~~~~~~~~~ BEGIN 'Buckwalter/Dimensional/CGS.lhs' ~~~~~~~~~~ Buckwalter.Dimensional.CGS -- CGS system of units Bjorn Buckwalter, bjorn.buckwalter@gmail.com License: BSD3 *** EXPERIMENTAL *** = Introduction = This module was prompted by an email from Chuck Blake[1]. He asked if the Dimensional library could support other systems of units than SI, in particular systems such as the centimeter-gram-second (CGS) system where fractional exponents of dimensions occur. He also wondered whether it was possible to convert quantities between different systems while statically ensuring that a given conversion was valid. In this module we show that we can in a straight forward manner support systems with rational exponents, provided that the rationals that may be encountered are known a priori. As an example we provide a rudimentary implementation of the CGS system. We also show that we can indeed statically prohibit invalid conversions between different systems. = Caveats = I'm ignorantly assuming that when working with the CGS (or MKS) system you will only (meaningfully?) encounter half-exponents and only of the length and mass dimensions. Of course, in other systems other rational exponents may be encountered. I am also assuming that the CGS system would not be employed when working with temperature, amount or luminosity. This is evident in the below type signatures where I have assumed zero extent in the temperature, amount and luminosity dimensions. If this is incorrect I would appreciate pointers to the CGS representation of these dimensions. Please correct and inform me if my assumptions are wrong! = Preliminaries = > {-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances #-} > module Buckwalter.Dimensional.CGS where > import Prelude ( undefined, Num, Fractional, Floating, Show, recip, Double ) > import qualified Prelude > import Buckwalter.Dimensional hiding ( DLength, DMass, DTime, DElectricCurrent ) > import Buckwalter.Dimensional.Quantities as SIQ > import qualified Buckwalter.Dimensional.SIUnits as SI > import qualified Buckwalter.NumType as N > import Buckwalter.NumType ( Neg2, Neg1, Zero, Pos, Pos1, Pos2, Pos3, NumType ) > import Buckwalter.NumType ( neg2, neg1, zero, pos1, pos2, pos3 ) > import Data.Maybe (catMaybes) = Dimensions = Analogously with the SI we collect the base dimensions of the CGS system in the data type 'CGSDim'. > data CGSDim lh mh t In the above 'lh' and 'mh' represent the number of half-exponents of length and mass respectively while 't' represents the number of whole-exponents. The base dimensions illustrate this. > type DLength = CGSDim Pos2 Zero Zero > type DMass = CGSDim Zero Pos2 Zero > type DTime = CGSDim Zero Zero Pos1 We add a few non-base dimensions for the sake of example. Charge is particularly interesting as it illustrates the need for half-exponents as described in [2]. > type DElectricCurrent = CGSDim Pos3 Pos1 Neg2 > type DCharge = CGSDim Pos3 Pos1 Neg1 = 'Mul', 'Div', 'Pow' and 'Root' instances = The 'Mul', 'Div', 'Pow' and 'Root' instances are strictly analogous with the SI. > instance ( N.Sum lh lh' lh'' > , N.Sum mh mh' mh'' > , N.Sum t t' t'' ) => Mul (CGSDim lh mh t) > (CGSDim lh' mh' t') > (CGSDim lh'' mh'' t'') > instance ( N.Sum lh lh' lh'' > , N.Sum mh mh' mh'' > , N.Sum t t' t'' ) => Div (CGSDim lh'' mh'' t'') > (CGSDim lh' mh' t') > (CGSDim lh mh t) > instance ( N.Mul lh x lh' > , N.Mul mh x mh' > , N.Mul t x t' ) => Pow (CGSDim lh mh t) x > (CGSDim lh' mh' t') > instance ( N.Div lh x lh' > , N.Div mh x mh' > , N.Div t x t' ) => Root (CGSDim lh mh t) x > (CGSDim lh' mh' t') = Units = We define the base units of the system. By defining 'meter' with a "scale" of 100 we get a scale of one for 'centi meter'. > meter :: Num a => Unit DLength a > meter = Dimensional 100 > gram :: Num a => Unit DMass a > gram = Dimensional 1 > second :: Num a => Unit DTime a > second = Dimensional 1 We continue by defining the CGS equivalents of the other base SI units. Actually we limit ourselves to 'ampere' since I am not sure if or how the SI base dimensions other than current are expressed in CGS. > ampere :: Floating a => Unit DElectricCurrent a > ampere = prefix (recip 3.33564e-10) ((SI.centi meter ^ pos3) ^/ pos2 * gram ^/ pos2 * second ^ neg2) We also define the preferred CGS unit for charge. > franklin :: Floating a => Unit DCharge a -- Also known as "esu". > franklin = gram ^/ pos2 * (SI.centi meter ^ pos3) ^/ pos2 / second = Conversion from SI = At some point we may wish to convert an SI quantity to a CGS quantity or vice versa. In order to convert a 'Quantity' from the SI system to the CGS system we use the strategy of dividing the quantity by the SI base unit and multiplying the resulting number (sans dimension) by the equivalent CGS unit. To realize this strategy we must be able to obtain the SI base unit and the equivalent CGS unit for a given quantity. We start with the SI unit since it is trivial. > unit_SI :: Num a => Quantity (Dim l m t i th n j) a -> Unit (Dim l m t i th n j) a > unit_SI _ = Dimensional 1 (Perhaps the above function would be better defined in another module.) Obtaining the CGS unit corresponding to the SI base unit of a Quantity isn't quite as trivial. The function body itself is straight-forward enough, the hairy part is the type signature. > unit_CGS :: forall a l m t i l2 m2 il it l' m' t'. > ( Floating a > , N.Mul Zero l Zero, N.Mul Pos2 l l2 > , N.Mul Zero m Zero, N.Mul Pos2 m m2 > , N.Mul Zero t Zero, N.Mul Pos1 t t > , N.Sum l2 Zero l2 > , N.Sum Zero m2 m2, N.Sum m2 Zero m2 > , N.Sum Zero t t > , N.Mul Pos3 i il > , N.Mul Pos1 i i > , N.Mul Neg2 i it > , N.Sum l2 il l' > , N.Sum m2 i m' > , N.Sum t it t' > ) => Quantity (Dim l m t i Zero Zero Zero) a -> Unit (CGSDim l' m' t') a > unit_CGS _ = meter ^ (undefined :: l) > * SI.kilo gram ^ (undefined :: m) > * second ^ (undefined :: t) > * ampere ^ (undefined :: i) Note that since the base dimensions of the CGS are a subset of those of the SI the mapping of types from SI to CGS is unambiguous. Also note that complex as the type signature may be producing it is a mostly mechanical process. With the above two functions we can define the function that converts a unit from the SI. We omit the type signature since it is hairy but can be readily inferred. > fromSI x = x /~ unit_SI x *~ unit_CGS x = Conversion to SI = We use the same strategy to convert from CGS to SI. However, when converting from CGS to SI there may be several valid SI dimensionalities for any given CGS dimensionality. We will handle this ambiguity by requiring the user to specify the desired type (except when it is inferable) of the resulting quantity. For example: ] toSI (3.2 *~ centi meter) :: Length Double In order to do this we must employ lexically scoped type variables and provide the hairy type signature for the 'toSI' function. > toSI :: forall a l m t i l2 m2 il it l' m' t'. > ( Floating a > , N.Mul Zero l Zero, N.Mul Pos2 l l2 > , N.Mul Zero m Zero, N.Mul Pos2 m m2 > , N.Mul Zero t Zero, N.Mul Pos1 t t > , N.Sum l2 Zero l2 > , N.Sum Zero m2 m2, N.Sum m2 Zero m2 > , N.Sum Zero t t > , N.Mul Pos3 i il > , N.Mul Pos1 i i > , N.Mul Neg2 i it > , N.Sum l2 il l' > , N.Sum m2 i m' > , N.Sum t it t' > ) => Quantity (CGSDim l' m' t') a -> Quantity (Dim l m t i Zero Zero Zero) a > toSI x = x /~ unit_CGS (undefined :: Quantity (Dim l m t i Zero Zero Zero) a) > *~ unit_SI (undefined :: Quantity (Dim l m t i Zero Zero Zero) a) Again, the type signature is complex but deriving it is a mechanical process. = 'Show' instance = We round off by writing 'Show' instance for 'CGSDim' analogous to that of 'Dim'. Out of laziness we use the notation "sqrt(cm)" to represent halves of integral dimensions. Nothing is technically keeping us from doing a better job here. > instance forall lh mh t. > ( NumType lh > , NumType mh > , NumType t > ) => Show (CGSDim lh mh t) where > show _ = (Prelude.unwords Prelude.. catMaybes) > [ dimUnit "sqrt(cm)" (undefined :: lh) > , dimUnit "sqrt(g)" (undefined :: mh) > , dimUnit "s" (undefined :: t) > ] = Examples = Let us try the Coulomb attraction example from [2]. We start by performing the calculation in the SI. > q_si = 1.6021773e-19 *~ SI.coulomb -- Elementary charge in SI. > r_si = 0.1 *~ SI.nano SI.meter -- Distance in SI > f_si = q_si ^ pos2 / (_4 * pi * e0 * r_si ^ pos2) > where > e0 = 8.8541878e-12 *~ (SI.ampere * SI.second / (SI.volt * SI.meter)) The same calculation in the CGS system. > q_cgs = fromSI q_si -- Elementary charge in CGS. > r_cgs = fromSI r_si -- Distance in CGS > f_cgs = q_cgs ^ pos2 / r_cgs ^ pos2 Inspecting the values in GHCi shows us that the results are consistent (within reasonable accuracy) with [2]. *Buckwalter.Dimensional.CGS> f_si 2.3070794737101255e-8 m kg s^-2 *Buckwalter.Dimensional.CGS> f_cgs 2.30708078598602e-3 sqrt(cm)^2 sqrt(g)^2 s^-2 To convert from CGS to SI we must specify the type of the SI 'Quantity'. > f_si' = toSI f_cgs :: SIQ.Force Double *Buckwalter.Dimensional.CGS> f_si' 2.3070807859860202e-8 m kg s^-2 We follow up with another conversion example demonstrating the ambiguity in the conversion from CGS to SI. > c = 1 *~ SI.farad -- A SI capacitance. > c_cgs = fromSI c -- Capacitance has dimensionality L in CGS. > c' = toSI c_cgs :: SIQ.Capacitance Double > c'' = toSI c_cgs :: Length Double *Buckwalter.Dimensional.CGS> c 1.0 m^-2 kg^-1 s^4 A^2 *Buckwalter.Dimensional.CGS> c_cgs 8.98755691740885e11 sqrt(cm)^2 *Buckwalter.Dimensional.CGS> c' 1.0 m^-2 kg^-1 s^4 A^2 *Buckwalter.Dimensional.CGS> c'' 8.98755691740885e9 m = Future work = This is a very rudimentary implementation. To make it more practical a significant number of quantities and units, in particularly those commonly used with the CGS, would need to be added. In the mean time all units defined for the SI can be used with the CGS by applying 'fromSI' to quantities defined from the SI units. If anyone is willing to add quantities/units (or other enhancements) I will happily to accept patches. Personally I do not expect to use this module and therefore do not intend to invest much more time in it. If the module has other users I might reconsider. And of course, another direction of future work is to define additional systems (e.g. natural, relativistic) using this module as a template. I imagine this should be fairly straight forward. = References = [1] http://code.google.com/p/dimensional/wiki/ChuckBlake20070611 [2] http://www.tf.uni-kiel.de/matwis/amat/mw1_ge/kap_2/basics/b2_1_14.html ~~~~~~~~~~ END 'Buckwalter/Dimensional/CGS.lhs' ~~~~~~~~~~ From O.Chitil at kent.ac.uk Fri Aug 3 10:43:52 2007 From: O.Chitil at kent.ac.uk (Olaf Chitil) Date: Fri Aug 3 10:36:35 2007 Subject: [Haskell] IFL 2007: Symposium on Implementation and Application of Functional Languages Message-ID: <46B33F28.4020509@kent.ac.uk> ********************************************************************** Call for Papers and Participation 19th International Symposium on Implementation and Application of Functional Languages IFL 2007 27th-29th September 2007, Freiburg, Germany co-located with ICFP 2007 http://proglang.informatik.uni-freiburg.de/IFL2007/ ********************************************************************** ==> Submission for Draft Proceedings 31 August 2007 ==> Early Registration & Hotel Deadline 1 September 2007 The aim of the IFL symposium is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. The symposium provides an open forum for researchers who wish to present and discuss new ideas and concepts, work in progress, preliminary results, etc. related primarily but not exclusively to the implementation and application of functional languages. Topics of interest include (but are not limited to): * language concepts * type checking * compilation techniques * (abstract) interpretation * generic programming techniques * automatic program generation * array processing * concurrent/parallel programming * heap management * runtime profiling * performance measurements * debugging and tracing * (abstract) machine architectures * verification * formal aspects * tools and programming techniques Papers on applications or tools demonstrating the suitability of novel ideas in any of the above areas and contributions on related theoretical work are also welcome. The change of the symposium name adding the term "application", introduced in 2004, reflects the broader scope IFL has gained over the years. Contributions Prospective authors are encouraged to submit papers to be published in the draft proceedings and present them at the symposium. All contributions must be written in English, conform to the Springer-Verlag LNCS series format and not exceed 16 pages. The draft proceedings will appear as a technical report. Every attendee of IFL 2007 will have the opportunity to submit a revised version of their paper for post-symposium reviewing. As in previous years, selected papers will be published by Springer Verlag in the Lecture Notes in Computer Science (LNCS) Series. Important Dates Submission for Draft Proceedings 31 August 2007 Early Registration Deadline 1 September 2007 Hotel Registration Deadline 1 September 2007 Symposium 27-29 September 2007 Submission for post-refereeing 2 November 2007 Notification of acceptance / rejection 14 December 2007 Submission of camera-ready version 25 January 2008 Programme Committee Peter Achten Radboud University Nijmegen, The Netherlands Kenichi Asai Ochanomizu University, Japan Manuel Chakravarty The University of New South Wales, Australia Olaf Chitil (chair) University of Kent, UK Martin Erwig Oregon State University, Oregon, USA Marc Feeley Universit? de Montr?al, Canada Martin Gasbichler Z?hlke Engineering AG, Switzerland Kevin Hammond University of St. Andrews, Scotland Zolt?n Horv?th E?tv?s Lor?nd University, Budapest, Hungary John Hughes Chalmers University of Technology, Sweden Ken Friis Larsen University of Copenhagen, Denmark Rita Loogen Philipps-Universit?t Marburg, Germany Michel Mauny ENSTA, France Sven-Bodo Scholz University of Hertfordshire, UK Clara Segura Universidad Complutense de Madrid, Spain Tim Sheard Portland State University, Oregon, USA Glenn Strong Trinity College, Dublin, Ireland Doaitse Swierstra Utrecht University, The Netherlands Malcolm Wallace The University of York, UK Local Organisation Markus Degen Universit?t Freiburg, Germany Peter Thiemann Universit?t Freiburg, Germany Stefan Wehr Universit?t Freiburg, Germany Further Information http://proglang.informatik.uni-freiburg.de/IFL2007/ From Oege.de.Moor at comlab.ox.ac.uk Mon Aug 6 09:00:28 2007 From: Oege.de.Moor at comlab.ox.ac.uk (Oege.de.Moor@comlab.ox.ac.uk) Date: Mon Aug 6 08:52:36 2007 Subject: [Haskell] PEPM 2008 Message-ID: <200708061300.l76D0SnQ004804@mercury.comlab.ox.ac.uk> PEPM 2008 ACM SIGPLAN Workshop on Partial Evaluation and Program Manipulation January 7-8, 2008, San Francisco Keynotes by Ras Bodik (Berkeley) and Monica Lam (Stanford) Co-located with POPL http://www.program-transformation.org/PEPM08/WebHome PEPM is a leading venue for the presentation of cutting-edge research in program analysis, program generation and program transformation. Its proceedings are published by ACM Press; full details of the scope, submission process, and program committee can be found at the above URL. The program committee would particularly welcome submissions from researchers in functional programming on any topic relating to analysis, optimisation and synthesis of Haskell programs Abstracts are due on October 12, and the deadline for full paper submission is October 17. Prospective authors are welcome to contact the program chairs, Robert Glueck (glueck@acm.org) and Oege de Moor (oege@comlab.ox.ac.uk) with any queries they might have. From icfp.publicity at googlemail.com Mon Aug 6 11:54:21 2007 From: icfp.publicity at googlemail.com (Matthew Fluet (ICFP Publicity Chair)) Date: Mon Aug 6 11:46:25 2007 Subject: [Haskell] ICFP07 Call for Participation Message-ID: <53ff55480708060854h603dfb10n8494a7ce608be2da@mail.gmail.com> ===================================================================== Call for Participation The 12th ACM SIGPLAN International Conference on Functional Programming (ICFP 2007) http://www.informatik.uni-bonn.de/~ralf/icfp07.html Freiburg, Germany, 1-3 October 2007 ===================================================================== ICFP 2007 provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. Preliminary program: * http://www.informatik.uni-bonn.de/~ralf/schedule.html * Invited speakers: + John Hughes (Chalmers University of Technology) + Frank Pfenning (Carnegie Mellon University) + John Lloyd (Australian National University) * The Program committee has *deliberately* created extra breaks so as to give participants more time to talk with colleagues. Schedule including related workshops: * 30 Sep: ACM SIGPLAN Haskell Workshop * 30 Sep: ACM SIGPLAN Workshop on Scheme and Functional Programming * 1-3 Oct: ICFP07 * 4 Oct: ACM SIGPLAN Commercial Users of Functional Programming * 4 Oct: ACM SIGPLAN Workshop on Mechanizing Metatheory * 5 Oct: ACM SIGPLAN Erlang Workshop * 5 Oct: ACM SIGPLAN Workshop on ML * 5 Oct: ACM SIGPLAN Programming Languages meets Program Verification Registration information: * http://proglang.informatik.uni-freiburg.de/ICFP2007/registration.shtml * Early registration deadline: September 7, 2007 Accommodations information: * http://proglang.informatik.uni-freiburg.de/ICFP2007/accommodation.shtml * Conference reservation/rate deadline: September 1, 2007 * September/October is Freiburg's main tourist season; participants are advised to book rooms as early as possible. Conference organizers: * General Chair: Ralf Hinze (Universit?t Bonn) * Program Chair: Norman Ramsey (Harvard University) * Local Arrangements Chair: Peter Thiemann (Universit?t Freiburg) * Workshop Co-Chairs: Graham Hutton (University of Nottingham) and Matthias Blume (Toyota Technological Institute at Chicago) * Programming Contest Chair: Johan Jeuring (Universiteit Utrecht) * Publicity Chair: Matthew Fluet (Toyota Technological Institute at Chicago) From paul.hudak at yale.edu Mon Aug 6 13:05:17 2007 From: paul.hudak at yale.edu (Paul Hudak) Date: Mon Aug 6 12:57:23 2007 Subject: [Haskell] [Fwd: PADL 2008: Call for Papers] Message-ID: <46B754CD.3080005@yale.edu> -------- Original Message -------- Subject: PADL 2008: Call for Papers Date: Sat, 4 Aug 2007 19:25:58 -0500 (CDT) From: Gopal Gupta [ Colleagues, note that this will be the 10th PADL; We strongly urge you to submit papers, the deadline is only 3 weeks way] CALL FOR PAPERS!!! Tenth International Symposium on Practical Aspects of Declarative Languages 2008 (PADL '08) http://www.ist.unomaha.edu/padl2008/ San Francisco, USA January 7-8, 2008 Co-located with ACM POPL'08 Declarative languages build on sound theoretical bases to provide attractive frameworks for application development. These languages have been successfully applied to vastly different real-world situations, ranging from data base management to active networks to software engineering to decision support systems. New developments in theory and implementation have opened up new application areas. At the same time, applications of declarative languages to novel problems raises numerous interesting research issues. Well-known questions include designing for scalability, language extensions for application deployment, and programming environments. Thus, applications drive the progress in the theory and implementation of declarative systems, and benefit from this progress as well. PADL is a forum for researchers and practitioners to present original work emphasizing novel applications and implementation techniques for all forms of declarative concepts, including, functional, logic, constraints, etc. Topics of interest include: * innovative applications of declarative languages; * declarative domain-specific languages and applications; * practical applications of theoretical results; * new language developments & their impact on applications; * evaluation of implementation techniques on practical applications; * novel uses of declarative languages in the classroom; and * practical experiences PADL 08 welcomes new ideas and approaches pertaining to applications and implementation of declarative languages. PADL 08 will be co-located with the ACM POPL. IMPORTANT DATES AND SUBMISSION GUIDELINES Paper Submission: August 24, 2007 Notification: September 27, 2007 Camera-ready: October 23, 2007 Symposium: January 7-8, 2008 Authors should submit an electronic copy of the full paper (written in English) in Postscript (Level 2) or PDF. Papers must be no longer than 15 pages, written in 11-point font and with single spacing. Since the final proceedings will be published as Lecture Notes in Computer Science by Springer Verlag, authors are strongly encouraged to use the LNCS paper formatting guidelines for their submission. Each submission must include on its first page the paper title; authors and their affiliations; contact author's email and postal addresses, telephone and fax numbers, abstract, and three to four keywords. The keywords will be used to assist us in selecting appropriate reviewers for the paper. If electronic submission is impossible, please contact the program chair for information on how to submit hard copies. MOST PRACTICAL PAPER AWARD The Most Practical Paper award will be given to the submission that is judged by the program committee to be the best in terms of practicality, originality, and clarity of presentation. The program committee may choose not to make an award, or to make multiple awards. Contacts: For information about papers and submissions, please contact the Program Chair: Paul Hudak PC co-Chair - PADL 2008 Department of Computer Science Yale University P.O. Box 208285 New Haven, CT 06520 - 8285 Email: hudak@cs.yale.edu David S. Warren PC co-Chair - PADL 2008 Department of Computer Science Stony Brook University Stony Brook, NY Email: warren@cs.sunysb.edu For other information about the conference, please contact: Hai-Feng Guo General Chair - PADL 2008 Department of Computer Science College of Information Science & Technology University of Nebraska at Omaha Omaha, NE, U.S.A. Email: haifengguo@mail.unomaha.edu Sponsored by: COMPULOG Americas (http://www.cs.nmsu.edu/~complog) and University of Nebraska at Omaha -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20070806/440e5ae6/attachment.htm From dons at cse.unsw.edu.au Tue Aug 7 06:02:29 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Tue Aug 7 05:54:39 2007 Subject: [Haskell] Haskell Weekly News: August 07, 2007 Message-ID: <20070807100228.GY8756@cse.unsw.EDU.AU> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20070807 Issue 64 - August 07, 2007 --------------------------------------------------------------------------- Welcome to issue 64 of HWN, a weekly newsletter covering developments in the [1]Haskell community. This issue marks the second anniversary of the Haskell (not quite) Weekly News. Thanks to the Haskell community for support, content and for reading over the last two years! 1. http://haskell.org/ Announcements OSCON Haskell Tutorial. Simon Peyton-Jones Appeared at the O'Reilly Open Source Convention (OSCON) in Portland, delivering a range of talks, including [2]A Taste of Haskell, [3]A Keynote on Functional Languages, [4]Nested Data Parallelism and [5]Transactional Memory for Concurrent Programming. Videos are available for most of these talks: [6]A Taste of Haskell: Part 1, [7]A Taste of Haskell: Part 2, [8]slides for A Taste of Haskell, [9]Transactional Memory for Concurrent Programming and [10]the NDP talk at the London Hugs meeting. 2. http://conferences.oreillynet.com/cs/os2007/view/e_sess/14016 3. http://conferences.oreillynet.com/cs/os2007/view/e_sess/14773 4. http://conferences.oreillynet.com/cs/os2007/view/e_sess/14014 5. http://conferences.oreillynet.com/cs/os2007/view/e_sess/14017 6. http://blip.tv/file/324976 7. http://www.blip.tv/file/325646/ 8. http://conferences.oreillynet.com/presentations/os2007/os_peytonjones.pdf 9. http://www.blip.tv/file/317758/ 10. http://video.google.co.uk/videoplay?docid=370317485066035666 hpodder 1.0. John Goerzen [11]announced version 1.0.0 of hpodder, the command-line podcatcher (podcast downloader) that just happens to be written in everyone's favorite language. You can get it [12]here. Version 1.0.0 sports a new mechanism for detecting and disabling feeds or episodes that repeatedly result in errors, updates to the Sqlite database schema, and several bugfixes. 11. http://article.gmane.org/gmane.comp.lang.haskell.general/15452 12. http://software.complete.org/hpodder encoding-0.1. Henning G?nther [13]announced the release of 'encoding', a Haskell library to cope with many character encodings found on modern computers. At the moment it supports (much more is planned): ASCII, UTF-8, -16, -32, ISO 8859-* (alias latin-*), CP125* (windows codepages), KOI8-R, Bootstring (base for punycode) 13. http://article.gmane.org/gmane.comp.lang.haskell.general/15481 Dimensional 0.6: Statically checked physical dimensions. Bj?rn Buckwalter [14]announced a library providing data types for performing arithmetic with physical quantities and units. Information about the physical dimensions of the quantities/units is embedded in their types and the validity of operations is verified by the type checker at compile time. The boxing and unboxing of numerical values as quantities is done by multiplication and division with units. 14. http://article.gmane.org/gmane.comp.lang.haskell.cafe/26944 Hackage This week's new libraries in [15]the Hackage library database. * hgal-1.0.1. Jean Philippe Bernardy. [16]Computation automorphism group and canonical labeling of a graph * hpodder-1.0.3. John Goerzen. [17]Podcast Aggregator (downloader) * dlist-0.3.1. Don Stewart. [18]Differences lists: a list-like type supporting O(1) append * pointfree-1.0. Felix Martini. [19]Stand-alone command-line version of the point-less plugin for lambdabot * encoding-0.1. Henning Guenther. [20]A library for various character encodings * AppleScript-0.1.3. Wouter Swierstra. [21]Call AppleScript from Haskell * SDL-ttf-0.4.0. David Himmelstrup. [22]Binding to libSDL_ttf * Finance-Quote-Yahoo-0.2. Brad Clawsie. [23]Obtain quote data from finance.yahoo.com * xmobar-0.7. Andrea Rossato. [24]A Minimalistic Text Based Status Bar 15. http://hackage.haskell.org/ 16. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hgal-1.0.1 17. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hpodder-1.0.3 18. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dlist-0.3.1 19. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/pointfree-1.0 20. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/encoding-0.1 21. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/AppleScript-0.1.3 22. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SDL-ttf-0.4.0 23. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Finance-Quote-Yahoo-0.2 24. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xmobar-0.7 Conference roundup OSCON. Simon Peyton-Jones gave a series of popular talks about Haskell and functional programming at OSCON, in Portland. Below are collected just some of the posts about Haskell at OSCON. * [25]A brief Haskell-at-OSCON trip report * [26]Wow! OSCON video viewing statistics * [27]OSCon Wednesday Part 2 * [28]A Taste of Haskell, A Taste of C * [29]OSCON Day 1 * [30]A Taste of Haskell * [31]OSCON 2007 * [32]Threading Building Blocks and C++ * [33]OSCON: Wednesday Morning * [34]OSCON: Wednesday Afternoon * [35]OSCON 2007 (July 25) * [36]Nested Data Parallelism in Haskell * [37]OSCON 2007: Wednesday Morning Keynotes * [38]A Taste of Haskell 25. http://www.realworldhaskell.org/blog/2007/08/03/a-brief-haskell-at-oscon-trip-report/ 26. http://www.realworldhaskell.org/blog/2007/08/07/wow-oscon-video-viewing-statistics/ 27. http://changelog.complete.org/posts/632-OSCon-Wednesday-Part-2.html 28. http://www.oreillynet.com/onlamp/blog/2007/07/a_taste_of_haskell_a_taste_of.html 29. http://brycebaril.vox.com/library/post/oscon-2007-day-1.html 30. http://jaortega.wordpress.com/2007/08/04/a-taste-of-haskell/ 31. http://www.sauria.com/blog/2007/08/03/oscon-2007/ 32. http://softwareblogs.intel.com/2007/07/26/threading-building-blocks-and-c/ 33. http://znark.com/blog/2007/07/25/oscon-wednesday-morning 34. http://znark.com/blog/2007/07/25/oscon-wednesday-afternoon 35. http://panela.blog-city.com/oscon_2007_july_25.htm 36. http://ihack.us/2007/07/25/nested-data-parallelism-in-haskell/ 37. http://www.canspice.org/2007/07/25/oscon-2007-wednesday-morning-keynotes/ 38. http://butlerpress.com/2007/07/24/a-taste-of-haskell/ Blog noise [39]Haskell news from the [40]blogosphere. * [41]Ord, Countable Ordinals, and an Idea of sigfpe * [42]Word numbers, Part 1: Billion approaches * [43]Implementing SmallTalk in Haskell * [44]From walking to zipping, Part 1: Moving right * [45]From walking to zipping, Part 2: Down and up * [46]Irrefutable patterns for the ignorant * [47]Making Haskell nicer for game programming * [48]Nested Data Parallelism in Haskell * [49]Compiling Haskell to Erlang * [50]Peano's Axioms IV: Advanced Functions and Integers * [51]37 Reasons to Love Haskell * [52]On the value of strong static typing * [53]Parsec Parser Testing with QuickCheck * [54]Fallacies in the Great Dynamic vs Static Debate * [55]Implementing a dictionary using first class functions * [56]Strong specifications in Coq: the type says everything * [57]Run length encoding in Haskell * [58]Run length encoding and arrows * [59]Playing with Arrows * [60]Monads! (and Why Monad Tutorials Are All Awful) * [61]Haskell: Explaining Arrows through XML Transformations * [62]Monads as computation * [63]Closed Categories * [64]Good Haskell Style * [65]Monads are hard to teach * [66]Parsec * [67]First attempt at using GTK with Haskell * [68]Introduction to Haskell, Part 3: Monads * [69]Programming in Haskell * [70]Haskell Fun * [71]Algebraic Data Types again * [72]DFAs, Categories, and Typecheckers * [73]Haskell State Accessors (second attempt: Composability) * [74]Developing Programs and Proofs Spontaneously using GADT * [75]Encoding Inductive and Coinductive Types in Polymorphic Lambda Calculus * [76]Polymorphic Types in Haskell without Constructors? * [77]Subtraction not Definable in Simply Typed Lambda Calculus * [78]Imperative programming is a special type of functional programming * [79]Binding Haskell to C structs 39. http://planet.haskell.org/ 40. http://haskell.org/haskellwiki/Blog_articles 41. http://blog.jbapple.com/2007/07/ord-countable-ordinals-and-idea-of.html 42. http://conway.rutgers.edu/~ccshan/wiki/blog/posts/WordNumbers1/ 43. http://lstephen.wordpress.com/2007/07/23/completing-the-spike/ 44. http://conway.rutgers.edu/~ccshan/wiki/blog/posts/WalkZip1/ 45. http://conway.rutgers.edu/~ccshan/wiki/blog/posts/WalkZip2/ 46. http://therning.org/magnus/archives/311 47. http://luqui.org/blog/archives/2007/07/26/making-haskell-nicer-for-game-programming/ 48. http://ihack.us/2007/07/25/nested-data-parallelism-in-haskell/ 49. http://blog.tornkvist.org/?id=1185571582964040 50. http://disparatemathematician.blogspot.com/2007/07/peanos-axioms-iv-advanced-functions-and.html 51. http://cdsmith.wordpress.com/2007/07/29/37-reasons-to-love-haskell-playing-off-the-ruby-article/ 52. http://www.serpentine.com/blog/2007/07/29/on-the-value-of-strong-static-typing/ 53. http://lstephen.wordpress.com/2007/07/29/parsec-parser-testing-with-quickcheck/ 54. http://neilbartlett.name/blog/2007/07/30/fallacies-in-the-great-dynamic-vs-static-debate/ 55. http://lukeplant.me.uk/blog.php?id=1107301671 56. http://www.rubrication.net/2007/04/24/strong-specifications/ 57. http://cgi.cse.unsw.edu.au/~dons/blog/2007/07/31#rle 58. http://community.livejournal.com/evan_tech/229752.html 59. http://unenterprise.blogspot.com/2007/08/playing-with-arrows.html 60. http://ahamsandwich.wordpress.com/2007/07/26/monads-and-why-monad-tutorials-are-all-awful/ 61. http://neilbartlett.name/blog/2007/08/01/haskell-explaining-arrows-through-xml-transformationa/ 62. http://www.haskell.org/haskellwiki/Monads_as_computation 63. http://unapologetic.wordpress.com/2007/08/01/closed-categories/ 64. http://urchin.earth.li/~ian/style/haskell.html 65. http://davblog48.blogspot.com/2007/08/monads-are-hard-to-teach.html 66. http://davblog48.blogspot.com/2007/05/parsec.html 67. http://davblog48.blogspot.com/2007/05/first-attempt-at-using-gtk-with-haskell.html 68. http://www.onlamp.com/pub/a/onlamp/2007/08/02/introduction-to-haskell-pure-functions.html 69. http://www.cs.chalmers.se/Cs/Grundutb/Kurser/d1pt/d1pta/external.html 70. http://changelog.complete.org/posts/640-guid.html 71. http://blog.tmorris.net/algebraic-data-types-again/ 72. http://disparatemathematician.blogspot.com/2007/08/dfas-categories-and-typecheckers.html 73. http://luqui.org/blog/archives/2007/08/05/haskell-state-accessors-second-attempt-composability/ 74. http://www.iis.sinica.edu.tw/~scm/?p=32 75. http://www.iis.sinica.edu.tw/~scm/?p=31 76. http://www.iis.sinica.edu.tw/~scm/?p=28 77. http://www.iis.sinica.edu.tw/~scm/?p=27 78. http://blog.tmorris.net/imperative-programming-is-a-special-type-of-functional-programming/ 79. http://therning.org/magnus/archives/315 Quotes of the Week * schluehk: ... Haskell taking over the world and troubled parents ask why their kids have turned into math hippies talking about nothing but love and abstract algebra... * JohnGoerzen: Haskell manipulates functions with the same ease that Perl manipulates strings * (anonymous Russian blogger): Glory to Simons! Glory to Swedish professors! * Laurent Sansonetti: I appreciated so much the Haskell talks that I am now learning the language. * dcoutts: Apparently that's only 200x faster than the faster of two common python serialisation libs, so we've got some way to go yet. * slava: [on Isabelle for web frameworks] IM IN UR WEB SITEZ, CODING PROVABLY-CORRECT BLINK TAG!! * gimboland: At present i'd say 'tinkering with a nuclear bomb' is approximately where i am with monads... * jcreigh: Could not find instance Ord for type ProgrammingLanguage * kowey: i suspect we're one of the rare wikibooks to use higher order templates * monochrom: 'm a -> (a -> m b) -> m b' is much more to the point than 'mumble computation mumble computation mumble computation mumble' * roconnor: damn it, Haskell pseudo code is indistinguishable from actual code * slava: Because top enterprise industry analysts recommend Because top enterprise industry analysts recommend that managers need to focus on Agile methodologies, SOA, B2B and Yoneda's lemma in today's rich internet application-driven environment. Don't get left behind by the AJAX craze by missing out on call center outsourcing and Yoneda's lemma! Code Watch Notable new features and bug fixes to the Haskell compilers. Fri Jul 27 03:41:57 PDT 2007. Simon Marlow. Pointer Tagging. This patch implements pointer tagging as per our ICFP'07 paper 'Faster laziness using dynamic pointer tagging'. It improves performance by 10-15% for most workloads, including GHC itself. The original patches were by Alexey Rodriguez Yakushev, with additions and improvements by me. I've re-recorded the development as a single patch. The basic idea is this: we use the low 2 bits of a pointer to a heap object (3 bits on a 64-bit architecture) to encode some information about the object pointed to. For a constructor, we encode the 'tag' of the constructor (e.g. True vs. False), for a function closure its arity. This enables some decisions to be made without dereferencing the pointer, which speeds up some common operations. In particular it enables us to avoid costly indirect jumps in many cases. More information [80]in the commentary. 80. http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution/PointerTagging About the Haskell Weekly News Each week, new editions are posted to [81]the Haskell mailing list as well as to [82]the Haskell Sequence and [83]Planet Haskell. [84]RSS is also available, and headlines appear on [85]haskell.org. Headlines are available as [86]PDF. To help create new editions of this newsletter, please see the [87]contributing information. Send stories to dons at cse.unsw.edu.au. The darcs repository is available at darcs get [88]http://www.cse.unsw.edu.au/~dons/code/hwn 81. http://www.haskell.org/mailman/listinfo/haskell 82. http://sequence.complete.org/ 83. http://planet.haskell.org/ 84. http://sequence.complete.org/node/feed 85. http://haskell.org/ 86. http://www.cse.unsw.edu.au/~dons/code/hwn/archives/20070807.pdf 87. http://haskell.org/haskellwiki/HWN 88. http://www.cse.unsw.edu.au/~dons/code/hwn From mads_lindstroem at yahoo.dk Tue Aug 7 07:42:45 2007 From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=) Date: Tue Aug 7 07:37:38 2007 Subject: [Haskell] Summer of code Haddock complains about module "which is not loaded" Message-ID: <1186486965.6687.6.camel@localhost.localdomain> Hi all I am trying to use the summer of code version of haddock, which I got from the Darcs repository. I have two files: Bar.hs: module Bar where -- |Some comment bar :: Int bar = 2 and Foo.hs: module Foo where import Bar -- |Some comment. foo :: Int foo = bar + 5 when I run haddock like: > haddock -h -ohtml -B/usr/local/lib/ghc-6.7.20070729/ Foo.hs Bar.hs it complains with: Warning: Cannot use package base: HTML directory $topdir/share/ghc/doc/html/base does not exist. argument targets: Foo.hs Bar.hs all targets: Bar.hs Foo.hs Foo.hs:3:0: attempting to use module `Bar' (Bar.hs) which is not loaded haddock: Failed to check all modules properly make: *** [doc] Fejl 1 Why is it Haddock cannot find the Bar module? After all I mention Bar.hs in the invocation of haddock. Greetings, Mads Lindstr?m From davve at dtek.chalmers.se Tue Aug 7 09:48:01 2007 From: davve at dtek.chalmers.se (David Waern) Date: Tue Aug 7 09:40:03 2007 Subject: [Haskell] Summer of code Haddock complains about module "which is not loaded" In-Reply-To: <1186486965.6687.6.camel@localhost.localdomain> References: <1186486965.6687.6.camel@localhost.localdomain> Message-ID: <50492.212.209.37.162.1186494481.squirrel@webmail.chalmers.se> Hi Mads, I have fixed this in my local repo. I will push the patch later today when I'm home. The bug was due to a change in the GHC API. /David > Hi all > > I am trying to use the summer of code version of haddock, which I got > from the Darcs repository. > > I have two files: > > Bar.hs: > > module Bar where > > -- |Some comment > bar :: Int > bar = 2 > > and Foo.hs: > > module Foo where > > import Bar > > -- |Some comment. > foo :: Int > foo = bar + 5 > > when I run haddock like: > >> haddock -h -ohtml -B/usr/local/lib/ghc-6.7.20070729/ Foo.hs Bar.hs > > it complains with: > > Warning: Cannot use package base: > HTML directory $topdir/share/ghc/doc/html/base does not exist. > argument targets: > Foo.hs > Bar.hs > all targets: > Bar.hs > Foo.hs > > Foo.hs:3:0: > attempting to use module `Bar' (Bar.hs) which is not loaded > haddock: Failed to check all modules properly > make: *** [doc] Fejl 1 > > Why is it Haddock cannot find the Bar module? After all I mention Bar.hs > in the invocation of haddock. > > > Greetings, > > Mads Lindstr?m > > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > From conal at conal.net Wed Aug 8 19:24:42 2007 From: conal at conal.net (Conal Elliott) Date: Wed Aug 8 19:16:38 2007 Subject: [Haskell] ghc.haddock? Message-ID: I've heard of a version Haddock that understands all of GHC's syntax extensions. Does anyone the current status? - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20070808/e4685205/attachment.htm From simonmarhaskell at gmail.com Thu Aug 9 04:55:17 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Aug 9 04:47:15 2007 Subject: [Haskell] ghc.haddock? In-Reply-To: References: Message-ID: <46BAD675.3040609@gmail.com> Conal Elliott wrote: > I've heard of a version Haddock that understands all of GHC's syntax > extensions. Does anyone the current status? - Conal That would be the next version of Haddock, courtesy of David Waern's Summer of Code project last year. It is dependent on an unreleased version of GHC, which is why it has not been more widely announced yet. The source is here; http://darcs.haskell.org/haddock.ghc but you'll need a very recent GHC 6.7 snapshot in order to build it. Cheers, Simon From cmb21 at kent.ac.uk Thu Aug 9 05:30:15 2007 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Thu Aug 9 05:22:35 2007 Subject: [Haskell] What makes a functional language functional? Message-ID: Hi, Is lazy evaluation necessary for a functional language to remain functional? The reason I ask is that because it violates beta-reduction, and also referential transparency (I think). In haskell, we can transform: g x + f x into: f x + g x as both f and g do not change the parameter x. If g always evaluates to a normal form (in both a lazy and a strict world) g x = x but f is defined thus: f x = (\y -> if x /= 0 then x else y/x) And we apply f to 0 (1/0) then f becomes _|_ therefore: 0 + _|_ /= _|_ + 0 Or, does this just become: _|_ = _|_ ? Or, am I missing something totally obvious? Regards, Chris. From O.Chitil at kent.ac.uk Thu Aug 9 06:20:05 2007 From: O.Chitil at kent.ac.uk (Olaf Chitil) Date: Thu Aug 9 06:12:36 2007 Subject: [Haskell] What makes a functional language functional? In-Reply-To: References: Message-ID: <46BAEA55.9070203@kent.ac.uk> Chris, I'm not sure what exactly your question is as you are mixing up several concepts. However, you start with: >In haskell, we can transform: > >g x + f x > >into: > >f x + g x > > Here you assume that the function + is commutative. Although this is probably true for all numeric types in all Haskell implementations, neither functional languages in general nor the Haskell report guarantee commutativity of +. So this assumption is dangerous. >0 + _|_ /= _|_ + 0 > >Or, does this just become: > >_|_ = _|_ ? > > The Haskell report probably does not say so explicitly, but in general primitive functions like + are strict in all arguments and hence 0 + _|_ = _|_ = _|_ + 0. Ciao, Olaf From jeremy.gibbons at comlab.ox.ac.uk Thu Aug 9 06:49:53 2007 From: jeremy.gibbons at comlab.ox.ac.uk (Jeremy Gibbons) Date: Thu Aug 9 06:42:24 2007 Subject: [Haskell] What makes a functional language functional? In-Reply-To: References: Message-ID: Many arguments have been had about what it means for a language to be "functional", so that's probably not a productive line of discussion. (ICFP carefully doesn't stipulate language choice for the programming contest, for example.) Both eager and lazy evaluation can be "pure", providing referential transparency: all that matters of an expression is its value, and a subexpression may be substituted with a different one having the same value without changing the meaning of the surrounding context. This fails on languages supporting side effects. Lazy evaluation is necessary, however, in order to treat a function definition as a (universally applicable) equation. In Haskell, I can define > three x = 3 and then infer, for any expression x, that the equation three x = 3 holds. With eager evaluation, that's no longer the case: if x denotes a non-terminating or error-raising computation, then three x /= 3 The equation then requires a side condition: three x = 3, for well-defined x which complicates equational reasoning, but it doesn't break referential transparency. Jeremy On 9 Aug 2007, at 10:30, C.M.Brown wrote: > Hi, > > Is lazy evaluation necessary for a functional language to remain > functional? > > The reason I ask is that because it violates beta-reduction, and also > referential transparency (I think). In haskell, we can transform: > > g x + f x > > into: > > f x + g x > > as both f and g do not change the parameter x. > > If g always evaluates to a normal form (in both a lazy and a strict > world) > > g x = x > > but f is defined thus: > > f x = (\y -> if x /= 0 then x else y/x) > > And we apply f to 0 (1/0) then f becomes _|_ > > therefore: > > 0 + _|_ /= _|_ + 0 > > Or, does this just become: > > _|_ = _|_ ? > > Or, am I missing something totally obvious? > > Regards, > Chris. > > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell Jeremy.Gibbons@comlab.ox.ac.uk Oxford University Computing Laboratory, TEL: +44 1865 283508 Wolfson Building, Parks Road, FAX: +44 1865 283531 Oxford OX1 3QD, UK. URL: http://www.comlab.ox.ac.uk/oucl/people/jeremy.gibbons.html From cmb21 at kent.ac.uk Thu Aug 9 07:06:41 2007 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Thu Aug 9 06:58:54 2007 Subject: [Haskell] What makes a functional language functional? In-Reply-To: References: Message-ID: Hi Jeremy, Thanks for this very informative answer! This has certainly helped to clear up a number of points. Thanks, Chris. > Many arguments have been had about what it means for a language to be > "functional", so that's probably not a productive line of discussion. > (ICFP carefully doesn't stipulate language choice for the programming > contest, for example.) > > Both eager and lazy evaluation can be "pure", providing referential > transparency: all that matters of an expression is its value, and a > subexpression may be substituted with a different one having the same > value without changing the meaning of the surrounding context. This > fails on languages supporting side effects. > > Lazy evaluation is necessary, however, in order to treat a function > definition as a (universally applicable) equation. In Haskell, I can > define > > > three x = 3 > > and then infer, for any expression x, that the equation > > three x = 3 > > holds. With eager evaluation, that's no longer the case: if x denotes > a non-terminating or error-raising computation, then > > three x /= 3 > > The equation then requires a side condition: > > three x = 3, for well-defined x > > which complicates equational reasoning, but it doesn't break > referential transparency. > > Jeremy > > > On 9 Aug 2007, at 10:30, C.M.Brown wrote: > > > Hi, > > > > Is lazy evaluation necessary for a functional language to remain > > functional? > > > > The reason I ask is that because it violates beta-reduction, and also > > referential transparency (I think). In haskell, we can transform: > > > > g x + f x > > > > into: > > > > f x + g x > > > > as both f and g do not change the parameter x. > > > > If g always evaluates to a normal form (in both a lazy and a strict > > world) > > > > g x = x > > > > but f is defined thus: > > > > f x = (\y -> if x /= 0 then x else y/x) > > > > And we apply f to 0 (1/0) then f becomes _|_ > > > > therefore: > > > > 0 + _|_ /= _|_ + 0 > > > > Or, does this just become: > > > > _|_ = _|_ ? > > > > Or, am I missing something totally obvious? > > > > Regards, > > Chris. > > > > > > _______________________________________________ > > Haskell mailing list > > Haskell@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell > > > > Jeremy.Gibbons@comlab.ox.ac.uk > Oxford University Computing Laboratory, TEL: +44 1865 283508 > Wolfson Building, Parks Road, FAX: +44 1865 283531 > Oxford OX1 3QD, UK. > URL: http://www.comlab.ox.ac.uk/oucl/people/jeremy.gibbons.html > > > From conal at conal.net Fri Aug 10 00:03:53 2007 From: conal at conal.net (Conal Elliott) Date: Thu Aug 9 23:55:47 2007 Subject: [Haskell] ghc.haddock? In-Reply-To: <46BAD675.3040609@gmail.com> References: <46BAD675.3040609@gmail.com> Message-ID: I'd like to give it a try. I guess the repo is http://darcs.haskell.org/SoC/ghc.haddock/. Glancing around, see a version of ghc, and I don't know how to build haddock. Is ghc.haddock a new flag to a forked version of ghc? Other questions: is ghc.haddock known to build & run on Windows? Is the plan to merge it into the main ghc sources, and if so, when? I'd love to hear from others using ghc.haddock. Thanks, - Conal On 8/9/07, Simon Marlow wrote: > > Conal Elliott wrote: > > I've heard of a version Haddock that understands all of GHC's syntax > > extensions. Does anyone the current status? - Conal > > That would be the next version of Haddock, courtesy of David Waern's > Summer > of Code project last year. It is dependent on an unreleased version of > GHC, which is why it has not been more widely announced yet. > > The source is here; > > http://darcs.haskell.org/haddock.ghc > > but you'll need a very recent GHC 6.7 snapshot in order to build it. > > Cheers, > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20070809/167f27cf/attachment-0001.htm From p.k.f.holzenspies at utwente.nl Fri Aug 10 03:47:52 2007 From: p.k.f.holzenspies at utwente.nl (Philip =?utf-8?B?Sy5GLiBIw7ZsemVuc3BpZXM=?=) Date: Fri Aug 10 03:39:57 2007 Subject: [Haskell] What makes a functional language functional? Message-ID: <20070810074752.GB8487@ewi1043.ewi.utwente.nl> Dear Chris, Aside from the points raised by others already, I wanted to add a small point. Aside from +'s commutativity. The + you use here can not be transformed the way you point out. Looking at the types: f :: Fractional a => a -> a -> a g :: t -> t In the expression g x + f x the type of + is: (+) :: Fractional a => t1 -> (a -> a) -> t2 The example as you give it would actually not pass through the type checker. If we simply define f as f x | x /= 0 = undefined | x == 0 = 0 the behaviour would be the one you describe. I'm not too sure about the actual formalisms, but I seem to recall that, since _|_ is not a value, non-termination does not violate referential transparency. Basically, it is undecidable for any x whether _|_ == x The undecidability even holds for x = _|_ Also, I can implement any program from a lazy functional programming language in, for example, C. If I program the test whether or not to evaluate the next element "now", I can even make my program behave in the exact same "lazy way" - but let's not discuss how large and ugly that code would be. This can be done with pure functions only, i.e. referentially transparent. I vaguely recall a formal semantics presentation about whether or not termination is part of the formal semantics at all. Since it has been so long ago since I scratched the surface of formal semantics, I'll refrain from making an idiot out of myself and committing to strong statements in that direction ;) Regards, Philip From davve at dtek.chalmers.se Fri Aug 10 04:50:21 2007 From: davve at dtek.chalmers.se (David Waern) Date: Fri Aug 10 04:42:13 2007 Subject: [Haskell] ghc.haddock? Message-ID: <52586.212.209.37.162.1186735821.squirrel@webmail.chalmers.se> > I'd like to give it a try. I guess the repo is > http://darcs.haskell.org/SoC/ghc.haddock/. Glancing around, see a version > of ghc, and I don't know how to build haddock. Is ghc.haddock a new flag > to > a forked version of ghc? > > Other questions: is ghc.haddock known to build & run on Windows? Is the > plan to merge it into the main ghc sources, and if so, when? > > I'd love to hear from others using ghc.haddock. > > Thanks, - Conal Hi Conal, The changes in ghc.haddock was merged to GHC last year after my SoC project was finished. This repository should not be used anymore. What you need is a quite recent GHC 6.7, probably from July or later. Then you should get Haddock 2.0 aka haddock.ghc from this darcs repository: http://darcs.haskell.org/SoC/haddock.ghc/. The package can be built using Cabal and GHC 6.7. I haven't tested it with Windows - please let me know if you have any problems. Thanks for taking interest! /David From conal at conal.net Tue Aug 14 17:02:22 2007 From: conal at conal.net (Conal Elliott) Date: Tue Aug 14 16:54:00 2007 Subject: [Haskell] ghc.haddock? In-Reply-To: <52586.212.209.37.162.1186735821.squirrel@webmail.chalmers.se> References: <52586.212.209.37.162.1186735821.squirrel@webmail.chalmers.se> Message-ID: Hi David. Thanks for the reply. I'm pretty confused. I understand your first paragraph as saying *not* to use that repo, and the second as saying to use it. Is the new haddock included in GHC 6.7 or is it still an app that works separately from GHC? If the latter, where is the app's repo? Thanks, - Conal On 8/10/07, David Waern wrote: > > > I'd like to give it a try. I guess the repo is > > http://darcs.haskell.org/SoC/ghc.haddock/. Glancing around, see a > version > > of ghc, and I don't know how to build haddock. Is ghc.haddock a new > flag > > to > > a forked version of ghc? > > > > Other questions: is ghc.haddock known to build & run on Windows? Is the > > plan to merge it into the main ghc sources, and if so, when? > > > > I'd love to hear from others using ghc.haddock. > > > > Thanks, - Conal > > Hi Conal, > > The changes in ghc.haddock was merged to GHC last year after my SoC > project was finished. This repository should not be used anymore. What you > need is a quite recent GHC 6.7, probably from July or later. > > Then you should get Haddock 2.0 aka haddock.ghc from this darcs > repository: > http://darcs.haskell.org/SoC/haddock.ghc/. The package can be built using > Cabal and GHC 6.7. I haven't tested it with Windows - please let me know > if you have any problems. > > Thanks for taking interest! > > /David > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20070814/ecbb92aa/attachment.htm From isaacdupree at charter.net Tue Aug 14 17:20:34 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue Aug 14 17:12:21 2007 Subject: [Haskell] ghc.haddock? In-Reply-To: References: <52586.212.209.37.162.1186735821.squirrel@webmail.chalmers.se> Message-ID: <46C21CA2.9000805@charter.net> Conal Elliott wrote: > Hi David. Thanks for the reply. > > I'm pretty confused. I understand your first paragraph as saying *not* to > use that repo, and the second as saying to use it. Is the new haddock > included in GHC 6.7 or is it still an app that works separately from GHC? > If the latter, where is the app's repo? haddock.ghc and ghc.haddock are different. Haddock.ghc needs a GHC with the patches from ghc.haddock. The latest GHC 6.7 has ghc.haddock patches. Haddock.ghc is the new haddock, which requires those GHC capabilities. So you need GHC 6.7 *and* haddock.ghc. Does that clear up the rather confusing naming scheme? Isaac From conal at conal.net Tue Aug 14 18:24:47 2007 From: conal at conal.net (Conal Elliott) Date: Tue Aug 14 18:16:25 2007 Subject: [Haskell] ghc.haddock? In-Reply-To: <46C21CA2.9000805@charter.net> References: <52586.212.209.37.162.1186735821.squirrel@webmail.chalmers.se> <46C21CA2.9000805@charter.net> Message-ID: All clear now. :) Much appreciated, Isaac! - Conal On 8/14/07, Isaac Dupree wrote: > > Conal Elliott wrote: > > Hi David. Thanks for the reply. > > > > I'm pretty confused. I understand your first paragraph as saying *not* > to > > use that repo, and the second as saying to use it. Is the new haddock > > included in GHC 6.7 or is it still an app that works separately from > GHC? > > If the latter, where is the app's repo? > > haddock.ghc and ghc.haddock are different. Haddock.ghc needs a GHC with > the patches from ghc.haddock. The latest GHC 6.7 has ghc.haddock > patches. Haddock.ghc is the new haddock, which requires those GHC > capabilities. So you need GHC 6.7 *and* haddock.ghc. Does that clear > up the rather confusing naming scheme? > > Isaac > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20070814/bc2d9719/attachment.htm From asumu at cyberberry.com Wed Aug 15 00:58:22 2007 From: asumu at cyberberry.com (Asumu Takikawa) Date: Wed Aug 15 00:50:43 2007 Subject: [Haskell] ANNOUNCE: Guihaskell and PropLang 0.1 Message-ID: <20070815045822.GA5154@cyberberry.com> Hello Haskellers. I'm one of the Google Summer of Code students for '07 and I'd like to announce the project my mentor, Neil Mitchell, and I have been working on. == GuiHaskell Guihaskell is a graphical REPL using PropLang, a GUI combinator library built on top of Gtk2hs, which aims to be an IDE for Haskell written in Haskell. It's still rough around the edges, so think of this as an alpha release. As such, I'd appreciate any feedback very much! Here's a feature list for 0.1: * Support for GHCi (default) and Hugs * Quick switching between compilers * Simple one-click profiling * Command history This first release of Guihaskell is mostly infrastructure. For future releases I aim to integrate more tools like Cabal and make it easier to use with an editor. == PropLang PropLang is a GUI library built on Gtk2hs that allows for high level design. The GUI is expressed as a series of relationships between GUI elements and data sources. Here's a "Hello World" example: import PropLang.Gtk import PropLang.Event main = do initPropLang window <- getWindow "foobar.glade" "wndFoo" let tb = getCtrl window "button" :: ToolButton tb!onClicked += putStrLn "Hello World!" showWindowMain window This example prints "Hello World!" when the user presses a button defined in a Glade file. PropLang is used with glade to define the interface. You can define more complicated relationships using the combinators in PropLang.Variable. Here's a snippet from GuiHaskell: tie (txtSelect!text) filename (\t -> if null t then Nothing else Just t) (maybe "" id) "tie" takes two PropLang variables and relates them so that when one is updated, it will inject its value into another. It also takes two functions to run on the data before injection. This snippet is used to tie the representation of the currently selected file in GuiHaskell (a Maybe String) to Gtk's TextView buffer (a String). If you injected a new value into filename... filename -< Nothing then txtSelect's text buffer would be set to "". You can also build other behaviors into PropLang variables to do interesting things. GuiHaskell has a configuration API built around PropLang. Configuration items are defined as special PropLang variables: filename <- newVarWithName "selected_filename" (newConfValueWithDefault Nothing "selected_filename") "newVarWithName" in PropLang.Variable lets you make new variables with custom actions to retrieve and set values. "newConfValue" is defined in GuiHaskell to serialize configuration items to disk so they can be read back after closing the program. For more information you can generate the Proplang docs with haddock. == Install Get the packages here: http://hackage.haskell.org/packages/archive/GuiHaskell/0.1/GuiHaskell-0.1.tar.gz http://hackage.haskell.org/packages/archive/proplang/0.1/proplang-0.1.tar.gz Install with cabal: runhaskell Setup.lhs configure runhaskell Setup.lhs build runhaskell Setup.lhs install == You can send feedback to my e-mail, the list, or contact me on IRC (I'm Shimei on #haskell). Thanks. Cheers, Asumu Takikawa -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell/attachments/20070814/df99216a/attachment.bin From ashley at semantic.org Thu Aug 16 02:45:43 2007 From: ashley at semantic.org (Ashley Yakeley) Date: Thu Aug 16 02:37:17 2007 Subject: [Haskell] Re: ghc.haddock? In-Reply-To: <46C21CA2.9000805@charter.net> References: <52586.212.209.37.162.1186735821.squirrel@webmail.chalmers.se> <46C21CA2.9000805@charter.net> Message-ID: <46C3F297.7010402@semantic.org> Isaac Dupree wrote: > haddock.ghc and ghc.haddock are different. Haddock.ghc needs a GHC with > the patches from ghc.haddock. The latest GHC 6.7 has ghc.haddock > patches. Haddock.ghc is the new haddock, which requires those GHC > capabilities. So you need GHC 6.7 *and* haddock.ghc. Does that clear > up the rather confusing naming scheme? So presumably ghc.haddock provides some new API that haddock.ghc uses to get parse information? -- Ashley Yakeley From stefanor at cox.net Thu Aug 16 02:58:51 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Thu Aug 16 02:50:28 2007 Subject: [Haskell] Re: ghc.haddock? In-Reply-To: <46C3F297.7010402@semantic.org> References: <52586.212.209.37.162.1186735821.squirrel@webmail.chalmers.se> <46C21CA2.9000805@charter.net> <46C3F297.7010402@semantic.org> Message-ID: <20070816065851.GA6179@localhost.localdomain> On Wed, Aug 15, 2007 at 11:45:43PM -0700, Ashley Yakeley wrote: > Isaac Dupree wrote: > >> haddock.ghc and ghc.haddock are different. Haddock.ghc needs a GHC with >> the patches from ghc.haddock. The latest GHC 6.7 has ghc.haddock patches. >> Haddock.ghc is the new haddock, which requires those GHC capabilities. >> So you need GHC 6.7 *and* haddock.ghc. Does that clear up the rather >> confusing naming scheme? > > So presumably ghc.haddock provides some new API that haddock.ghc uses to > get parse information? Yup, modern GHC can parse Haddock comments and return them in the API. Disgustingly non-compositional, but it gets the job done, and is much better than just copying code... Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell/attachments/20070815/76e63cb2/attachment-0001.bin From conal at conal.net Thu Aug 16 03:54:22 2007 From: conal at conal.net (Conal Elliott) Date: Thu Aug 16 03:45:56 2007 Subject: [Haskell] Ref class? Message-ID: does anyone know where there's a class that abstracts over IORefs? it includes newRef, readRef, and writeRef. i've seen it but can't remember where. - conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20070816/d8f7f188/attachment.htm From rahn at ira.uka.de Thu Aug 16 04:02:41 2007 From: rahn at ira.uka.de (Mirko Rahn) Date: Thu Aug 16 03:54:23 2007 Subject: [Haskell] Ref class? In-Reply-To: References: Message-ID: <46C404A1.1030905@ira.uka.de> > does anyone know where there's a class that abstracts over IORefs? it > includes newRef, readRef, and writeRef. i've seen it but can't remember > where. - conal John Hughes, Functional Pearl: Global Variables in Haskell. /BR -- -- Mirko Rahn -- Tel +49-721 608 7504 -- --- http://liinwww.ira.uka.de/~rahn/ --- From bulat.ziganshin at gmail.com Thu Aug 16 06:54:11 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Aug 16 06:48:27 2007 Subject: [Haskell] Ref class? In-Reply-To: References: Message-ID: <549892940.20070816145411@gmail.com> Hello Conal, Thursday, August 16, 2007, 11:54:22 AM, you wrote: > does anyone know where there's a class that abstracts over IORefs? > it includes newRef, readRef, and writeRef.? i've seen it but can't remember where.? - conal http://haskell.org/haskellwiki/Library/ArrayRef -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From haskell at list.mightyreason.com Thu Aug 16 07:06:20 2007 From: haskell at list.mightyreason.com (haskell@list.mightyreason.com) Date: Thu Aug 16 06:57:53 2007 Subject: [Haskell] Ref class? In-Reply-To: References: Message-ID: <46C42FAC.8050608@list.mightyreason.com> Try http://haskell.org/haskellwiki/Library/ArrayRef#Monad-independent_references Conal Elliott wrote: > does anyone know where there's a class that abstracts over IORefs? it > includes newRef, readRef, and writeRef. i've seen it but can't remember > where. - conal > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From conal at conal.net Thu Aug 16 17:11:45 2007 From: conal at conal.net (Conal Elliott) Date: Thu Aug 16 17:03:17 2007 Subject: [Haskell] Re: Ref class? In-Reply-To: References: Message-ID: Thanks to all for the replies. I have it now. - Conal On 8/16/07, Conal Elliott wrote: > > does anyone know where there's a class that abstracts over IORefs? it > includes newRef, readRef, and writeRef. i've seen it but can't remember > where. - conal > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20070816/c596aac8/attachment.htm From shlomobauer at mac.com Sun Aug 19 10:52:59 2007 From: shlomobauer at mac.com (robert bauer) Date: Sun Aug 19 10:44:25 2007 Subject: [Haskell] help with IOArray Message-ID: I have an IOArray, but it doesn't work the way I expected it to. I defined newMem s = newIOArray (0, size-1) 0 and then x = newMem 30 then do { y <- x ; v <- readIOArray y 2 ; print v ; writeIOArray y 2 20 ; v <- readIOArray y 2 ; print v } this resulted in 0, 2 as expected. however, then do { y <- x ; v <- readIOArray y 20 ; print v } results in 0 I thought the IOArray was basically a static structure? Thanks From bertram.felgenhauer at googlemail.com Sun Aug 19 11:22:59 2007 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sun Aug 19 11:14:24 2007 Subject: [Haskell] help with IOArray In-Reply-To: References: Message-ID: <20070819152259.GB4587@zombie.inf.tu-dresden.de> robert bauer wrote: > I have an IOArray, but it doesn't work the way I expected it to. > > I defined > > newMem s = newIOArray (0, size-1) 0 > > and then > > x = newMem 30 > > then > > do { > y <- x > ; v <- readIOArray y 2 > ; print v > ; writeIOArray y 2 20 > ; v <- readIOArray y 2 > ; print v > } > > this resulted in 0, 2 as expected. > > however, then > > do { > y <- x > ; v <- readIOArray y 20 > ; print v > } > > results in 0 > > I thought the IOArray was basically a static structure? yes it is. However, 'x' is not an IOArray. Its type is (after defaulting) x :: IO (IOArray Int Int) It represents an IO action that constructs a *new* array.> do { so > do { > y <- x > ; v <- readIOArray y 20 > ; print v > } constrcts a new array and finds its 20th element, which was initialized to 0. The problem you have is dealing with global variables in Haskell. There are two major approaches. a) Construct the variable once and pass it explicitely as an argument to all functions. (In other words, don't use global variables at all.) > main = do { > mem <- newMem > func1 mem > func2 mem > } This is simple, easy to understand, but it doesn't scale well. To make it scale better you can define a data type for the global state. > data GlobalState = GS { mem :: IOArray Int Int } This record can then easily be extended with new fields as they come up. Finally you can get rid of the explicit 'mem' (or 'state') arguments by using a state monad transformer (StateT). b) Use actual global variables. See http://haskell.org/haskellwiki/Top_level_mutable_state for further information. http://haskell.org/haskellwiki/Global_variables is also interesting. HTH, Bertram From bulat.ziganshin at gmail.com Sun Aug 19 12:24:45 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Aug 19 12:29:12 2007 Subject: [Haskell] help with IOArray In-Reply-To: References: Message-ID: <7010399767.20070819202445@gmail.com> Hello robert, Sunday, August 19, 2007, 6:52:59 PM, you wrote: > I defined > newMem s = newIOArray (0, size-1) 0 > and then > x = newMem 30 i recommend you to read http://haskell.org/haskellwiki/IO_inside -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonpj at microsoft.com Tue Aug 21 03:41:46 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Aug 21 03:33:03 2007 Subject: [Haskell] Commercial users of functional programming 2007: programe is published, registration open Message-ID: Friends, The program for the 2007 Commercial Users of Functional Programming workshop is now published. http://cufp.galois.com/ The workshop is co-located with ICFP, and will be held in Freiburg, Germany, on 4 October 2007. We had a terrific response to our call for talks, and there are twelve (!) speakers describing commercial applications, variously written in Caml Erlang F# Haskell ML Scheme The talks are informal, and there are no proceedings. We'll just have fun learning about functional programming used to solve real problems. Do come! Kathleen Fisher Simon Peyton Jones From gmh at Cs.Nott.AC.UK Wed Aug 22 17:28:44 2007 From: gmh at Cs.Nott.AC.UK (Graham Hutton) Date: Wed Aug 22 17:26:42 2007 Subject: [Haskell] ANNOUNCE: Programming in Haskell - eBook version Message-ID: <1820.1187818124@cs.nott.ac.uk> Dear all, Readers of this list may be interested to know that "Programming in Haskell" is now also available as an eBook, in addition to the traditional paperback and hardback versions. For further details, just click the eBooks link on the book's home page: http://www.cs.nott.ac.uk/~gmh/book.html Best wishes, Graham +-----------------------------------------------------------------+ | Dr Graham Hutton Email : gmh@cs.nott.ac.uk | | School of Computer Science | | University of Nottingham Web : www.cs.nott.ac.uk/~gmh | | Jubilee Campus, Wollaton Road | | Nottingham NG8 1BB, UK Phone : +44 (0)115 951 4220 | +-----------------------------------------------------------------+ This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From rm606 at doc.ic.ac.uk Thu Aug 23 16:38:02 2007 From: rm606 at doc.ic.ac.uk (Rob Myers) Date: Thu Aug 23 16:29:10 2007 Subject: [Haskell] Generic combination of generic types Message-ID: <46CDF02A.1050004@doc.ic.ac.uk> Hi there, This is a question about combining data types in a generic way. I am using Haskell to write a first implementation of a new generic algorithm to decide a fairly large class of modal logics. Type classes provide an excellent way to generically define a modal language. In particular you only need to define the data type of the modal operator (e.g. it could be indexed by