Re: Scratch variables in GUI

[Ben Pfaff]

John Darrington <address@hidden> writes:

> I've noticed that scratch variables are being displayed in the GUI.
> That in itself is a problem which I need to fix.
>
> But I was intrigued that they seem to retain the same values that they
> were originally assigned, and appear to have space in the datasheet
> allocated.   I thought that scratch variables were reset at the start
> of each case, and I didn't expect a case source to actually allocate
> storage for them.
>
> Is this an opportunity for optimisation that we've overlooked?

Yes, to some extent.  Ideally we shouldn't ever store the values
of scratch variables in the cases presented to procedures or
written to the replacement active file.  In practice, the core
code is not yet that advanced.

Three issues (at least) have to be resolved before we can get
scratch variables to where they should be:

        1. There should be a way to ensure that scratch variables
           get allocated at the *end* of a case, never in the
           middle.  If we can guarantee that, then dropping the
           scratch values from a case before it passes to the
           procedure is easy and doesn't ever cause fragmentation
           of the case values.

           This is tricky, though: currently case indexes are
           allocated as the same time that variables are created,
           and some transformations like to record case indexes
           (usually as an optimization).  We'd need to delay
           allocation of case indexes and fix the transformations
           that try to grab them.

           Alternatively we could just decide that this isn't
           worth the trouble and just insert another case
           compaction point if the case gets fragmented by
           deletion of scratch variables.

           (I'm not sure any of the above will make sense to
           anyone but me.  If it doesn't, say so and I will try
           to elaborate.)

        2. There needs to be a good way to ensure that procedures
           don't try to access the values of scratch variables
           and in particular that mentioning them in syntax
           elicits an error message.  There are mechanisms for
           this, e.g. the PV_NO_SCRATCH option to
           parse_variables, but I worry a little that we'd miss
           some places that we need them, which could easily
           cause a segfault or at least great user confusion.  So
           ideally some kind of less error-prone mechanism would
           be created.

        3. There are other commands that need to be updated,
           e.g. WEIGHT.

It's quite possible that none of these is a big deal, especially
if we decide not to worry about the allocation order issue from
#1.
-- 
On Perl: "It's as if H.P. Lovecraft, returned from the dead and speaking by
seance to Larry Wall, designed a language both elegant and terrifying for his
Elder Things to write programs in, and forgot that the Shoggoths didn't turn
out quite so well in the long run." --Matt Olson