>>>>>>>>>>Perhaps we're misunderstanding (some portion of) what Walter has been saying -- probably due to how he's been wording his responses, along with some conclusions he's arriving at: What I think he might be saying is the following:
>>>>>>>>>>* mdot isn't necessarily bad, but using it as your only defense is bad if you're not using it in *all* cases (where it would avoid potential problems)
>>>>>>>>>>* where you use mdot often depends on context (which isn't always clear [for most people])
>>>>>>>>>>* there are some known cases where mdot won't work -- such as in the case where alias names or fields that clash with identifiers such as THIS and THISFORM, or where alias or fields that are named "M" (IMHO these are "pathological" cases demonstrating problem with poor identifier choice rather than a failing of mdot)
>>>>>>>>>>* if you're not applying mdot where required (to avoid problem), it's not any different than not using it at all (don't completely agree as I see this as a broad generalization)
>>>>>>>>>>* Applying a careful naming convention (consistently) obviates the need for mdot (to avoid variable/field/alias confusion).
>>>>>>>>>>
>>>>>>>>>>Although I agree with careful naming convention could be used to avoid variable/field/alias confusion (such application of convention is relatively easy), I don't agree that it makes mdot unnecessary. I (and others) have pointed out it often doesn't work if you have to deal with "foreign" code or tables (i.e. those from a different party). He makes the statement along the lines of "such code nor tables (that don't follow the naming convention) should never be accepted" -- I would counter that by saying that you don't always have a choice on the matter when you're tasked with interfacing with a "foreign" system. You may not always (typically never) have the luxury of imposing your style or conventions on the other system.
>>>>>>>>>
>>>>>>>>>Hi Naoto,
>>>>>>>>>
>>>>>>>>>Sorry, I can't reply to every bullet in your message, since I've gone through most of them, extensively, with Walter before. Although, I just wanted to say that if one doesn't want to bother with selectively applying mdot based on context, for the sake of keeping the rule simple, mdot can be used harmlessly everywhere (including in front of THIS and THISFORM). However, the extreme cases (of fields named "this", or "m", etc) may fall under the "shooting oneself in the foot" category listed in the links that you and Dragan have posted before, though mdot may be able to diasambiguate some of those, as well.
>>>>>>>>
>>>>>>>>Actually, not everywhere. mdot with a macro doesn't work. That is:
>>>>>>>>
>>>>>>>>

>>>>>>>>&m.cSomeVar
>>>>>>>>

>>>>>>>>
>>>>>>>>is not the same as
>>>>>>>>
>>>>>>>>

>>>>>>>>&cSomeVar
>>>>>>>>

>>>>>>>>
>>>>>>>
>>>>>>>I would say that in &m.cSomeVar you are macrosubstituting m. If you'd want to apply it to var you'd have to issue

m.&cSomeVar

which works for plain values and object references.
>>>>>>>*
>>>>>>As has been previously pointed out, code like the following:
>>>>>>

cSomeVar = "? 'Hello, world'"
>>>>>>&cSomeVar.

>>>>>>will break if you do that.
>>>>>
>>>>>Yes, it will break because it is not used as intended or documented. In the statement above, you would be substituting the string "cSomeVar" with the string "? 'Hello world". It is same as
>>>>>

>>>>>#DEFINE cSomeVar ? 'Hello world'
>>>>>cSomeVar
>>>>>

>>>>>In other words, cSomeVar is not a true variable in that context. It is the plain string "cSomeVar" substituted with something else. Thus, attempting to treat it as a var should fail, as it does.
>>>>>*
>>>>
>>>>There is a subtle, but important difference. Using a manifest constant (i.e. a #DEFINE) the replacement is performed at compile time (i.e. when the text is transformed into p-code). On the other hand, macro expansion is performed at run time. I could change the contents of the variable used in the macro expansion at runtime and affect what the macro does.
>>>>
>>>>Back in the old dBASE III days you might see on occasions macros to implement what could be called "pseudo-array" (since the language didn't support subscripted variables).
>>>>

foo1 = "fee"
>>>>foo2 = "fie"
>>>>foo3 = "foe"
>>>>foo4 = "fum"
>>>>for I=1 to 4
>>>>    cIdx = ALLTRIM(STR(I))
>>>>    ? foo&cIdx.
>>>>endfor

>>>>Conceptually it's not too different from what was sometimes done in scripting languages like EXEC, EXEC2 and REXX under VM/CMS.
>>>
>>>The only difference between &cidx and #DEFINE cidx is the stage at which the substitution occurs. In the case of #DEFINE the substitution occurs at compile time, wheras in the case of &, it occurs at runtime., Like a runtime compiler, if you will. But, it does the same thing: it replaces one string with another, and if the result is not a valid statement, you'll get an error. It has nothing to do with variables, per se.
>>>*
>>
>>Perhaps there's a miscommunication here. What I've been saying (as well as others) is that in the context of a macro, the identifier specified can only be a variable (i.e. cannot be a field) -- thus the mdot is NOT required (thus in this way it DOES have to do with variables). Additionally, due to the particulars of the syntax you DON'T want to use mdot (and as has been stated previously, the meaning completely changes from what was probably intended).
>*
>I agree that it cannot be a field, but it cannot be a variable either. Thus, I feel that I have to further clarify this, and the concept of a variable.
>A variable is an identifier that stores/points to data used by the interpreted program at runtime. In that sense, in your example above, cidx is a variable only on the line of the assignment (i.e. cidx = "something"). However, on the line of the macro-substitution, cidx is no longer seen as a variable as defined in the first sentence of this paragraph, and it has no meaning for the interpreter. It becomes (part of) a token, creating a syntax that has to be compiled, and only afterwards executed. At this point the string "cidx" is data for the compiler. Would you call that a variable, or a token?
>*
I think I see what you're trying to get at. Perhaps we need to note that when a macro expansion is used, the line of code goes through different states -- in particular the pre-expansion and post-expansion state (just prior to the reparse/recompile). In the state prior to expansion, the reference to identifier "cIdx" can only be an identifier due to the context in which it is used. After the expansion (and reparse/recompile) the identifier cIdx no longer matters (since in the particular case resulting line after expansion no longer contains a reference to the identifier). After the expansion, the variable cIdx does exist -- as for what the identifier "cIdx" refers to (if it is a field or variable) depends on the context the program is running in (but in this particular example, it's moot since there isn't a reference to it after the expansion and reparse/recompile).

Now for an example that could be considered somewhat perverse:

cYuck = "? 'cYuck: '+CHR(34)+cYuck+CHR(34)"
&cYuck.

Where one probably should place the mdot is within the string expression we're assigning to variable cYuck:

cYuck = "? 'cYuck: '+CHR(34)+m.cYuck+CHR(34)"
&cYuck.

In the first line of code, the cYuck on the left-hand-side doesn't need mdot since in this given context it can only be a variable. However it shouldn't hurt to add one (unless of course, you're using WordTech's Quicksilver -- in which case results in the creation of a variable with the name that has an mdot -- i.e. it creates variable named "m.cYuck")
The second line doesn't require the mdot since in the context of the line as coded, cYuck can only be a variable. On the other hand, you don't want to add the mdot since that completely changes the meaning of the line.