Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:16 PM +0100 11/16/04, Leopold Toetsch wrote:
>>This would imply a distinct return opcode instead of C.
> That went in, or was supposed to go in, as part of moving the return
> continuation into the interpreter struct. I presume this hasn't
> happened
At 9:16 PM +0100 11/16/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
+I if there are overflow parameters. Otherwise garbage
+=item I0
+
+=item I1-I4
I3 isn't always visible?
Effectively it is, yes.
> ... Fetching the return continuation
+may be expensive, and
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> +I if there are overflow parameters. Otherwise garbage
> +=item I0
> +
> +=item I1-I4
I3 isn't always visible?
> ... Fetching the return continuation
> +may be expensive, and should only be done if truly necessary.
Err, e.g. for returning fr
Maybe I should wait for the entire picture here, but in cases like this
(int $x, string $y) = some_function()
it would be nice to pass in both type _and_ number of return values. Or,
more generally, to consider the type of a list to be a list of the types
of its members. This means tha
