On Sun, Feb 05, 2006 at 09:37:39PM +0000, Roger Browne wrote: > 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).
Interesting terminology. > 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 That's a sound idea. It's even an optimization. In pasm: get_results with no parameters, not even a string, should express that the subsequent call is a void call, without our having to create a new void-call opcode. I'm struggling with good PIR syntax for it, though. A simple call without an '=' is, AFAIK, already taken to mean a call where the get_returns was already spelled out by the user in some way. Void calls will be common, so it'd be nice to express them easily. Hm. ... On a tangential matter: To address the question of describing parameters and return context, Audrey, Leo, and I considered a "signature" abstraction in Austria lo these many months ago. A Signature object would describe all the parameter and return information for a subroutine. Sadly, describing return contexts that way is dauntingly expensive. You don't want to go to the expense of creating a Signature pmc to describe every single call/return, not to mention the effect on cache coherency. Thus, it's possible we'll have signature objects for subs and more limited introspection on return signatures. -- Chip Salzenberg <[EMAIL PROTECTED]>
