> Naoto, actually you only need the m. when referencing a variable.
> myvar=3
> mynewvar=m.myvar+4
> To be honest it only matters for very tight loops- the tiny delay is otherwise invisible.
> I don't know much about Quicksilver.
Already knew that -- in short, the m. prefix is really only needed in situations where there may be an abiguity in what you're referencing (memory variable or field). In assignments it's not required (as you can't change the value of a field using the syntax of a variable assignment). Adding the extraneous "m." prefix in places where they're not really needed is essentially harmless in FoxPro and VFP. As I mentioned earlier, in the Quicksilver compiler you get an unexpected suprise when you add the "m." when specifying the target of the assignment -- you end up with memory variables which have the "m." prefix as part of the variable name. One place where the m. prefix is neither necesssary nor desired is in macro expansions. Macros only work with memory variables (so the prefix is not necessary), and by adding the m. prefix you're saying you want to replace the value of the variable "m" in that place:

Test = "The value of 'Test'"
MyTest = "The value of 'MyTest'"
m = "My"
? &m.Test

By the way, we dropped Quicksilver after trying out FoxPro for DOS (version 2.0) and noticing that the same pieces of code would run noticibly faster than it did under Quicksilver (which *at best* yielded a 3-fold improvement in execution speed over dBASE III). Switching to FoxPro also allowed us to improve the UI by using some built-in constructs (not available in dBASE III nor Quicksilver) for things such as drop-down menus and windowing interface (previously we had highlight-bar menus implemented which looped around using INKEY() to scan the keyboard and repainting accordingly. The "window" interface was implemented by taking snapshot of screen prior to drawing a window and restoring the snapshot to "erase" it -- of course it's not a full implementation as you couldn't really reposition these "windows").