Version française
Home     About     Download     Resources     Contact us    
Browse thread
moderation of caml-list
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Markus Mottl <mottl@m...>
Subject: Re: moderation of caml-list
On Wed, 19 Jul 2000, Julian Assange wrote:
> As a side note, I'd like to again express my desire for type-inferment
> of side-effects and exceptions in closures containing them or
> references to functions that do (and so on). Apart from making the
> code easier to read and debug this would also permit:

Although I would also like to see something like this, I fear that
implementing a "good-enough" solution would draw human resources that are
currently probably better invested elsewhere...

In any case: having information of this sort at compile time would allow
some really nice transformations/optimizations, much more powerful ones
than just factoring of common subexpressions or lifting of expressions.

E.g., one could safely apply transformations like partial evaluation,
deforestation/fusion or automatic introduction of accumulators for
tail-recursiveness, etc...

For people interested in program transformations, here is a nice overview:

  @Article{Pettorossi-Proietti96,
    key =          "Pettorossi \& Proietti",
    author =       "Alberto Pettorossi and Maurizio Proietti",
    title =        "Rules and Strategies for Transforming Functional and
                    Logic Programs",
    journal =      "ACMCS",
    volume =       "28",
    number =       "2",
    pages =        "360--414",
    month =        jun,
    year =         "1996",
    annote =       "Many references.",
  }

You can get it from here:  http://www.iasi.rm.cnr.it/~proietti/reports.html

I especially like the example where the straightforward (exponential)
fibonacci function is transformed by a series of automatable rule
applications to one which runs in logarithmic time (yes, I mean
*logarithmic*, not linear - I didn't know of this trick either...).
Such superexponential speedups are indeed very attractive! 8-)
Unfortunately, some transformations require purity...

Best regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl