what -I- consider a bug in *cabe

[Fairlight]

>From inside the gravity well of a singularity, John Esak shouted:
> 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.)

Nah, I thought I'd said, maybe I was unclear.  I'm doing this under RDP
in Windows 2003.  The DOS console windows -have- a copy and paste, but it
-really- sucks.  PuTTY would be a total no-brainer, as would Anzio, or even
screen(1).

The F8 save/load keys I actually remember using back in my 4.1 days, but I
just haven't started using them again, really--although I'm at a point in
this project where I'm going to want to start doing so again.  And now that
I look at it again, I remember what I don't like about it, but you'll think
it's possibly weird or at least a bit picky.  Basically, if I had a snippet
of code that is unsuitable for a CALLed table (in any pre-5.6 version,
basically, you can't nest CALLs, so this is the major thing that hits me),
I'll end up with handling code that needs to do various things that are
modular in nature and go into like 20+ tables.  However, I can't just make
a table and CALL it due to the no nesting limitation.  So I'd like to copy
that into every file.  Which the F8 save/load will let me do.  The part
about the F8 save/load that I don't like is having a table there that's
not meant to -ever- actually be run alone, called, chained...ever touched
directly, yet it's sitting there in your processing table list, possibly
giving someone a bad idea, or maybe just confusing someone.  At the very
least, for me, I consider it a matter of anal-retentive housekeeping, but I
acknowledge that's just me.  Yes, I know it's pretty picky, but that's my
actual reason I don't like that method.

> > 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.
> 
> 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

Ah, well, I guess I took that as just a kind of acknowledgement that I
wasn't flat-out calling it a bug, and that was appreciated in some form.

There have been examples of "typo" or semantic type bugs that fP -does-
catch that I was trying to think of last night.  Things that specifically
make me think, "Gee, if it goes this far, certainly it should check for a
non-numeric argument as a sole string literal in a place where a numeric is
required."  Emphasis on -sole string literal-.  I take your point about
runtime expression evaluation, but if it were just a single string literal
there, there's no evaluating to be done--it's correct or it's not.

However, now that I think back, I remember having issues in lookups with
long variable names if you don't put parentheses around them in the k=
portion of the lookup statement, for one.  Yes, I just tested to make sure
it still does that as of 5.6.06R4 on linux.  

::declare longvar;longvar="abcde":
::lookup test = demo k=longvar i=a -nx:

And it'll complain about longvar there as an "invalid field in processing
set" (that's the literal error text).  I would personally say that's a lot
less of a typo than what I had with my mid() statement.  And if you just
use "aa" without using it elsewhere, it complains because it doesn't exist
anywhere, which makes sense.  If you use "aa" and it is used elsewhere, it
passes.  But since I've declared "longvar", why should I get that error
unless putting parens around it?

It's convoluted stuff like that where it's obviously going to some lengths
to check against something obscure that makes me go, "If it will check for
something that arcane there, why won't it check for a simple numeric value
as a sole string literal if it detects that's all that was there?"

Perhaps it's just a matter of fP already does -too- much syntax checking
in other places, so I expect it to catch the really simple things that
it doesn't.  You do have a point though, in bringing up the expression
example for a mid() place or length indicator.  That made me think about
other languages, and for the life of me, I can't think of a language
that -would- complain about the exact same kind of error at syntax
check/compile time.  They'd all be spurious runtime results, from C to perl
to whatever--probably even BASIC.  So yeah, I think it's really down to fP
doing so much already that one starts to expect more of it than it really
does (or should do) at times.  What I'm asking for seems -logical- to
expect, but again, I can't think of another language that actually does it,
prompted by your example and reducing it to a single literal.  Even perl
took substr($test,"g","2") and just evaluated the start position to 0.

So yeah...you're right.

> 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

I agree.  I guess I just wish it was less strict in some areas and more
strict in others.  It ends up feeling kind of inconsistent in its severity
and thoroughness when you mix things like the mid() falling through the
cracks with a bad argument, yet lookup has a perfectly valid variable in
place and you have to use a special notation that's not even in the help
file, if it's a long variable that you're using and you don't want a syntax
check failure.

> 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

At least I'm not alone in having done similar.  :)  I take some comfort in
that when even the best coders do it.

Nah, upon reflection of what you said and looking at other languages (I'm
99% sure even without testing that C would compile such gibberish as well,
it would just possibly act -really- severely cranky at runtime...possibly
throwing either a segv or bus error, depending which criterion smacked it
first although I can't say without testing), I think the expectation I had
was actually likely out of bounds.  You raise a valid point.  I didn't
realise it when I posted, but yes, the original expectation I had seems
unreasonable now, put in further context and with more thought devoted to
it.

Damn, but I'm glad I prefaced it as opinion this time.  Now I only feel
like half an idiot instead of a complete one.

But this leaves me feeling unfulfilled!  :) :) :)

> Maybe a whole new class of errors??
> 
> ***Warning a typo has been encountered***
> 
> :-)

I'll go for that.  Can we also add:

***PEBKAC***

:)

mark->
-- 
No matter what your problems, modern medicine can help!
http://members.iglou.com/fairlite/fixital/