[m-dev.] logging proposal

[Ian MacLarty]

On 27 Feb 2006, at 15:06, Mark Brown wrote:
>
>> Clearly some kind
>> of logging feature is necessary, especially for very long running
>> programs that would be too slow in debugging grades.
>
> I'm not so sure I agree with this line of reasoning.  If your debugging
> events are going to be fairly frequently doing I/O, then surely the 
> cost
> of the I/O is going to outweigh the cost of debugging anyway 
> (particularly
> with --trace-optimized).
>
> If it is only rarely called, or only rarely doing output, then I don't
> see this feature as being necessary -- using impure code and testing 
> the
> current value of a mutable to decide whether to have the event or not
> would seem to be an acceptable solution.
>
> Because of this, and because of the situation I outlined at the start,
> I think it would be best to tie the feature to the debugging grades.
> This would also effectively stop people from trying to use the feature
> in production code, which they really shouldn't do.
>

I've been thinking about it and I feel that restricting debug goals to 
debugging grades might be too restrictive, because then you couldn't 
use the feature in non low-level grades.  Perhaps your program requires 
the features of another grade (such as hlc.par.gc, or the il backend), 
which means you can't use debug goals in your program.  Debug goals 
might be very useful for debugging, for example, concurrent programs.

As Mark mentioned there is more scope for abuse if you don't restict 
the feature to debugging grades, so I'm not sure what the solution it.  
I just thought I'd raise the point.

Ian.

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------