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
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
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
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
"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
