Extend logging library to also support some kinds of bookkeeping

[pschachte]

Now we can use this library to log a message when something happens, but I'd like to be able to quickly insert a line of code here and there to count how often something happens. Ideally, this would allow multiple things to be counted, so each would need to have a name. One way to implement this would be to mis-use resources (now that they're represented as global variables).

Note that this library is for semipure operations intended for debugging and similar, not for semantically significant code.

[pschachte]

Part of the rationale for this is that it's a nuisance to turn functions into procedures just so that they can use resources, and then turn them back into functions when you're done with the bookkeeping.

[jimbxb]

I'm not quite sure I follow the train of thought. Using resources will always require you to transform a function into a proc.

Perhaps promoting all resources to global variables isn't what we should be doing. If we could annotate resources to be "metric"s, we could do the old-school non-flobal transformation from before HO.

Something like

resource {metric} counter:int

use counter in {
    !tick
    !logmsg("counter: $counter")
}

def tick use !counter {
    !counter + 1
}

Maybe metric isn't the right name. But if we're counting something, it fits in nicely.

[jimbxb]

Now that I've thought about it, maybe we could add a special resource that does this.

def tick use !call_counter {
    !logmsg("tick called $call_counter times")
}

A proc annotated with call_counter would generate a global call_counter#proc (here call_counter#this.module.tick<0>, initialised to 0. (I think we'd reuse the global for a multispec.) The generated LPVM code for the proc would then load/incr/store to this global upon each invocation.

Unlike most special resources, no additional parameter would be generated, and would allow this to work seamlessly with HO code.

[pschachte]

Sorry, I wasn't clear. The idea is to provide operations that use impurity (actually, semipurity) to update data storage, implemented as static variables, so there would be no need to use a resource. The operation would be semipure, though, so it would still need a !. That would allow it to be called from anywhere without serious code rewriting, just like the logging operations.

One way to do this would be to allow a resource declaration to specify {semipure} or {impure}, which would allow it to be treated as available everywhere, even in procedures (and function bodies) that don't specify that they use that resource. However, procedures that use them would need to be declared {semipure} or {impure}, and so, of course, would need a ! where they're called.