Dan Sugalski <[EMAIL PROTECTED]> wrote:
> YHO would be incorrect here. There's a lot of runtime mutability, and
> there's no guarantee that a sub or method has the same prototype at
> runtime that it did at compiletime.
*if* the pdds allow such weirdness with native types. Can we define
another p
On Wed, 12 Nov 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > The reason to have them is compile-time uncertainty about call and return
> > types. Since we can't safely know with certainty what the definition of a
> > sub or method is, we need to pass into the sub/met
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The reason to have them is compile-time uncertainty about call and return
> types. Since we can't safely know with certainty what the definition of a
> sub or method is, we need to pass into the sub/method a notation of what
> parameters its getting. Other
On Mon, 10 Nov 2003, Leopold Toetsch wrote:
> 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 cou
On Mon, 10 Nov 2003, Dave Whipp wrote:
> "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
"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