There was a long duscussion about that a while ago. See Re: Type function is not smart enough Thread #714883. According to MS it's a feature not a bug and it's done this way for performance reason. It's certanly omission in FoxPro documentation.

>Hi,
>
>I'm returned from the vacations, and I resume to ...
>
>TYPE() VFP function have a bug when you use to UDF.
>
>TYPE(' udf() ') not evaluate the udf(), but search for an Array
>
>

>? EVALUATE('MyRef(1)')
>? VARTYPE(MyRef(2))
>? TYPE('MyRef(3)')
>? TYPE(MyRef(4))
>? '-------------'
>? EVALUATE('MyRef[1]')
>? VARTYPE(MyRef[2])
>? TYPE('MyRef[3]')
>? TYPE(MyRef[4])
>
>DIMENSION MyRef[1]
>MyRef[1]='ARRAY'
>
>? EVALUATE('MyRef(1)')
>? VARTYPE(MyRef(1))
>? TYPE('MyRef(1)')
>? TYPE(MyRef(1))
>? '-------------'
>? EVALUATE('MyRef[1]')
>? VARTYPE(MyRef[1])
>? TYPE('MyRef[1]')
>? TYPE(MyRef[1])
>
>PROCEDURE MyRef(z)
> ? 'call ',z && non viene chiamata da TYPE('MyProc()')
> RETURN 'ZUPPA'
>ENDPROC
>

>
>This problem derives from a sin originates made them in VFP3:
>
>it is possible to use () and [] it is for the Array, it is for the UDF;
>
>this ambiguity creates remarkable problems to the VFP Team,
>why the parser it must or resolve (slowing down) or to ignore it.
>
>An Array has priority on a UDF, but a VFP function can have priority on an Array:
>
>

> date=5 && no problem
> DIMENSION date[1] && it is ambiguous, therefore VFP generates an error
>

>
>If [] the VFP were exclusive of the Array Team would have saved a sea of controls and possible others bugs.
>
>VARTYPE() suffers from others correlate bugs.
>
>After all an unique command does not exist in order to control existence, accessibility and type of one variable, Array, property, method, udf, expression.
>
>To correct this error after VFP3, VFP5, VFP6, VFP7, VFP8 becomes critical; the only solution is to add to an option like
>SET COMPATIBLE TO VFP9
>with which the use of [] is shrunk for the Array and () for the UDF.
>
>Fabio