Re: Unifying call and return

2003-11-13 Thread Leopold Toetsch
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

Re: Unifying call and return

2003-11-12 Thread Dan Sugalski
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

Re: Unifying call and return

2003-11-12 Thread Leopold Toetsch
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

Re: Unifying call and return

2003-11-12 Thread Dan Sugalski
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

Re: Unifying call and return

2003-11-11 Thread Dan Sugalski
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

Re: Unifying call and return

2003-11-10 Thread Dave Whipp
"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

Re: Unifying call and return

2003-11-10 Thread Leopold Toetsch
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

Unifying call and return

2003-11-10 Thread Dan Sugalski
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