Changes between Version 12 and Version 13 of ExplicitCallStack


Ignore:
Timestamp:
Jan 29, 2007 4:11:53 PM (7 years ago)
Author:
guest
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ExplicitCallStack

    v12 v13  
    7070The key issues are: 
    7171 
    72  * Higher-order calls. Where does a partially applied function receive its stack trace from? Possible options include: 
     72 * '''Higher-order calls'''. Where does a partially applied function receive its stack trace from? Possible options include: 
    7373   1. The lexical call site (corresponding to where the function is mentioned in the source code. 
    7474   2. The context in which the function receives a particular argument, for instance the one where it is saturated.   
    7575 
    76  * CAFs. The problem with CAFs is that, at least for expensive ones, we want to preserve the sharing of their evaluation. Therefore we cannot simply extend them into functions which take a stack trace as an argument - this would cause the CAF to be recomputed at each place where it is called. The simplest solution is to make CAFs the roots of call stacks, but it seems like there will be situations where it would be useful to know more about the context in which a CAF was evaluated. 
     76 * '''CAFs'''. The problem with CAFs is that, at least for expensive ones, we want to preserve the sharing of their evaluation. Therefore we cannot simply extend them into functions which take a stack trace as an argument - this would cause the CAF to be recomputed at each place where it is called. The simplest solution is to make CAFs the roots of call stacks, but it seems like there will be situations where it would be useful to know more about the context in which a CAF was evaluated. 
    7777 
    78  * Recursion. Obviously the call stack will grow in size proportional to the depth of recursion. This could lead to prohibitive space usage, thus it is desirable that the size of the stack be kept within reasonable bounds. We will probably need some way to dynamically prune the stack. 
     78 * '''Recursion'''. Obviously the call stack will grow in size proportional to the depth of recursion. This could lead to prohibitive space usage, thus it is desirable that the size of the stack be kept within reasonable bounds. We will probably need some way to dynamically prune the stack. 
    7979 
    80  * Extent. It is desirable to have a scheme where only some functions in the program are transformed for stack tracing, whilst others remain in their original form. We want to avoid the ``all-or-nothing'' situation, where the whole program has to be recompiled before tracing can be done. For example, with the current state of profiling in GHC, the whole program has to be recompiled, and special profiling libraries must be linked against. This is a nuisance which reduces the usability of the system. Similar problems occur with other debugging tools, such as Hat and buddha, and this really hampers their acceptance by programmers. 
     80 * '''Extent'''. It is desirable to have a scheme where only some functions in the program are transformed for stack tracing, whilst others remain in their original form. We want to avoid the ``all-or-nothing'' situation, where the whole program has to be recompiled before tracing can be done. For example, with the current state of profiling in GHC, the whole program has to be recompiled, and special profiling libraries must be linked against. This is a nuisance which reduces the usability of the system. Similar problems occur with other debugging tools, such as Hat and buddha, and this really hampers their acceptance by programmers. 
    8181 
     82=== An abstract syntax === 
     83 
     84For the purpose of exploring the rules we need an abstract syntax. Below is one for a simple core functional language: 
     85 
     86{{{ 
     87   Decls --> x :: T | x = E | data f a1 .. an = K1 .. Km 
     88}}} 
    8289 
    8390