First of all, you could have a VARIENT variable type (which would be default, say, unless a SET STRICTVARTYPE was set at compiletime), which could be anything. So this would still work:

LPARAMETERS tvFirst, tvSecond
DO CASE
  CASE VARTYPE(tvFirst) == "N"
    ...
  CASE VARTYPE(tvFirst) == "O"
    ...
...

BUT, you could also have code like this:

FUNCTION DoSomething(nNumber STRICTAS Number)
FUNCTION DoSomething(cNumber STRICTAS Character)
FUNCTION DoSomething(vNumber STRICTAS Varient)

So, Code like this:

DoSomething(nNumber)
DoSomething(cBlah)
DoSomeThing(oObject)

Would all still work, as any variable type can be changed to Varient. That would be pretty cool, no?

The only problem it would cause is FoxPro would have to search all possible/available functions, before it could run the function. So, you would need either something that specifies to not search outside the APP/EXE, OR, something like a function to search and build a list of available functions, which would still slow VFP down. For example:

* These could possibly call different functions, but "@DoSomething"
* would be faster, because the compiler can mark which function to use.
* There are a lot of issues here, actually. Anyway you look at it though,
* making VFP have these kinds of strictness is going to make VFP much slower,
* unless a lot more happens at compiletime.
@DoSomething(cSomething)
DoSomething(cSomething)
*OR
DoSomething(cSomething)
VFPReloadFunctions()
DoSomething(cSomething)
*Could also run different functions

-----

*Consider this code!
DoThis("1")

Function DoThis(tcValue STRICTAS Character)
LOCAL cValue STRICTAS Character

cValue = EVAL(tcValue) && Can't be evaluated until runtime

-----

* So what does foxpro do? Error? Not assign anything?
* This adds a great deal of potencial complexity. Of course,
* it also eliminates a great deal of complexity, as the compiler can catch
* a bunch of mistakes, like this:

@DoSomething(1) && Ooops! supposed to be "1"
FUNCTION DoSomething(tcToWorkOn STRICTAS Character)

* Of course, you must have the "@", or the compiler has no way of knowing 
* that you don't have an external program named DoSomething.
* Actually, a SET STRICTCALLS makes sence here...
* Or perhaps:
#PRAGMA STRICTCALLS ON
*(also a SET STRICTCALLS for a default. PRAGMA would apply only to that method)
* This errors if there's no "FUNC DoSomething(cParameter STRICTAS Character)"
* or "FUNC DoSomething(vParameter STRICTAS Varient)" or compatable function 
* in the APP/EXE
LOCAL cStuff STRICTAS Character
cStuff = "Stuff"
DoSomething(cStuff)
#PRAGMA STRICTCALLS OFF
* This doesn't error until runtime. I doubt that most developers would have 
* PRGs in the runtime directory, so they could just have STRICTCALLS on all
* the time.
LOCAL cStuff
cStuff = "Stuff"
DoSomething(cStuff)

Ok, that's a big enough post. What does everyone think?