headers
Alain Cremieux | 3 Nov 2003 00:40
Picon
Favicon

REMINDER - Contributions to HC&A Report (November 2003 edition)

Category : Applications, Groups, and Individuals
Subcategory : Individual Haskellers and their projects

I work in a company making software for payrolling, which is a 
incredibly complex subject in France.
I'd like to use Haskell in my everyday's work, but up to now it's only 
been a personal hobby ("passion" woul be more accurate).
I am convinced that embedded languages ("DSEL") have strong applications 
in software-making companies. Of course Haskell is one of the best 
language for that; but if there are many fascinating papers (resulting 
from hard work & deep insights) on the subject, practical reusable code 
lacks. Most projects are unfinished, and when code exists it is in "as 
is" state, and never reusable without much work.
So as a start I am trying to implement How to write a financial contract 
<http://research.microsoft.com/Users/simonpj/Papers/financial-contracts/pj-eber.ps>, 
a chapter in "The Fun of Programming" by Simon Peyton Jones & Jean-Marc 
Eber. This article details the full analysis (the hard part) of an 
embedded language application. A deriving implementation should provide 
several solutions, depending on design decisions (for instance a 
"shallow" embedding and a "deep" embedding), simplifications rules 
leading to a (moderately) optimised interpreter and a code generator 
(C-- is my target language). And the code should work (calculate the 
value of several common financial options).
Two other key papers for this work are  Compiling Embedded Languages 
<http://www.conal.net/papers/jfp-saig/>, by Conal Elliott, Sigbjorn 
Finne and Oege de Moor, and Programming Graphics Processors Functionally 
<http://www.conal.net/papers/Vertigo/> (Vertigo) by Conal Elliott.
Any advice and/or discussion would be welcome.
Alain Crémieux
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Karrmann | 1 Nov 2003 17:36
Picon

Re: time since the epoch

Hi,

a while ago time calculation was subject on this list.
Now, I have a time library based on the TAI (international
atomic time) time scale.

>Peter Thiemann (Thu, Feb 06, 2003 at 12:40:14PM -0800):
>> John's code illustrates TimeDiff's deficiencies perfectly:
>> 
>> There is also a more fundamental problem with the TimeDiff data
>> type. While seconds, minutes, hours, and days are clearly specified
>> amounts of time, the duration of a month or a year may vary depending
>> on the reference point where the time difference is applied.

> newtype TimeDiff = TimeDiff Rational
>    deriving (Eq, Ord)
>> Hmm, this is underspecified!
>> As another poster said, (pointing out http://cr.yp.to/libtai, but it
>> is better to look at http://cr.yp.to/time.html, which has a discussion
>> on UTC vs TAI vs UNIX time) the official source of time is TAI, so it
>> is best to base a time library
>> *on the number of TAI seconds since a reference date*
>> (which is btw what the libtai is all about).
>> For compatibility with UNIX time, "Arthur David Olson's popular time
>> library uses an epoch of 1970-01-01 00:00:10 TAI"
>> [http://cr.yp.to/proto/utctai.html]. 
>> So this mostly means that you need to set your system clock correctly:-)

Sincerly,
--

--
(Continue reading)

Permalink | Reply | 575 comments |
headers
andrew cooke | 3 Nov 2003 02:58
Favicon
Gravatar

Expiring cached data?


I have a Haskell program that caches data in a tree.  Unfortunately, the
tree grows to exceed the available memory over time.  In a different
language, where I might be handling the caching myself, rather than
relying on laziness within the language, I might work round this by
keeping track of which leaves in the tree were more recently used, and,
when memory run slow, deleting those that have not been used for some time
(by the nature of the problem, access to particular caches tend to be
grouped, so a long-unused cache can be deleted without much performance
penalty).

What options do I have in Haskell?  I'm interested both in general
solutions (maybe some compilers do this anyway?) and in approaches to
structuring the program so that I can control caching in more detail.

Thanks,
Andrew

--

-- 
http://www.acooke.org/andrew
Permalink | Reply | 10 comments |
headers
Ben Escoto | 3 Nov 2003 08:34
Picon
Favicon

Re: Expiring cached data?

On Sun, 2 Nov 2003 22:58:41 -0300 (CLST)
"andrew cooke" <andrew <at> acooke.org> wrote:
> I have a Haskell program that caches data in a tree.  Unfortunately,
> the tree grows to exceed the available memory over time.  In a
> different language, where I might be handling the caching myself,
> rather than relying on laziness within the language, I might work
> round this by keeping track of which leaves in the tree were more
> recently used, and, when memory run slow, deleting those that have
> not been used for some time (by the nature of the problem, access to
> particular caches tend to be grouped, so a long-unused cache can be
> deleted without much performance penalty).
> 
> What options do I have in Haskell?  I'm interested both in general
> solutions (maybe some compilers do this anyway?) and in approaches
> to structuring the program so that I can control caching in more
> detail.

I'm new to Haskell, so take this with a grain of salt.  More
experienced coders will probably have better advice, but no one else
has responded yet.

Anyway, what you could do pair the tree with some data structure which
keeps track of what parts of the tree have been recently read.
Functions that read the tree could return a new pair (tree,
other_data_structure).  Usually read functions would just return the
tree as-is and just update that other data structure.

However, once in a while (every N reads?), the tree could be rebuilt
based on the data stored in the other data structure.  Leaves that you
want to expire could be recreated, and the leaves you want to save
(Continue reading)

Permalink | Reply | 2 comments |
headers
ketil+haskell | 3 Nov 2003 09:17
Picon
Picon

Re: time since the epoch

Stefan Karrmann <sk <at> mathematik.uni-ulm.de> writes:

> a while ago time calculation was subject on this list.
> Now, I have a time library based on the TAI (international
> atomic time) time scale.

This is cool!  But what actually happens when people post interesting
library code to the list?  Does somebody snarf it, and put it in a
more convenient place?

Why not upload it into the Haskell library site at Sourceforge, and
just post a description and a pointer?

        http://sourceforge.net/projects/haskell-libs/

-kzm
--

-- 
If I haven't seen further, it is by standing in the footprints of giants
Permalink | Reply | 0 comments |
headers
Conal Elliott | 3 Nov 2003 18:43
Gravatar

RE: Expiring cached data?

Hi Andrew.  This situation is what weak pointers [1] are for.  You keep
weak rather than regular pointers to your cache data.  The garbage
collector clears out the weak pointers and reclaims cache data when
necessary.  However, I don't think there is any policy to make
discriminating choices about *which* cache data gets discarded, for
instance least recently (or frequently) used.  Doing so would seem to be
an interesting and useful extension.  Regards,

     - Conal

[1] Stretching the storage manager: weak pointers and stable names in
Haskell, Simon Peyton Jones, Simon Marlow, and Conal Elliott. Proc
Workshop on Implementing Functional Languages, 1999.
http://research.microsoft.com/~simonpj/Papers/weak.htm 

-----Original Message-----
From: haskell-bounces <at> haskell.org [mailto:haskell-bounces <at> haskell.org]
On Behalf Of andrew cooke
Sent: Sunday, November 02, 2003 5:59 PM
To: haskell <at> haskell.org
Subject: Expiring cached data?

I have a Haskell program that caches data in a tree.  Unfortunately, the
tree grows to exceed the available memory over time.  In a different
language, where I might be handling the caching myself, rather than
relying on laziness within the language, I might work round this by
keeping track of which leaves in the tree were more recently used, and,
when memory run slow, deleting those that have not been used for some
time
(by the nature of the problem, access to particular caches tend to be
(Continue reading)

Permalink | Reply | 6 comments |
headers
Tom Pledger | 3 Nov 2003 21:18

RE: Expiring cached data?

Conal Elliott writes:
 | Hi Andrew.  This situation is what weak pointers [1] are for.  You keep
 | weak rather than regular pointers to your cache data.  The garbage
 | collector clears out the weak pointers and reclaims cache data when
 | necessary.  However, I don't think there is any policy to make
 | discriminating choices about *which* cache data gets discarded, for
 | instance least recently (or frequently) used.
 :

How about adapting splay trees so that their pointers become weak
after a certain depth?  The advantage for caching is that the more
frequently used elements move closer to the root, so you wouldn't have
to add much code for tracking recent use, just a depth threshold.

See the book Purely Functional Data Structures for more details on
implementing splay trees in a functional setting.

- Tom
Permalink | Reply | 5 comments |
headers
Conal Elliott | 3 Nov 2003 21:49
Gravatar

RE: Expiring cached data?

Cool idea!  Still, this discussion suggests to me the idea of
"relatively weak pointers".  Instead of a pointer being either strong or
weak, what if it could have a strength attribute (estimated value to the
app), e.g., in the real interval of zero to one?  The garbage collector
would prefer breaking weaker pointers over stronger ones.  The strength
required to survive a GC would depend on available memory and on the
distribution of existing pointer strengths and the reclamation benefits
of breaking weaker ones.

     - Conal

-----Original Message-----
From: haskell-bounces <at> haskell.org [mailto:haskell-bounces <at> haskell.org]
On Behalf Of Tom Pledger
Sent: Monday, November 03, 2003 12:18 PM
To: haskell <at> haskell.org
Subject: RE: Expiring cached data?

Conal Elliott writes:
 | Hi Andrew.  This situation is what weak pointers [1] are for.  You
keep
 | weak rather than regular pointers to your cache data.  The garbage
 | collector clears out the weak pointers and reclaims cache data when
 | necessary.  However, I don't think there is any policy to make
 | discriminating choices about *which* cache data gets discarded, for
 | instance least recently (or frequently) used.
 :

How about adapting splay trees so that their pointers become weak
after a certain depth?  The advantage for caching is that the more
(Continue reading)

Permalink | Reply | 4 comments |
headers
alberto | 3 Nov 2003 17:29
Picon

WRLA 2004 - Second call for papers

[[ -- Apologies for multiple copies of this message  -- ]]

+ + + + + WRLA'04 + + + + + SECOND CALL FOR PAPERS + + + + + WRLA'04 + + + + +

      +----------------------------------------------------------+
      |                                                          |
      |              5th International Workshop on               |
      |           Rewriting Logic and its Applications           |
      |                                                          |
      |                      W R L A  2004                       |
      |                                                          |
      |            Barcelona, Spain, March 27-28, 2004           |
      |                                                          |
      |              http://www.fdi.ucm.es/wrla2004              |                                                                    
      +----------------------------------------------------------+

The workshop will be held in conjunction with

         ETAPS 2004 
         7th European Joint Conferences on Theory and Practice of Software
         March 27 - April 4, 2004
         http://www.lsi.upc.es/etaps04

IMPORTANT DATES

November 24, 2003    Deadline for submission
January 15, 2004     Notification of acceptance
February 18, 2004    Final version in electronic form
March 27-28, 2004    Workshop in Barcelona
(Continue reading)

Permalink | Reply | 0 comments |
headers
S. Alexander Jacobson | 4 Nov 2003 00:26

haskell httpd

I've been working on a new project and evaluating
the Twisted python framework which relies on
asynchIO rather than threading to achieve speed.

The resulting idioms feel like they would be much
more elegant in Haskell.

So my question at this point is:

Is there a reasonably efficient Haskell httpd
implementation around that uses poll/select?

-Alex-


___________________________________________________________________
S. Alexander Jacobson                      Check out my new blog!!!
1-212-787-1914 voice                       http://alexjacobson.com
Permalink | Reply | 13 comments |

Gmane