"Dan Sugalski" <[EMAIL PROTECTED]> wrote
> Right now, the only true difference between a sub call and a return, at
> least at the assembly level, is that we don't pass back a return
> continuation when we're returning
If one is coding a co-routine/iterator, then perhaps even this difference
might
Dan Sugalski wrote:
Anyway, time to unify. The question, then, is what gets kept and what gets
tossed. The return spec says we pass in the number of P, I, S, and N
params we're returning, which is fine,
I don't think we need these counts. If the call is prototyped, the
caller knows the type and
Okay, so it's time to get this taken care of.
Right now, the only true difference between a sub call and a return, at
least at the assembly level, is that we don't pass back a return
continuation when we're returning. You can, if you really want, even
arguably consider a sub PMC as a frozen semi-s
Jonathan Lang writes:
> To make "method" work as an alternative for "multi" in every case, the
> only changes that you'd need to make would be to allow more than one
> invocant to be explicitly specified in the "method" syntax, and to allow
> the positional portion of the parameter list to optional
Jeff Clites wrote:
Okay, that makes sense then. So is the current implementation
incomplete? I ask because it looks like the mark functionality won't yet
quite deal with non-PObj values, etc.
The mark_key (and hash, compare) functions can be passed to the extended
new_hash_x() creation functio
