- Haskell-Cafe - Haskell.org

derive Pretty?
by Greg Fitzgerald 01 Feb '08

01 Feb '08

Is it possible to automatically derive instances of Pretty<http://haskell.org/ghc/docs/latest/html/libraries/haskell-src/Language-Hask…>? If no, what do most do when it comes to pretty-printing large data types? Thanks, Greg

3 2

Fwd: Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
by Wolfgang Jeltsch 01 Feb '08

01 Feb '08

Hello Ryan, I hope, it’s okay to forward your message to the list: > Date: Freitag, 1. Februar 2008 01:41 > From: "Ryan Ingram" <ryani.spam(a)gmail.com> > To: "Wolfgang Jeltsch" <g9ks157k(a)acme.softbase.org> This representation is not exactly the same when you include _|_. For example: > data None -- only _|_ / undefined are members of this type. > data Pair a b = Pair a b > > -- There are three distinct inhabitants of the type Pair None (Pair None > None): v1, v2, v3 :: Pair None (Pair None None) > v1 = undefined > v2 = Pair undefined undefined > v3 = Pair undefined (Pair undefined undefined) > > -- whereas there are only two inhabitants of (None, None, None): > p1, p2 :: (None, None, None) > p1 = undefined > p2 = (undefined, undefined, undefined) You could solve it this way: > data PairL a b = PairL a !b where (a,b,c) is syntactic sugar for PairL a (PairL b (PairL c ())) Now we are back to only having two inhabitants of the type: > x1, x2 :: PairL None (PairL None (PairL None ())) > x1 = undefined > x2 = PairL undefined (PairL undefined (PairL undefined ())) There are still potential efficiency issues, although this could be worked out in the compiler; right now it's a single operation to get from a tuple to any member, but in PairL it takes n operations to get from the root to the nth elment of the tuple. The "unbox-strict-fields" optimization can fix this. On 1/31/08, Wolfgang Jeltsch <g9ks157k(a)acme.softbase.org> wrote: > Well, the representation (D1,D2,D9) might be considered more readable. It > has the disadvantage of a fixed maximum size for the numbers. Which takes > me to a point I had already considered some time ago: Wouldn't it be good > if we had just a type > > data Pair val1 val2 = Pair val1 val2 > > and if then (val1,val2,…,valn) would just be syntactic sugar for this: > > val1 `Pair` (val2 `Pair` (…(valn `Pair` ())…))

2 1

Relevance and applicability of category theory
by aaltman＠pdx.edu 31 Jan '08

31 Jan '08

Category theory seems to have an inconsistent relationship to Haskell - both documentation and the language's implementations of categorical concepts. I come from a math background that makes the Haskell's tight coupling to its mathematical foundation very appealing. But, I may have found some inconsistencies. Whether you agree or not I hope we can get some discussion going that will clarify the wikibooks, etc. My issues: 1. Are Haskell monads useful in a truly categorical sense? 2. Is Haskell's functor class misnamed? 3. Haskell arrows and Haskell monads have a misleading relationship 1. Categorical monads are a class of functors, that is, morphisms on Cat. Haskell's monads are at least a bit closer to the categorical idea than Haskell's functors by virtue of having the same domain and codomain: Hask -> Hask. I think applicability of Haskell monads beyond sequencing computation, and the validity of their definition, would be much more clear if someone explained the meaning of adjoint functors to and from Hask. In other words, provide the mathematical characterization to make Haskell monads a precise representation of categorical monads on Hask. 2. Functors are structure preserving maps in the category Cat. The Haskell Functor class represents structure preserving maps in the category Hask, which seem to me more like the categorical notion of arrows or the algebraic notion of homomorphisms. If we talk about functors relating to Haskell, it seems more likely we'd be referring to functors to or from the category Hask than functions (or arrows or whatever) between elements of Hask. Maybe categorical functors are useful as an abstract characterization of programs themselves: a program defines a functor from the problem domain into Hask, or from Hask into output in a problem domain. The name "Arrow" is already taken; what about renaming Functor to Automorphism? 3. I believe the documentation stating that Haskell arrows are a generalization of Haskell monads, but arrows are a categorical thing too and in that context bear a much more distant relationship to monads. Does a Haskell arrow have Hask as domain and codomain? Or is one particular element in Hask its domain and possibly another its codomain? Those are not at all the same thing. My guess is that the concept of Hask is too murky to be any use right now. The documentation may be more clear by avoiding it until we work out a formal definition... or is there one already? - Aaron Altman

7 9

announcing darcs 2.0.0pre3
by David Roundy 31 Jan '08

31 Jan '08

We are happy to announce the third prerelease version of darcs 2! Darcs 2 features numerous improvements, and it seems that we have fixed most of the regressions, so we're looking for help, from users willing to try this release out. Read below, to see how you can benefit from this new release, and how you can help us to make the final darcs 2 release the best ever! The third prerelease features (apart from numerous bug and performance regression fixes) a completely rewritten rollback command and new progress-reporting functionality. If darcs takes more than a couple of seconds for a given operation and provides you with no feedback as to what it's up to, let us know, so we can fine-tune the progress-reporting output! I would especially like to thank Mark Stosberg for his tireless work triaging old bugs in our bug tracker and writing tests to be added to our test suite for those still present! For more details, and instructions on obtaining darcs 2.0.0pre3, see: http://wiki.darcs.net/index.html/DarcsTwo David

11 27

RE: [Haskell] Announce: Yi 0.3
by Bayley, Alistair 31 Jan '08

31 Jan '08

> From: haskell-bounces(a)haskell.org > [mailto:haskell-bounces@haskell.org] On Behalf Of > Jean-Philippe Bernardy > > * homepage: http://haskell.org/haskellwiki/Yi Took a quick look around and saw this: * GTK frontend works in Win32 So Yi works on Windows? hs-plugins was broken for Windows for a while, so I'm wondering if this has been fixed too. Does Yi use hs-plugins, or does it go straight down to ghc? (looking at the yi.cabal file seems to indicate no dependency on hs-plugins) Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

3 3

Re: [Haskell-cafe] RE: [Haskell] Announce: Yi 0.3
by Peter Verswyvelen 31 Jan '08

31 Jan '08

Is YI also an IDE for creating Haskell code? I guess it's not, it's "just" a text editor right? I mean, if it talks to GHC directly, it could neatly take over some tricks used in Visual Haskell (on the fly type inference, good completion, etc), only much much easier (without the COM layer, directly in Haskell).

1 0

Re: [Haskell-cafe] Simple network client
by Gary Bickford 31 Jan '08

31 Jan '08

Wasn't there a Linux file system (possibly a FUSE user-space one) that worked on writable CDs? IIRC it worked by marking the previous copy of the file as erased, and writing a new copy. On Wed, 2008-01-30 at 23:05 -0500, haskell-cafe-request(a)haskell.org wrote: > > PS: I would love to see an immutable filesystem that does not allow > writing to files, it only creates new files and garbage collects files > that have no incoming reference anymore... Just like a garbage > collected heap, and a bit like an OLAP databases (as far as I remember > my DB theory...) Besides the performance bottleneck, does something > like that exists? > > Plan 9's venti is somewhat similar to this. though it's really a > storage backend that you implement a filesystem on top of, and the fs > winds up having a write cache, which is mutable in practice. The > interesting thing is that the block's location is the cryptographic > hash of its contents, which leads to all sorts of neat properties (as > well as requiring immutability). > -- "Isn't it funny how the Global Village includes everybody but the villagers?" (http://wiki.laptop.org/go/OLPC_Publications)

3 2

Re: [Haskell-cafe] Mission: To take args from an n-tuple ... generally
by Martin Hofmann 31 Jan '08

31 Jan '08

> > I wondered, why not take an n-tuple of arguments s.t. > > > > multApply' :: (a1->a2->...->an->o) -> (a1,(a2,(...(an,o)...))) -> > o > > > I'm not sure what you're trying to do here. Why is there an o in the > argument? Also, do you really mean the number of arguments expected to > match the number of arguments given? > You are right. It should rather be multApply' :: (a1->a2->...->an->o) -> (a1,(a2,(...(an-1,an)...))) -> o as e.g. in: multApply' take (2,['a','b','c']) > Also you might want to check out Olegon polyvariadic functions: > http://okmij.org/ftp/Haskell/vararg-fn.lhs Thanks, I will have a look at this. Martin

1 0

CFP - PLMMS 2008
by Jacques Carette 31 Jan '08

31 Jan '08

FIRST CALL FOR PAPERS Second Workshop on Programming Languages for Mechanized Mathematics (PLMMS 2008) http://events.cs.bham.ac.uk/cicm08/workshops/plmms/ As part of CICM / Calculemus 2008 Birmingham, UK, 28-29 July 2008 This workshop is focused on the intersection of programming languages (PL) and mechanized mathematics systems (MMS). The latter category subsumes present-day computer algebra systems (CAS), interactive proof assistants (PA), and automated theorem provers (ATP), all heading towards fully integrated mechanized mathematical assistants that are expected to emerge eventually (cf. the objective of Calculemus). The two subjects of PL and MMS meet in the following topics, which are of particular interest to this workshop: * Dedicated input languages for MMS: covers all aspects of languages intended for the user to deploy or extend the system, both algorithmic and declarative ones. Typical examples are tactic definition languages such as Ltac in Coq, mathematical proof languages as in Mizar or Isar, or specialized programming languages built into CA systems. Of particular interest are the semantics of those languages, especially when current ones are untyped. * Mathematical modeling languages used for programming: covers the relation of logical descriptions vs. algorithmic content. For instance the logic of ACL2 extends a version of Lisp, that of Coq is close to Haskell, and some portions of HOL are similar to ML and Haskell, while Maple tries to do both simultaneously. Such mathematical languages offer rich specification capabilities, which are rarely available in regular programming languages. How can programming benefit from mathematical concepts, without limiting mathematics to the computational worldview? * Programming languages with mathematical specifications: covers advanced "mathematical" concepts in programming languages that improve the expressive power of functional specifications, type systems, module systems etc. Programming languages with dependent types are of particular interest here, as is intentionality vs extensionality. * Language elements for program verification: covers specific means built into a language to facilitate correctness proofs using MMS. For example, logical annotations within programs may be turned into verification conditions to be solved in a proof assistant eventually. How need MMS and PL to be improved to make this work conveniently and in a mathematically appealing way? These issues have a very colorful history. Many PL innovations first appeared in either CA or proof systems first, before migrating into more mainstream programming languages. Some examples include type inference, dependent types, generics, term-rewriting, first-class types, first-class expressions, first-class modules, code extraction etc. However, such innovations were never aggressively pursued by builders of MMS, but often reconstructed by programming language researchers. This workshop is an opportunity to present the latest innovations in MMS design that may be relevant to future programming languages, or conversely novel PL principles that improve upon implementation and deployment of MMS. We also want to critically examine what has worked, and what has not. Why are all the languages of mainstream CA systems untyped? Why are the (strongly typed) proof assistants so much harder to use than a typical CAS? What forms of polymorphism exist in mathematics? What forms of dependent types may be used in mathematical modeling? How can MMS regain the upper hand on issues of "genericity" and "modularity"? What are the biggest barriers to using a more mainstream language as a host language for a CAS or PA/ATP? Submission ---------- Submission works through EasyChair http://www.easychair.org/conferences/?conf=plmms2008 Two kinds of papers will be considered: * Full research papers may be up to 12 pages long. Authors of accepted papers are expected to present their work on the workshop in a regular talk. * Position papers may be up to 4 pages long. The workshop presentation of accepted position papers consists of two parts: a stimulating statement of certain issues or challenges by the author, followed by a discussion in the plenum. Papers should use the usual ENTCS style http://www.entcs.org/prelim.html (11 point version), and will be reviewed by the program committee. Informal workshop proceedings will be circulated as a technical report. We also plan post-workshop proceedings of improved research papers, or position papers that have been completed into full papers, as a special issue in a journal; papers from both PLMMS 2007 and 2008 will be considered here (details to follow). Programme Committee ------------------- Jacques Carette (Co-Chair) (McMaster University, Canada) John Harrison (Intel Corporation, USA) Hugo Herbelin (INRIA, Ecole polytechnique, France) James McKinna (Radboud University Nijmegen, Netherlands) Ulf Norell (Chalmers University, Sweden) Bill Page Christophe Raffalli (Universite de Savoie, France) Josef Urban (Charles University, Czech Republic) Stephen Watt (ORCCA, University of Western Ontario, Canada) Makarius Wenzel (Co-Chair) (Technische Universitaet Muenchen, Germany) Freek Wiedijk (Radboud University Nijmegen, Netherlands) Important Dates --------------- * Submission deadline - 5 May 2008 * Notification of acceptance - 6 June 2008 * Final version - 7 July 2008 (approximately) * Workshop - 28-29 July 2008

1 0

Mission: To take args from an n-tuple ... generally
by Martin Hofmann 31 Jan '08

31 Jan '08

Dear Community. I have recently read Joel Koerwer's posting how to evaluate a function of type (a->a->...->a->a), taking the arguments from a list (http://haskell.org/pipermail/haskell-cafe/2006-October/018658.html) Therefore, he introduced a function multApply: multApply :: (a->a->...->a->a) -> [a] -> a I wondered, why not take an n-tuple of arguments s.t. multApply' :: (a1->a2->...->an->o) -> (a1,(a2,(...(an,o)...))) -> o I naively tried to modify Joel's code, but in vain. As far as I can deduce from the error messages, GHC fails to fix the accordant types. However, in my understanding the type solely depends on the type of the passed function. Or am I wrong? Maybe there is a reason nobody has tried it this way? Following the code. First Joel's original multApply and then my attempt to define multApply'. ------------------------ MultApply.hs ------------------------------ {-# OPTIONS -fglasgow-exts -fallow-overlapping-instances #-} module MultApply where class MultApply func arg | func -> arg where multApply :: func -> [arg] -> arg instance MultApply (a->a) a where multApply f (x:xs) = f x multApply f _ = error "MultApply: one too few args" instance MultApply cascade a => MultApply (a -> cascade) a where multApply f (x:xs) = multApply (f x) xs multApply f _ = error "MultApply: n too few args" -- some random examples oneArg = multApply sqrt [25..] twoArg = multApply (+) [1..] fiveArg = multApply (\a b c d e -> sqrt ((a+b)^2+(d-e)^2)-5*c) [13..] class MultApply' f arg out | f -> arg out where multApply' :: f -> arg -> out instance MultApply' (a->b) a b where multApply' f x = f x multApply' f _ = error "MultApply: one too few args" instance MultApply' cascade a2 b => MultApply' (a1 -> cascade) (a1,a2) b where multApply' f (x,xs) = multApply' (f x) xs multApply' f _ = error "MultApply: n too few args" -------------------End File ------------------------ Hope I didn't stumble in a stupid newbie question. Thanks a lot to everybody who could give me some explanation and hints. Cheers, Martin

2 1