Monitoring (Lazy) Functional Languages 
Author Message
 Monitoring (Lazy) Functional Languages

Theo Norvell writes:
> What research has been done on analysing the time required for
> programs written in lazy languages to execute?  I'm interested
> in both exact counts (e.g. the number of application of primitives)
> or the big-oh (or big-theta) complexity.

> Any pointers or ideas will be greatfully received.
And Patrick Sansom writes:
> For those interested the profiling ideas that Simon PJ and
> myself have developed can be found in a draft paper available
> by ftp from glasgow.

This seems to be a good opportunity to mention the availability of my
thesis which presents a formal and practical framework for monitoring
(i.e., profiling, tracing and debugging). This framework has much
relevance to monitoring lazy (and non-lazy) functional languages.
This issue is discussed in detail there.

Some parts of this thesis were published in a paper with my advisor
P. Hudak and with C. Consel:

"Monitoring semantics: A formal framework for specifying, implementing
and reasoning about execution monitors." In Proceedings of the 1991 ACM
Conference on Programming Languages Design and Implementation. ACM,
June 1988.

Those interested in this work can contact me via e-mail:

New Haven, CT. 06520-2158                   UUCP:   decvax!yale!kishon-amir

The abstract of the thesis follows:

                          Theory and Art of
                     Program Execution Monitoring

                           Amir Shai Kishon
                         Advisor: Paul Hudak

A program execution monitor is a system that monitors the run-time
behavior of a program.  Examples include profilers, tracers, and
de{*filter*}s.  Monitors are an important element in any software
development environment. However, despite their ubiquity, formal and
general treatments of program execution monitoring are rare.

This thesis introduces monitoring semantics --- a formal model of
program execution monitors.  Using the framework of continuation
semantics, one can specify the behavior of a large family of program
execution monitors.  The resulting specification can then be
automatically combined with the standard semantics to yield a
composite semantics that is formally consistent with respect to the
standard semantics.

Beyond its theoretical interest, monitoring semantics provides a basis
for implementing a large family of source-level monitoring activities
for any language for which a continuation semantics is available.  To
demonstrate the generality and effectiveness of this approach, we use
our methodology to automatically synthesize debugging behaviors with
standard interpreters.  The enhanced interpreters are guaranteed to be
consistent with the standard interpretation.  This solves the
consistency problem that still persists in many debugging
methodologies for strict and especially non-strict programming
languages.  We present the synthesis of correct profilers, tracers
and, most importantly, interactive source-level de{*filter*}s for strict
and non-strict (lazy) functional programming languages and compare
their specifications.

Finally, using standard partial evaluation techniques as an
optimization strategy, monitoring semantics forms a practical basis
for building actual monitors.  Our system can be optimized in two
levels of specialization: specializing the interpreter with respect to
a monitor specification automatically yields an instrumented
interpreter; further specializing this instrumented interpreter with
respect to a source program yields an instrumented program, i.e., one
in which the extra code to perform monitoring has been automatically
embedded into the program.

All these ideas add up to a complete methodology for specifying,
implementing and reasoning about a large family of program execution
monitors for sequential deterministic programming languages.



New Haven, CT. 06520-2158                   UUCP:   decvax!yale!kishon-amir

Mon, 21 Nov 1994 11:51:51 GMT  
 [ 1 post ] 

 Relevant Pages 

1. Speed of FP languages, prospects (was Re: Benchmarking Lazy Functional Languages)

2. multiplatform GUI design with parallelized lazy functional language

3. Lazy and Strict Functional languages

4. Benchmarking Lazy Functional Languages

5. Partial Evaluation for Lazy Functional Languages

6. Profiling Lazy Functional Languages

7. Time complexity of lazy programs. profiling functional languages

8. Lazy-evaluation functional language for MS DOS

9. Applications for lazy functional languages

10. Functional Programming Languages with Lazy Evaluation

11. Parial Evaluation & Lazy Functional Language

12. Are macros relevant in lazy functional languages?


Powered by phpBB® Forum Software