[GRASS-dev] grass is a monad?

[Glynn Clements]

Paul Kelly wrote:

> So, I feel the idea behind Glynn's comments (and one that I guess I would 
> agree with) is that we encourage other projects to use GRASS by calling 
> the modules directly. As GRASS has so few developers compared to the 
> massive body of code, putting in extra development time to make GRASS work 
> in ways that have no benefit for GRASS is just too much effort.

That's about right.

Maybe I can elaborate:

1. The GRASS libraries handle errors by calling exit(). This avoids
the need for callers to explicitly handle errors and for either the
caller or callee to perform cleanup.

It's possible to avoid the call to exit() by installing an error
handler which longjmp()s out; However: it is implied that calling
G_fatal_error() relieves the caller of the responsibility to restore
GRASS data structures to a consistent state. If you longjmp() out of
the error handler, then make further calls to GRASS functions, they
may crash.

This is Not A Bug. Calling into GRASS after a fatal error *is* a bug.

2. The GRASS libraries don't bother tracking (and freeing) memory
which would only represent a fixed overhead for a GRASS module, or
which would typically not be freed until shortly before termination. 

If an operation uses a small amount of memory (e.g. a map name) and is
typically performed once or a few times per map, we don't care about
freeing it. A module will inevitably need some amount of memory for
each map which it opens, and if the difference between freeing and not
freeing means that the amount is 15Kb rather than 10Kb, then it
doesn't really matter.

It all gets returned to the OS when the module terminates anyhow.

If you try to write a persistent application which continually opens
and closes maps, eventually the accumulated leaks will cause it to run
out of memory.

This too is Not A Bug. Not isolating distinct operations in distinct
processes *is* a bug.

Both of these strategies make it much easier to both implement the
GRASS libraries and to use them, and they work perfectly well for the
libraries' intended purpose: writing GRASS modules.

If it means that they aren't suitable for other purposes, that is
Not A Bug.

For any changes, the main concern is how those changes impact GRASS
itself. If the changes impose extra effort on anyone writing GRASS
modules, or (to a lesser extent) anyone modifiying the libraries, then
those changes would be a net loss for GRASS.

-- 
Glynn Clements <glynn at gclements.plus.com>