What you ask here is very interesting to me, because some time back I got to thinking about what Alan Kay talked about with trying to negotiate meaning, in reference to using Licklider's concept of "communicating with aliens." Kay (IIRC) used a simpler concept of trying to order a burrito from a vendor, where neither the vendor nor the customer understand each other's language. He said by using gestures, you can get the idea across, because you can reference common concepts in each other's heads, and finally come to agreement about ordering a burrito. So, I started on a "sketch" for a language for a fairly simple task (converting between encoding schemes) where the code was suggestive, rather than prescriptive, and it just used a declarative style. One example is I just said, "a5 b6 10..." (including the double-quotes, and the trailing "...") to try to suggest a string containing a sequence of hex numbers of indeterminate length. I was saying, "Expect this type of information." As I did this, and thought about what else the language would need to express, I came to the exact same question you did, "There could be a variety of interpretations of this. Maybe the dev. environment should ask the programmer questions, 'Did you mean...?'" The programmer could respond in some way meaning "Yes" or "No." If no, the dev. environment could ask about other possible meanings it knows about, based on the syntax used. I could see this getting complicated very quickly, because what I hoped for was that the language would give a programmer the freedom to try expressions that made sense to them, in hopes that the language environment with which the programmer communicated would understand them, and that the language environment should try as "hard" as it could to understand them. However, not being skilled in AI, I wondered if the forms of expression I was thinking about were constrained enough in meaning that I could completely code a scheme whereby, looking at syntax "signals" in the code, it could reason through the expressions to make good guesses about their meaning, and then test them by formulating intelligible questions about them to confirm what the programmer was getting at. Going through that exercise told me I had a lot to ponder, learn, and explore with this idea, because I didn't come up with any ready answers that felt satisfactory. The best I could come up with was that I would code the language to allow a few possibilities with the syntax "signals," in combination with other "signals" that I could anticipate, but if the expression went beyond the coded meanings, I'd have to have the language say, "I don't understand what you're talking about. Please try expressing it differently," which would lead to a kind of guessing game between the programmer and the language, with the programmer quickly getting the idea, "There have got to be some rules to this system. Why don't I just look at its programming, and figure out how I use its rules to express what I want," which would defeat what I was going after. The whole thing would be an artifice, rather like an Eliza simulation.