>I disagree. I have had to work through other developers' code where there was so much macro expansion going on, you couldn't tell what the hell was happening. Passing the name of a command as a parameter to another function is a crime worthy of punishment by troutslap. I've actually seen this and many other crimes committed using & as the weapon.

Criminal mind will do its thing using even command.com's batch language. There are so many recipies for spaghetti - I remember one guy issuing a Read after each Get, so he got a Cobol-style entry screen (back in FP2). Having weapon at hand is no excuse, and, OTOH, is the weapon to blame?

>Right, but I view this not as a glorious use for &, but as a shameful workaround for big gaping holes in our language. I am of the opinion that ALL VFP commands should take named expressions instead of literals. But until then, we'll have to keep patching those holes with &.

Now, my point becomes slightly moot, because the OOP, among others, broke one thing which I thought was an axiom - "whatever you put between quotation marks is your private matter or a file name". I.e. the contents of string literals didn't influence the flow of execution. Then came xBase and all of a sudden even filenames didn't need quotes arround them (look at USE command - you can USE "thetable" and USE thetable, it's all the same). Then came FP and suddenly you had names of things, like windows and menus - names, not variables - which were programmatically meaningful, and now with OOP you have very important strings, like classnames, parameters to CursorG/SetProp()... and you can make your app very thoroughly data-driven by just setting the class names in a table (object factory pattern). By just using name expressions, parameters to various calls and setting properties, you can do a lot - much more than the &-armed cowboys could do before.

Still, I think many things which made Fox such a good tool to have data driven apps are originating from use of & in turning data in tables into workable components of an app. What else would you use for a data driven menu? I was using eval() back in FPD, because I ran each DO this With list,of,parameters as a function - but now with Do Form, well, it would be far cleaner and easier to use a macro, right?

And, of course, various forms of filter builder which allow us to build a complicated string and then Select ... where &lcCondition. I don't see how would this be accomplished except by having Fox use its own data through its own OLEDB provider, which doesn't make much sense to me.

Others may add their own.