what -I- consider a bug in *cabe

[John Esak]

>
> With neither thought nor caution, Kenneth Brody blurted:
> > You do know that you can F8/Save from one, and F8/Load in another,
> > don't you?
>
> I do know that, but depending on the situation, it's almost as cumbersome
> (sometimes moreso) than trying to use copy & paste.  At least for
> me.  Used
> to use it, but haven't in ages.

I use the F8/save/load functions 100's of times a week when I'm programming
in filePro. Don't see how anyone could write inside the cabe editor without
them. For smller than a lines worth of cut and pasting... how is it possible
that you're not working in an emulator that doesn't support it. FacetWin, at
least, supports the Windows clipboard/mouse... so where do you lose any
ability at all... unless PUTTy or is it pUTTY or do I mean PuTtY ... is
braindead in this simple regard? (I was guessing you use that eumulator...
you used to , anyway.)

> >
> > Are you passing a literal that is probably not what you meant?  Yes.
> > Is it invalid syntax?  No.
>
> >From the cabe help file:
>
>          MID()              Finds and copies the middle of a field.
>
>
>            Syntax
>
>                 a=MID(f,"s","n")
>
>                  where f is a field, s is the starting position
> and n is the
>                  number of characters from the starting position.
>
> It flat out says 'n' is the number of characters.  Context and
> common sense
> indicate that 's' is likewise a -number- of characters into the
> string (ie.,
> the starting position literally stated).
>
> Thus, unless character number "$" is a valid starting position, it's a
> syntax error in my book.  Since "$" isn't a number, that's always going to
> be logically false, and thus always wrong.
>
> I'm not likely to win this debate, so I'll just concede the point.
> However, I did take exception with your logic, given the docs cited.
>
> mark->

You actually *did* win this one... enough to have Ken immediately and
without any hassle, argument, complaint, or disagreement of any kind simpoly
and concisely answer your first observation and report with "Noted".  This
has come to mean (for me anyway) that Ken probably fixed that little
situation 5 minutes after you brought it up. Interesting, that you were the
first in over 25 years to have typo'd in this way causing the situation to
come up. I would think you would be very happy with a "Noted" and its
implied fix (or change of docs)... but, since you wish to go on quoting the
Syntax for the MID function and talking about it "flatly states" this and
such... and so forth.  I'm afraid I have to agree with Ken.  You really
aren't going to win this one... especially if you start out by saying that
yourself. :-)  My take on it is that there is certainly no syntax error in
what happened to you. All syntactical form was followed precisely.... no
error can be generated. What there needs to be is a very short statement
appended to the documentation which instructs that you (as the programmer)
must be aware that if the expression you use for the starting location in
the mid string resolves to something that does not point to a position
*within* that string then that would be an invalid parameter for the
function. It has *nothing* to do with syntax and "syntax" checking. What you
seem to be asking for is a second level of checking for acceptable values in
a function... and nowhere is this sort of checking done. This is why I
suggest an addition to the docs disclosing the limitations of pointing to a
position in the  string which doesn't exist, or using a value or character
in the case of the "$" that doesn't oint anywhere.

What you sound like you're asking for Mark, is a spell checker that not only
checks for correct spelling but then also checks for correct meaning and/or
grammar.... "I'm going to cut my meet with this fork and knife." passes all
the syntax for a proper sentence, but it obviously makes no "sense". Do you
know any spell checkers, or for that matter even any grammar checkers that
would flag this sentence as wrong?

And if you can't agree that there are these various levels and types of
checking that don't refer to the syntax of a function, then you might later
say that filePro should also try and wipe the butt of the programmer who
writes:

     xx=mid("myargument",yy,zz)

by first trying to resolve what yy and zz will result in and only *pass*
this line for good syntax if yy falls between "1" and "10", and then ZZ
falls to some value that that fits from that starting point to the end of
the length of the mid_string. Obviously, this is a runtime operation and not
a compile time thing... and furthermore, just because you used a specific
literal with your "$" instead of any old expression... (incidentally, in my
book, literals are expressions too... it's a fully enfranchised subset of
the concept of an expression by anyone's book I would hope), even so, it
still is not special enough for filePro to run an entire 2nd level check
against "values" just to ascertain whether proper *syntax* has been
followed. No question, I agree, a "$" can never point to a valid position
within the string... but then neither could "3" in some cases, or "29" or an
infinitude of other perfectly fine values based on the mid string length of
course.

Like I say, the best you are going to get, is a notation in the docs about
the "problem"... tiny as it is.... big though it was when it bit you... (I
am sympathetic... similar things have bitten me), but I wouldn't be
surprised if there wasn't some behind the scenes change by Ken or someone at
FP Tech which somehow ameliorates the situation you fell into, but again, I
believe it will be notational. Unless, of course, Ken or another programmer
at FP Tech actually has the time to insert a huge table of non-allowed
literal single characters into the MID command.  (Let me say, I *hope* they
have far better things to do with their time.) :-)

As for some kind of "logical" code being written into the function so that
it generates a syntax error on typo... I wouldn't really hold my breath,
because as you start to work it out... you begin with saying... let's
disallow any literal <1 or >len(mid_string).... oops, but there you go
again, jumping into that real-time operation of calculating what the length
of the mid_string is... so you can disallow values higher than it by calling
them a syntax error.... 1) you can't perform the runtime calc at cabe
compile time, 2) you can't call it a syntax error if the syntax has been
followed properly.

Maybe a whole new class of errors??

***Warning a typo has been encountered***

:-)


John