what -I- consider a bug in *cabe

[Fairlight]

On Sun, Jun 03, 2007 at 09:42:45PM -0400, Kenneth Brody may or may not have
proven themselves an utter git by pronouncing:
> What sort of "typos" are you refering to which filePro catches at
> compile time yet aren't syntax errors?

My example below (omission of parens) was what I considered one of them.  I
was (and am, currently) at a loss to remember other examples I'm sure I've
encountered but cannot recall ATM.

> > ::declare longvar;longvar="abcde":
> > ::lookup test = demo k=longvar i=a -nx:
> 
> This _is_ a syntax error.  What follows "k=" must either be a field,
> or an expression contained within parentheses.  The variable "longvar"
> is not a "field".
[snip]
> As I said above, the variable longvar is not a "field".

This is where I take exception to seemingly inconsistent behaviour or
definitions.

You declare a long variable name, and it acts -just- like a dummy
field--EXCEPT in certain cases.  

Dummy fields -were- basically the only type of variables before long
variables ever existed.

Now that you have long variable names, you're discriminating arbitrarily
between the two.  

Both can act as variables, and both can act as fields (my definition of
such here being that you can define a length, edit, and global flag for
long variables that are declared, as you can with any dummy or regular
field).  Syntactically, they act almost identically, with the exception of
the global/extern and the related functionality in the declaration and use
for one, and the magical instantiation in the other.  But they still act
like long-named dummy fields with those two exceptions.  They were -billed-
in the hype for whatever version they appeared as a substitute for using
the limited pool of dummy fields, even if it was unofficial billing.  That
was ostensibly the whole reason they were introduced at the time, was
people running up against reasonable 2-letter combinations from a pool of
4096.  I remember discussions hailing this as solving the problem of a lack
of proper dummy variable names.  "Variable" has always been interchangeable
with field as far as dummy fields went, as far as I can tell.  I've heard
the same people use both terms interchangeably.

So they have the same semantic use for most people (with the exception of
inter-table value passing), yet you consider one a field and one a variable
in a seemingly arbitrary way.

That's something I find infuriatingly frustrating as a programmer.  They're
a replacement, but at the same time they're not replacement.

Seems like a mighty fine line, given the history of "variables" in fP.
Given your statement that "longvar" isn't a field, "aa" is, then fP -never-
had variables until what, 4.8?  One can't claim it did if one claims this
distinction...it simply can't swing both ways if it's defined as one or the
other and they're not actually synonymous.  And if it can, I'm not seeing
it, honestly.

I'd call it splitting hairs and irrelevant--not even worth
discussing--except things -break- depending on what you decide to call them
and how they're treated, and people need to understand those differences to
achieve things.

mark->