- Haskell-Cafe - Haskell.org

Setting runtime memory limits on GHC programs to avoid thrashing
by John D. Ramsdell 10 Dec '10

10 Dec '10

Enclosed is a simple script that sets GHCRTS and provides a reasonable memory limit on systems that have /proc/meminfo. By default, the GHC runtime will grow to a size that can cause thrashing. John

1 0

Missing Functor instances in GHC 7?
by Sebastian Fischer 10 Dec '10

10 Dec '10

Hello, according to http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.ht… Control.Monad exports 20 Functor instance declarations in base-4.3.0.0. However: bash# ghc-pkg list | grep base base-4.3.0.0 bash# ghci --version The Glorious Glasgow Haskell Compilation System, version 7.0.1 bash# ghci Prelude> import Control.Monad Prelude Control.Monad> :i Functor class Functor f where fmap :: (a -> b) -> f a -> f b (GHC.Base.<$) :: a -> f b -> f a -- Defined in GHC.Base instance Functor Maybe -- Defined in Data.Maybe instance Functor [] -- Defined in GHC.Base instance Functor IO -- Defined in GHC.Base There are only 3 instances instead of 20. Importing Control.Applicative gives 3 more instances but for example the instance for ((->) r) is still missing. Is my installation broken? Or has anybody similar problems finding Functor instances in GHC 7? Sebastian

4 6

ANNOUNCE: mime-mail 0.1.0
by Michael Snoyman 09 Dec '10

09 Dec '10

Hi all (again), I'm happy to announce the second major release of the mime-mail[1] package. mime-mail is a package providing support for rendering multipart emails. This new release introduces: * A partHeaders record, allowing you to place arbitrary headers on individual parts of a message. This is especially useful for ContentID * Support for quoted-printable. There are two new Encoding constructors added: QuotedPrintableText and QuotedPrintableBinary. They differ in how they treat newline characters: the latter outputs CRs and LFs in an escaped form, while the former strips all CRs and outputs LFs as the ASCII codes for "\r\n". * Support for encoded-word for header values. This is a completely transparent change: now if you use non-ASCII characters in your header values, mime-mail will automatically encode appropriately. Enjoy! Michael [1] http://hackage.haskell.org/package/mime-mail

5 6

Re: [Haskell-cafe] [Haskell] ANNOUNCE: genprog-0.1
by Alberto G. Corona 09 Dec '10

09 Dec '10

Hi ;) 2010/12/8 Mitar <mmitar(a)gmail.com> > Hi! > > On Wed, Dec 8, 2010 at 3:39 PM, Alberto G. Corona <agocorona(a)gmail.com> > wrote: > > DNK? I think you mean DNA. > > Sorry. In my native language it is DNK. ;-) > > > the genotype program that develips the fenotype is much more smooth and > > granular than a computer program. A chante un a gen does not make you to > > have a extra bone. It can make you to have your hand slighltly longer. or > > shorter. > > Because we are using very small programs. A change of one constant in > a Linux kernel would also be a very small change in general. Maybe > some esoteric device would not function anymore, but this is it. Of > course there would be also changes which would make whole kernel > dysfunctional. > > Of course there are smooth zones in the fitness landscape of any code. what is necessary is to direct the process by avoiding absurd replacements (mutations that goes straight to dead zones) and rules for changing from a smooth to another smooth area once the local maximum is not satisfactory. Or to detect them as early as possible (that is, rules again). That is what I mentioned before. > > In fact there are metalevels of selection that discard abrupt changes. > For > > example, when females ovulate there are a strong selection where > thounsands > > of candidate cell ovules are tested and discarded. This is one of the > > reasons why anomalous mutations are scarce. > > I doubt that. Aren't female eggs made while she is still a fetus? And > they do not divide anymore later on? > This selection of candidate eggs happens each month within each ovulation period. It is mentioned in this superb conference series by Yale university. It is a very good introduction. I don´t remember the exact chapter. sorry: http://www.youtube.com/watch?v=VjgHd6HKtvE Moreover, the genetic code has evolved to evolve. For many reasons. Neither Haskell nor any conventional language has. One of the safety measures of the genetic code is protectin itself against undesired mutations. This is something vital for life. Cancer is one consequence. but another consequences are more deadly: If a mother spend nine months to produce an unfit child this is a dead end for the mother´s genome line. For this reason, undesired mutations, specially in reproductive cells are either repaired or discarded. This selection is more strong in females than in males (for investment reasons) . The rate of mutations in living beings is equal to the theorical optimum for procariots and eucariouts. This is another examople of how finely tuned the DNA has evolved for evolution. The molecular bonds are strong enough just to permit the right rate of mutation . But the DNA i´m sure, has much more secrets to learn and discover. So in conclusion there are much details to learn and to implement to have sucessful general genetic algorithms for genetic programming. But the research promises a lot of fun.

5 10

Operator #
by c8h10n4o2 09 Dec '10

09 Dec '10

What does # mean in this code ? (from Data.List) findIndices p ls = loop 0# ls where loop _ [] = [] loop n (x:xs) | p x = I# n : loop (n +# 1#) xs | otherwise = loop (n +# 1#) xs -- View this message in context: http://haskell.1045720.n5.nabble.com/Operator-tp3299360p3299360.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

2 1

Re: [Haskell-cafe] A home-brew iteration-alike library: some extension quiestions
by Permjacov Evgeniy 09 Dec '10

09 Dec '10

-------- Original Message -------- Subject: Re: [Haskell-cafe] A home-brew iteration-alike library: some extension quiestions Date: Thu, 09 Dec 2010 23:07:49 +0300 From: Permjacov Evgeniy <permeakra(a)gmail.com> To: Antoine Latter <aslatter(a)gmail.com> On 12/09/2010 10:54 PM, Antoine Latter wrote: > I only have some surface level questions/comments - > > What existing packages is this similar to? How is it different from > any previous work in the area? > Main idea was taken from Iteratees invented by Oleg Kiselev (there are two packages on hackage implementing this ideas: data-iteraties and enumerator packages) The difference is, that I wished haskell-2010 compilant package for left-foldable streams, including support for easy builing, transcoding, merging and folding of streams relying on do-notation (see Data.Iteration.Unicode.* for examples of transcoding streams: it is quite clean and easily understandable) and ability to specify easily monadic actions in stream processors. > Also, likes looks like you don't need the 'Monad m' constraint on your > various Monad and Functor instances in Data.Iteration.Types, which I > think is one of the nicest properties of the continuation-based > approach to something like this. Errgh. That may be true, but I did not consider non-monadic context at all, so I enforced this constrain mindlessly > It's a mater of taste which way to go, but I prefer importing modules > qualified rather than have type-suffixes on functions - so I would > rather use 'I.next' and 'A.next' instead of 'nextI' and 'nextA'. But > reasonable people can disagree on this. > > Take care, > Antoine Thanks! > On Thu, Dec 9, 2010 at 1:42 PM, Permjacov Evgeniy <permeakra(a)gmail.com> wrote: >> Hi. I Wrote a simple iteration library. It was not intensively tested, >> so it MAY contatin bugs, but it is very unlikely. The library is >> currently on github: https://github.com/permeakra/iteration >> >> I'm not ready to upload it to hackage, as some testing and extension is >> really needed. However, I'd like to know about possible flaws. >> >> Current goal is addition of byte-stream (de)compression and IO functions >> extenstion. After this package will be cabalized and uploaded to >> hackage. So, while design is not frozen yet, I'm interested in criticism -)/ >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >>

1 0

Re: [Haskell-cafe] ANN: hledger 0.13
by Simon Michael 09 Dec '10

09 Dec '10

On Dec 9, 2010, at 7:34 AM, Peter Simons wrote: > I can tell it's doing more harm than good. The situation right now is > that it's impossible to install hledger on ArchLinux -- not because Why ? I haven't yet heard why depending on the higher process version is a problem.

2 2

Re: [Haskell-cafe] [Haskell] ANNOUNCE: genprog-0.1
by Alberto G. Corona 09 Dec '10

09 Dec '10

> > Hi! >> >> On Thu, Dec 9, 2010 at 1:48 PM, Alberto G. Corona <agocorona(a)gmail.com> >> wrote: >> > assign rates of mutation for each statement, >> >> This could be assigned by evolution itself. If "if" will have high >> probability of mutation then resulting programs will not survive. So >> those probabilities can be assigned by evolution itself and be also >> something which is passed on with generations (with again possibility >> of mutations of those probabilities itself). >> > > As any part in a genetic algoritm, it is a trading of flexibility for huge > gains of speed. take into accout that some of these tricks neded a > subtantial fraction of the age of the universe to evolve using massively > paralell hardware (ecosystems). > > > >> What would be interesting is to have an evolution algorithm which >> would allow such protections to evolve during its run. So some kind of >> protection which would lower the rate of mutation for some code part. >> >> > Species of programs means that the seed of the genetic algoritm must not >> be >> > turing comoplete I guess. It must be specific for each problem. >> >> I do not see this as necessity. Just that those specimens which would >> use this power too much would probably not survive. (If they would >> remove protection for some sentences they have build before.) >> > > The mutation weigths are something conventional for coventional languages. Another option is to design an automodifying evolving language from scratch. That "software DNA" I guess, should follow closely the techniques of the real DNA. Your idea fits more here In the conventional approach, the turing incomplete templates can have pre-assigned mutation weights for each statement. These mutation rates can evolve too. However, nothing prevents from having an additional level for selecting the appropriate template for each problem. > >> >> Mitar >> > > Alberto

1 0

Re: [Haskell-cafe] ANN: hledger 0.13
by Simon Michael 09 Dec '10

09 Dec '10

On Dec 9, 2010, at 3:35 AM, Peter Simons wrote: > you said that a dependency of one of those packages would require > process >= 1.0.1.4. Now, what I don't understand is why you added > that restriction to hledger then? Picture this common scenario, which I saw during installability testing - you install hledger to try it out. Cabal builds it with process 1.0.1.3. You get enthusiastic and later try to cabal install hledger-X, but this fails ("can not install hledger-X because hledger requires process-1.0.1.3"). (In other, similar-seeming cases I have seen cabal rebuild the installed depender; I don't understand all of cabal's behaviour.) I presume the user could work around this by - ghc-pkg unregister hledger; cabal install hledger-X - installing hledger the first time with --constraint process-1.0.1.4 but I figured a low-impact to make things "just work" was to bump hledger's process dependency. Is it making sense ? I welcome further insights or better solutions.

1 0

ICFP 2011: Call for papers
by Wouter Swierstra 09 Dec '10

09 Dec '10

===================================================================== Call for Papers ICFP 2011: International Conference on Functional Programming Tokyo, Japan, Monday 19 -- Wednesday 21 September 2011 http://www.icfpconference.org/icfp2011 ===================================================================== Important Dates ~~~~~~~~~~~~~~~ Titles, abstracts & keywords due: Thursday 17 March 2011 at 14:00 UTC Submissions due: Thursday 24 March 2011 at 14:00 UTC Author response: Tuesday & Wednesday 17-18 May Notification: Monday 30 May 2011 Final copy due: Friday 01 July 2011 Conference: Monday-Wednesday 19-21 September 2011 Scope ~~~~~ ICFP 2011 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects, concurrency, or parallelism. Particular topics of interest include * Language Design: type systems; concurrency and distribution; modules; components and composition; metaprogramming; relations to imperative, object-oriented, or logic programming; interoperability * Implementation: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; memory management; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components, or low-level machine resources * Software-Development Techniques: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling * Foundations: formal semantics; lambda calculus; rewriting; type theory; mathematical logic; monads; continuations; delimited continuations; global, delimited, or local effects * Transformation and Analysis: abstract interpretation; partial evaluation; program transformation; program calculation; program proofs; normalization by evaluation * Applications and Domain-Specific Languages: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed-systems and web programming; hardware design; databases; XML processing; scientific and numerical computing; graphical user interfaces; multimedia programming; scripting; system administration; security; education * Functional Pearls: elegant, instructive, and fun essays on functional programming * Experience Reports: short papers that provide evidence that functional programming really works or describe obstacles that have kept it from working in a particular application Abbreviated instructions for authors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * By 17 March 2011, 14:00 UTC, submit a title, an abstract of at most 300 words, and keywords. * By 24 March 2011, 14:00 UTC, submit a full paper of at most 12 pages (6 pages for a Functional Pearl and for an Experience Report), including bibliography and figures. The deadlines will be strictly enforced and papers exceeding the page limits will be summarily rejected. * Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. * Each submission must adhere to SIGPLAN's republication policy, as explained on the web at http://www.acm.org/sigplan/republicationpolicy.htm In addition, authors of resubmitted (but previously rejected) papers have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the program chair will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no rewiewer will read the annotated copies of the previous reviews. Overall, a submission will be evaluated according to its relevance, correctness, significance, originality, and clarity. It should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. Functional Pearls and Experience Reports are separate categories of papers that need not report original research results and must be marked as such at the time of submission. Detailed guidelines on both categories are on the conference web site. Proceedings will be published by ACM Press. Authors of accepted submissions are expected to transfer the copyright to the ACM. Presentations will be videotaped and released online if the presenter consents by signing an additional permission form at the time of the presentation. Formatting: Submissions must be in PDF format printable in black and white on US Letter sized paper and interpretable by Ghostscript. If this requirement is a hardship, make contact with the program chair at least one week before the deadline. Papers must adhere to the standard ACM conference format: two columns, nine-point font on a ten-point baseline, with columns 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter of 2pc (0.33in). A suitable document template for LaTeX is available from SIGPLAN at http://www.acm.org/sigs/sigplan/authorInformation.htm Submission: Submissions will be accepted electronically at a URL to be named later. Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Author response: Authors will have a 48-hour period, starting at 14:00 UTC on Tuesday 17 May 2010, to read reviews and respond to them. Special Journal Issue: There will be a special issue of the Journal of Functional Programming with papers from ICFP 2011. The program committee will invite the authors of select accepted papers to submit a journal version to this issue. Conference Chairs: Manuel M T Chakravarty, University of New South Wales, Australia Zhenjiang Hu, National Institute of Informatics (NII), Japan Program Chair: Olivier Danvy, Aarhus University, Denmark Program Committee: Kenichi Asai, Ochanomizu University, Japan Josh Berdine, Microsoft Research, UK Adam Chlipala, Harvard University, USA William Cook, University of Texas at Austin, USA Maribel Fernandez, King's College London, UK Ronald Garcia, Carnegie Mellon University, USA Neal Glew, Intel Labs, USA Jacques Garrigue, Nagoya University, Japan Suresh Jagannathan, Purdue University, USA Sam Lindley, University of Edinburgh, UK Frank Pfenning, Carnegie Mellon University, USA Paola Quaglia, University of Trento, Italy Alexis Saurin, University of Paris VII, France Mike Spivey, Oxford University, UK Kristian Stoevring, University of Copenhagen, Denmark Doaitse Swierstra, Utrecht University, The Netherlands David Van Horn, Northeastern University, USA Rene Vestergaard, JAIST, Japan Edwin Westbrook, Rice University, USA

1 0