>I have four suggestions.  If I'm being redundant or even repeating
>something over and over again, my appologies  :-)
>
>1) a STATIC declaration which would be similar to the C construct
>allowing a variable's value to persist between execution iterations,
>but allow the variable to be scoped as well.  Such a declaration
>might also allow scoping so that one could have a LOCAL STATIC or
>a PRIVATE STATIC variable (obviously a PUBLIC STATIC wouldn't make much
>sense).  STATIC by itself could default to either (as you choose).
>
>2) The ability to assign an initial value in a declaration.
>e.g:
>LOCAL lnCounter = 0
>PRIVATE STATIC lcOutString = ""
>
>3) An OPTION EXPLICIT, similar to VB.  I think this would be invaluable
>in aiding debugging and helping to create more stable applications.
>Making it an option wouold allow compatibility with existing code bases
>as well as enforcing shop standards where pre-declaration is required.
>
>4) Finally, VFP now initializes empty parameters to .F.  This makes
>checking for non-passed parameters a little more difficult than it
>could be.  Offering something like:
>SET NULLPARM TO
>	-or-
>SET EMPTYPARM TO
>Would allow the developer to devine the value passed in such a case.
>One could use:
>SET NULLPARM TO .NULL.
>	-or-
>SET EMPTYPARM TO CHR(255)
>
>Then in code one could say:
>
>SET EMPTYPARM TO .NULL.
>
>? Hello( .T., "Keith")
>
>REPLACE Greeting WITH Hello( .T.,,{06/01/1999})
>
>THIS.txtSalutation.Value = Hello( "Keith")
>
>
>FUNCTION World( vlPrintName, vcName, vdToday)
>
>IF ISNULL( vcName) OR VARTYPE( vcName) <> "C"
>	vcName = "whatever your name is"
>ENDIF
>
>IF ISNULL( vlPrintName) OR VARTYPE( vlPrintName) <> "L"
>	vlPrintName = .F.
>
>ENDIF
>
>IF ISNULL( vdToday) OR VarType( vdDate) <> "D"
>	llDateEntered = .T.
>	vdToday = DATE()
>ELSE
>	llDateEntered = .F.
>ENDIF
>	
>lcRetVal = "Hello "
>IF vlPrintName
>	lcRetVal = lcRetVal + ", " + vcPrintName + "."
>ENDIF
>
>IF llDateEntered
>	lcRetVal = lcRetVal + " The date you entered was " ;
>		+ DTOS( vdToday)
>ENDIF
>
>RETURN lcRetVal
>
>An admittedly contrived example, but you get the point.  Named parameters
>would be nice too, but I suspect that it would add a bit of overhead to
>the parsing routines that would, I'm sure not be welcomed in the VFP
>community  :-)
>
>	...kt
>
>