I wrote: > > Some languages (including Amber) make a clear distinction between > > queries (which return something) and commands (which return nothing). > > > > If possible, please make the "little less strict" checking of function > > calls be optional [...]
Chip: > Please detail this "query" vs. "command" distinction. In some situations, just "looking at something" shouldn't change it. For example you don't want side-effects in an "assert" statement or the behaviour of your program will change when you enable or disable runtime assertion-checking. Some languages (such as Amber and Eiffel) make a formal distinction between commands (which can change state but do not return a value) and queries (which return a value but cannot change state). This is called command-query separation http://c2.com/cgi/wiki?CommandQuerySeparation and is of course very different from the C tradition where "throwing away the return value" is permitted and commonplace. In a language where a query cannot change state but can only return a value, it is necessarily a bug if the returned value is not used. Therefore, I would like to be able to detect this situation and throw an exception. (In its current state, Amber for Parrot does not enforce command-query separation - but I am moving towards enforcing it at least for preconditions, postconditions and other assertions). > dynamic vs. static Dynamic. The number of return values expected by the caller must match the number of return values supplied by the dynamically-selected callee. > determined at call point vs. by called function Determined at every call point, according to the rules of the calling language. > over what scope > by HLL? > by namespace? > other? The scope is a single call point, in the sense that each test occurs at a single call point and does not care about the rest of the program. Furthermore, the test is at the caller's end. For example: if Amber code calls a Python function, then the Amber code must use the Python return value according to the rules of Amber. On the other hand, if Python code calls an Amber function, the Amber function doesn't care what Python does with the function's return value. > You can weigh in on those questions, but don't jump to Solution Land ... A solution is already defined. Leo suggested making it a little less strict... Leo> > ... WRT return/results count mismatch, I think, this Leo> > should be a little less strict and allow 'void' function Leo> > calls of functions that return something ... which would probably make life easier for implementors of many languages, but I'm hoping to retain the option to use the strictest checking (which will make life easier for me). Regards, Roger Browne
