SL>Hi again everyone!
SL>DECLARE FUNCTION Trim$(BYVAL STRING) AS STRING
SL>DECLARE FUNCTION GetNCWord(BYVAL STRING, BYVAL STRING) AS STRING
SL>and then in the function definitions ...
SL>FUNCTION Trim$(BYVAL StringContents AS STRING) LOCAL
SL>FUNCTION GetNCWord(BYVAL NCBlock AS STRING, BYVAL Letter AS STRING) LOCAL
I've had that happen to me more than once....  ;)
SL>As you can see, I had omitted the returned type of the function
SL>in the function definitions, and they should have read as follows:
SL>FUNCTION Trim$(BYVAL StringContents AS STRING) LOCAL AS STRING
SL>FUNCTION GetNCWord(BYVAL NCBlock AS STRING, BYVAL Letter AS
SL>STRING) LOCAL AS STRING
SL>This raises a couple of other questions though.  Other than the obvious
SL>Trim$ name and the AS STRING type declaration of one of the functions,
SL>what redundancies exist in what I've done?
SL>What precisely does the LOCAL keyword do in a function definition?
LOCAL is the default.  It means that all variables in the following
SUB/FUNCTION are local to it.  You don't have to state that explicitly,
because it is the default.  Had that been SHARED, all variables would be
SHARED, and STATIC would mean that they'd all be STATIC.  This defines
the default "life" of the variables in the procedure.  All others must
be explicitly declared, like this:
SUB MySub (...) SHARED
        LOCAL i,x,y
        ' The following i is local....
        FOR i = 1 TO 100
                PRINT i
         NEXT i
        ' The following a is shared...since SHARED is the default for
        ' this SUB....
         a = 100
END SUB
This is useful if most or all of the variables declared in a procedure
are of one type, either SHARED or STATIC.  (As I've already said, LOCAL
is not strictly necessary, because it is the compiler default.)
SL>How many of you actually leave the full array/variable declaration
SL>requirement on _ALL_ the time?  Under what conditions might you turn it
SL>off?  It seems to be a bit of a pain to keep all that stuff in line for
SL>what many of you will consider to be a trivial program.
I use it quite often, and will use it more in the future.  If you turn
it on, it effectively turns the compiler into a one pass compiler,
rather than a two pass compiler.  Try turning it on for a trivial
program, and watch the "pass" meter during the compile.
SL>And on a slightly different PowerBASIC topic ...
SL>What does PowerBASIC do with constants when they're declared?  I know
SL>that it's possible, though undesirable, to have two *variables* of two
SL>different types called (for example) Nuts$ and Nuts#.  This seems to be
SL>impossible if you've turned on the full variable checking, because you
SL>can't declare them this way.  Please correct me if I'm wrong.
You cannot, with declaration mode on, have two variables WITHIN THE SAME
SCOPE with the same base name.  This is how C programmers have always
had it.  I prefer DIM a AS STRING and SUB MySub (A AS INTEGER, etc.)
The old-style suffixes are very nasty to parse with preprocessors.  You
can, however, have two variables of different types with the same name
within DIFFERENT SCOPES, such as:
DIM a AS STRING
MySub a
SUB MySub (Param AS STRING)
        DIM a AS INTEGER
        FOR a = 1 TO 100
                PRINT Param
        NEXT a
END SUB
I always like to imagine a scope resolution operator before the
variables local to a procedure, like this:
        DIM MySub::a AS INTEGER
That helps to mentally separate similarly named variables....
SL>Now, as I understand it, PowerBASIC declares named constants by
SL>preceding the "variable name" with the type, something called an
SL>"equate."  If I declared a constant called %TRUE, which I obviously might
SL>use as the integer representation of a boolean flag, must I also
SL>use %TRUE throughout the body of the program when evaluating some
SL>expression relationship to %TRUE, or can just TRUE be made to suffice?
Constants are preceded by %, not the type, and may only be numeric.  I'd
like to see string constants.  TRUE and %TRUE are not one and the same.
%TRUE is a global constant, whereas TRUE is an identifier that may be of
any datatype.  The %nnnnn format makes it quite clear upon seeing it in
the code that its value is numeric, integer, and cannot be changed.
TRUE can be changed, but to what, we don't know.
SL>Thanks for taking the time to look through this with me.
Sure.  I've been analyzing PB syntax for months now for my Fermat
preprocessor, and these issues come up daily these days.
Cheers,
Jamshid
--- Maximus/2 2.01wb
---------------