ANNOUNCE: The Haskell Platform 2009.2.0.2

We're pleased to announce the third release of the Haskell Platform: a
single, standard Haskell distribution for everyone.

The specification, along with installers (including Windows and Unix
installers for a full Haskell environment) are available.

Download the Haskell Platform 2009.2.0.2:

    http://hackage.haskell.org/platform/

The Haskell Platform is a single, standard Haskell distribution for
every system, in the form of a blessed library and tool suite for
Haskell distilled from the thousands of libraries on Hackage, along with
installers for a wide variety of systems. It saves developers work
picking and choosing the best Haskell libraries and tools to use for a
task.

When you install the Haskell Platform, you get the latest stable
compiler, an expanded set of core libraries, additional development
tools, and cabal-install – so you can download anything else you need
from Hackage.

What you get:

    http://hackage.haskell.org/platform/contents.html

With regular time-based releases, we expect the platform will grow into
a rich, indispensable development environment for all Haskell projects.

ANNOUNCE: sendfile-0.5 with >2gb files and goood performance

IFL 2009: Call for Papers and Participation

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

memory management

Hello,

      I'm interested in research relating to memory management in 
Haskell. I'm at the point where I don't know enough to have very 
specific questions, but I'm especially interested in garbage collection 
in Haskell, and any available statistics (such as, how long does a thunk 
typically live before its evaluated, after its evaluated?), or tools 
that would let me get that sort of information more easily. If any one 
could be so kind as to point me to relevant research papers or other 
documentation, it would be very much appreciated.

           --Nathan Ricci

Re: memory management

nricci01:
> Hello,
>
>      I'm interested in research relating to memory management in  
> Haskell. I'm at the point where I don't know enough to have very  
> specific questions, but I'm especially interested in garbage collection  
> in Haskell, and any available statistics (such as, how long does a thunk  
> typically live before its evaluated, after its evaluated?), or tools  
> that would let me get that sort of information more easily. If any one  
> could be so kind as to point me to relevant research papers or other  
> documentation, it would be very much appreciated.

Some research papers on GC and Haskell:

    http://haskell.org/haskellwiki/Research_papers/Runtime_systems#Garbage_collection

Simon Marlow has some recent papers on benchmarking costs in the
runtime,

    http://www.haskell.org/~simonmar/bib/bib.html

Re: memory management

2009/8/3 Nathan Ricci <nricci01 <at> eecs.tufts.edu>:
> Hello,
>
>     I'm interested in research relating to memory management in Haskell. I'm
> at the point where I don't know enough to have very specific questions, but
> I'm especially interested in garbage collection in Haskell, and any
> available statistics (such as, how long does a thunk typically live before
> its evaluated, after its evaluated?), or tools that would let me get that
> sort of information more easily. If any one could be so kind as to point me
> to relevant research papers or other documentation, it would be very much
> appreciated.
>
>          --Nathan Ricci

Hi Nathan,

Whilst the work is not about memory management directly, you might
find this paper interesting:

   Feedback Directed Implicit Parallelism
   Tim Harris and Satnam Singh
   http://research.microsoft.com/en-us/um/people/tharris/papers/2007-fdip.pdf

And maybe have a look at the work on optimistic evaluation in Haskell:

   Adaptive Evaluation of Non-Strict Programs (PhD thesis)
   http://berkeley.intel-research.net/rennals/

(there might be some analysis about the life of thunks in those references).

Cheers,
Bernie.

PADL 2010: Second Call for Papers

                           CALL FOR PAPERS

		 Twelfth International Symposium on
	   Practical Aspects of Declarative Languages 2010
			      (PADL'10)

           http://clip.dia.fi.upm.es/Conferences/PADL-2010

                            Madrid, Spain
                         January 18-19, 2010

		     Co-located with ACM POPL'10

Declarative  languages build  on  sound theoretical  bases to  provide
attractive  frameworks for  application  development. These  languages
have   been  successfully   applied  to   many   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  raise  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, but are not limited to:

    * Innovative applications of declarative languages.
    * Declarative domain-specific languages and applications.
    * Practical applications of theoretical results.
    * New language developments and their impact on applications.
    * Declarative languages and Software Engineering.
    * Evaluation of implementation techniques on practical applications.
    * Practical experiences and industrial applications.
    * Novel uses of declarative languages in the classroom.

PADL'10 welcomes  new ideas and approaches  pertaining to applications
and  implementation   of  declarative  languages.    PADL'10  will  be
co-located with POPL 2010.

IMPORTANT DATES

      Abstract submission: August 31, 2009
      Paper Submission:	   September 4, 2009
      Notification:        October 5, 2009
      Camera-ready:	   October 26, 2009
      Symposium:	   January 18-19, 2010

SUBMISSION GUIDELINES

Authors should submit an electronic copy of the full paper (written in
English)    in   PDF,    in    the   Springer    LNCS   format    (see
http://www.springer.com/computer/lncs?SGWID=0-164-7-72376-0).       The
submission   will    be   done   through   EasyChair    at   the   URL
http://www.easychair.org/conferences/?conf=padl10 .

PADL'10 will accept both technical and application papers.

Technical Papers

Technical  papers  must   describe  original,  previously  unpublished
research  results,  and  must  not  be  simultaneously  submitted  for
publication elsewhere.   Each submission  must be written  in English,
and include three to four keywords, which will be used to assist us in
selecting appropriate  reviewers for the paper.   Submissions must not
exceed 15 pages in Springer LNCS format.

Application Papers

Application  papers are  a  mechanism to  present important  practical
applications  of declarative languages  that occur  in industry  or in
areas  of research  other than  computer science.   Application papers
will be  published in the Springer-Verlag  conference proceedings, and
will be presented in a separate session.

Application papers are expected  to describe complex and/or real-world
applications that rely on  an innovative use of declarative languages.
Application   descriptions,  engineering   solutions   and  real-world
experiences (both positive and negative) are solicited.

The limit for application papers is 3 pages in Springer LNCS format.

Most Practical Paper Award

The  Most  Practical  Paper  award  will be  given  to  the  technical
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.

PROGRAM COMMITTEE

Program Committee Chairs

   Manuel Carro (Universidad Politécnica de Madrid, Spain)
   Ricardo Peña (Universidad Complutense de Madrid, Spain)

Program Committee

   María Alpuente (Universidad Politécnica de Valencia, Spain)
   Lennart Augustson (Standard Chartered Bank and
                      Chalmers University of Technology, Sweden)
   Olaf Chitil (University of Kent, UK)
   María García de la Banda (Monash University, Australia)
   Andy Gill (The University of Kansas, USA)
   Haifeng Guo (University of Nebraska at Omaha, USA)
   Martin Hofmann (Ludwig-Maximilians Universität, Germany)
   Andy King (Portcullis Computer Security Limited, UK)
   John Launchbury (Galois, USA)
   Rita Loogen (Philipps-Universität Marburg, Germany)
   Erik Meijer (Microsoft Research, UK)
   Enrico Pontelli (New Mexico State University, USA)
   Vítor Santos Costa (Universidade do Porto, Portugal)
   Terrance Swift (CENTRIA, Portugal)
   Paolo Torroni (Università di Bologna, Italy)
   Roland Yap (National University of Singapore, Singapore)

CONTACTS:
     For information about papers and submissions, please contact a
     Program Chair:

          Manuel Carro
          PC co-Chair - PADL 2010
          School of Computer Science
          Universidad Politécnica de Madrid
          Campus de Montengancedo
          E-28660 Boadilla del Monte, Spain
          Email: mcarro <AT> fi<DOT>upm<DOT>es

          Ricardo Peña
          PC co-Chair - PADL 2010
          Facultad de Informática
          Universidad Complutense de Madrid
          c/ Profesor José García Santesmases s/n
          E-28040 Madrid, Spain
          Email:  ricardo <AT> sip<DOT>ucm<DOT>es

     For other information about the conference, please contact:
	
          Manuel Carro
          General Chair - PADL 2010
          School of Computer Science
          Universidad Politécnica de Madrid
          Campus de Montengancedo
          E-28660 Boadilla del Monte, Spain
          Email: mcarro <AT> fi<DOT>upm<DOT>.es

WITH THE COOPERATION OF:

    The University of Texas at Dallas
    ACM Sigplan

Re: memory management

Nathan,

>      I'm interested in research relating to memory management in 
> Haskell. I'm at the point where I don't know enough to have very 
> specific questions, but I'm especially interested in garbage collection 
> in Haskell, and any available statistics (such as, how long does a thunk 
> typically live before its evaluated, after its evaluated?), or tools 
> that would let me get that sort of information more easily. If any one 
> could be so kind as to point me to relevant research papers or other 
> documentation, it would be very much appreciated.

In the early to mid '90s we built various heap-profiling tools to 
examine the characteristics of heap data in lazy functional programs. 
You can find papers describing this work by Googling "heap profiling". 
You may be particularly interested in the investigation of "heap lag" 
and "heap drag" -- see for example the ICFP'96 paper.  Others have 
worked on similar tools since, but I'm not sure how extensive heap 
profiling facilities are in ghc, the most widely used implementation of 
Haskell.

Regards
Colin R

RE: memory management

I'm not quite sure how to describe this, but are you aware of any
research into converting heap allocations into frames on a stack?

For example, many C functions follow this kind of pattern:

void doSomeStuff(..)
{
	// allocate required resources
	int a,b,c;	// finite amount of temp allocations on stack
	int* buffer = malloc(..); // larger (finite) allocation on heap

	// free resources
	free(buffer); // free heap allocations
	// stack allocs popped by compiler.
}

They key aspect is the amount of memory required is calculatable in
advance and allocated/removed in a lump rather than a series of
requests. No pointer-tracking/garbage collection is required. 

I can picture similar situations arising in Haskell where for suitable
expressions the compiler could in theory determine that garbage
collection would be unnecessary for a lump of temporary data and simply
allocate/deallocate when starting/finishing evaluating the thunk. The
goal being to simplify garbage collection for this kind of temporary
allocation.

Any thoughts?

Ta,
Sam

-----Original Message-----
From: haskell-bounces <at> haskell.org [mailto:haskell-bounces <at> haskell.org]
On Behalf Of Colin Runciman
Sent: 04 August 2009 12:06
To: Nathan Ricci
Cc: Haskell <at> haskell.org
Subject: Re: [Haskell] memory management

Nathan,

>      I'm interested in research relating to memory management in 
> Haskell. I'm at the point where I don't know enough to have very 
> specific questions, but I'm especially interested in garbage
collection 
> in Haskell, and any available statistics (such as, how long does a
thunk 
> typically live before its evaluated, after its evaluated?), or tools 
> that would let me get that sort of information more easily. If any one

> could be so kind as to point me to relevant research papers or other 
> documentation, it would be very much appreciated.

In the early to mid '90s we built various heap-profiling tools to 
examine the characteristics of heap data in lazy functional programs. 
You can find papers describing this work by Googling "heap profiling". 
You may be particularly interested in the investigation of "heap lag" 
and "heap drag" -- see for example the ICFP'96 paper.  Others have 
worked on similar tools since, but I'm not sure how extensive heap 
profiling facilities are in ghc, the most widely used implementation of 
Haskell.

Regards
Colin R

_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: memory management

On Tue, Aug 4, 2009 at 7:30 AM, Sam Martin<sam.martin <at> geomerics.com> wrote:
> I can picture similar situations arising in Haskell where for suitable
> expressions the compiler could in theory determine that garbage
> collection would be unnecessary for a lump of temporary data and simply
> allocate/deallocate when starting/finishing evaluating the thunk. The
> goal being to simplify garbage collection for this kind of temporary
> allocation.
>
> Any thoughts?
>
> Ta,
> Sam

Sounds like region inference to me. (https://secure.wikimedia.org/wikipedia/en/wiki/Region_inference)


-- 
gwern

_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell