Re: for superclasses

[Michael McClary <michael>]

> [Introducing variables]
> like in a 'real' programming language is probably the correct solution,
> but would involve a *MAJOR* rewrite of Formic.  Introducing $(SUPERCLASS)
> is the best way out I've been able to think of so far, but even that is
> more than a 'quick fix' & I'm not SURE it would be unambiguous. 

$(SUPERCLASS) should be sufficient.  (It's what I thought would be the
way you'd do it.)

The only thing I see that might be ambiguous is the mnemonic.  It implies
the immediate superclass, not the current superclass in a search.  (Perhaps
"SCLASS", which could be read "StepClass"?  Or is that attempting to
resolve an ambiguity by adding MORE ambiguity? B-) )

The only TIME there's a problem is when the flow is not in a FOR SCLASSES
loop.  When you've exited from one (especially if you exited by a BREAK),
the logical thing to do is to have it hold its value until CLASS is changed
by another step of the FOR CLASSES loop.  Once that happens (or before the
loop is entered), it would be sufficient for SCLASS to become undefined-
error-to-reference.  (What happens with FUNC outside a FOR FUNCS, or CLASS
outside FOR CLASSES?)  An alternative would be holding the value beyond
scopes where it makes sense, and initializing it to something logical
(like the immediate superclass, if there is one).  This would make it
tempting to USE these out-of-context values, which is error-prone.

Though adding variables and changing the loop syntax would give the
language a lot of power, or simplify adding more power, I don't see
any need for the extra power at this time.  The uses that spring to
mind are:

  - Search up to a class with property "Foo", then iterate over its
    member functions/variables
  - Find the superclass with property "Foo", then the superclass of
    that with the property "Bar".
  - Ditto, where the search includes the starting class.

but I don't need any of them currently.  The (relativly) quick hack
is sufficient to give me:

  - The closest superclass with property "Foo".
  - Each superclass with property "Foo".
  - (and if $(FOR SCLASSES <prop: Bar>) happens, and leaves SCLASS
     set to the last match on exit):  The most distant superclass
     with the property "Bar".

and I DO need the first of these, right now, tonight.  So, despite
the historical record of hidden benefits from general solutions, I'll
ask for the hack.

====================

Unrelated issue:  I notice that chunks of stubble's output come, not
from the .f file, but from the driver script, with several annoying
downsides.  As near as I can tell, the only reason for this is that
the root of the filename is needed for the generation of two of the
early lines in the output file.  Yet the root of the file name is
available to formic, as the root of its input file's name.

If one were to define the ants $(FNROOT) and $(FNROOT_IN_CAPS),
the .f file could become the complete description of the desired
transformation (a handy modularity), the driver script could lose
all this special knowlege (which would cut its size and complexity,
and eliminate the need to hack it for each use of formic), and one
less utility would be invoked by the driver script (shaving a squidge
off the execution time).

(Note that this is not NECESSARY, either right now or ever.  It just
 appears so trivial [ from the outside B-) ] that it might be worth
 a few minutes to clean up the organization of the tool, and end the
 annoyance.)

Second unrelated issue:  Stubble copies <fnroot>.hxx unmodified to
<fnroot>-cX<tasknumber>.cxx, and then uses this file only as input
to the preprocessor, and deletes it on exit.  This has the undesirable
side-effect of making the error messages point to lines in a file that
has disappeared.  Is this a hangover?  (Perhaps from formerly-necessary
hacks to the input file, or from keeping a copy of the input during
the debugging of formic?)  Or is this perhaps to insure that formic's
input file exists?

	michael