From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Tue, 14 Jun 2005 11:48:06 +0200
Bob Rogers wrote:
. . .
> To ignore a parameter, simply don't fetch it. To ignore a return,
> simply don't supply a register for it.
Yep - that's still doable, but not in the middle, which looks insane to
me anyway.
Not always, seems to me. Sometimes, in order to implement a defined
protocol (e.g. for a callback), you must accept a parameter that you
don't need. If the compiler can avoid allocating a register for it,
then that is a useful optimization, albeit a small one.
The same argument applies for multiple returns; arguably, this is the
more common case.
But this argument only applies to receiving values; I agree that it's
a bad idea to allow (e.g.) passing the first and third value to a
function, but not the second. I have seen languages that support this
(at least one anyway), but I'm not sure it's worth the bother. IMHO, it
addresses a need that named parameters address better.
> I would also argue that the generated PIR should be in charge of
> signalling language-specific "too few/many" args errors. (The language
> may be required to do so in any case.)
I expect that we end up with some context error/warning flags that cover
various mismatches of argument passing. Please note: the old conventions
didn't really specify what should happen for an args/params mismatch.
It was more a "don't do that then or check it yourself".
Yes, and that has always seemed fine to me. Common Lisp requires the
following [1] in such cases:
If this situation occurs in a safe call, an error of type
PROGRAM-ERROR must be signaled; and in an unsafe call the
situation has undefined consequences.
Either way, the compiler needs to generate the appropriate code; I don't
expect Parrot to do that for me.
> If we wanted to be really radical (is my head still spinning?), we
> could promote call frames to first-class objects.
Let's postpone this a bit.
No prob. ;-}
> [1] Common Lisp allows a "supplied-p-parameter" variable to be bound
> for optional and keyword arguments; see
> http://www.lispworks.com/documentation/HyperSpec/Body/03_da.htm for
> details.
Could you please translate this to PIR or some such ;-)
leo
Actually, I started to extract some examples from compiler output for my
previous post, but I was afraid that would be too noisy. I'll see if I
can produce something intelligible, but under separate cover.
From: Chip Salzenberg <[EMAIL PROTECTED]>
Date: Tue, 14 Jun 2005 12:34:02 +0200
On Tue, Jun 14, 2005 at 11:48:06AM +0200, Leopold Toetsch wrote:
> > foldup_return <index>, <flags>, <Preg>
>
> .set_returns "(0x10,0x10,0x10)", $P5, $P6, $P7
> # mark 3 pmcs as being returned as array
Unless I've misunderstood its purpose, I don't think that "foldup" is
a good feature here. There's no reason a subroutine shouldn't be
expected create an Array (or other aggregate of its choice -- note that
the specific type may be important) and return it.
The (called) subroutine could do that, but what if the callee is written
to return a series of separate values, but the caller wants them all as
a single object? The Common Lisp multiple-value-list form [3] comes to
mind here; it allows the caller to accept all values without knowing in
advance how many there might be.
> The proposal has argcI, argcP, ...
"The proposal"? (Register-)color me confused.
Me too; I didn't see these . . .
From: Chip Salzenberg <[EMAIL PROTECTED]>
Date: Tue, 14 Jun 2005 14:12:54 +0200
{Pre-Post-Script: After all this trouble below, which is hairy and yet
not even complete, parameter-by-parameter conversion is actually
starting to look good for complex cases. Despite all my reasons
against it. I start to suspect that we need both; that get_params
can be used for cases that are quite simple, and get_param [one at a
time] can be introduced for more complex cases.}
Now that you mention it, I can see that having both would be beneficial
even for the complex cases, if the boundary can be drawn appropriately.
It would be ideal if get_params (or Sub metadata) could do most of the
work, with additional ops to support the hairier stuff when needed.
Unfortunately (or perhaps fortunately), I'm out of time for making more
detailed suggestions.
Currently, @MULTI declares metadata that are attached to the Sub
structure, while get_params claims to be an executable opcode but
that's a deception . . .
So all the information currently in these places, plus more, should be
collected into a single construct that is explicitly metadata . . .
I think this is a great idea. Such metadata would of course be useful
to a debugger as well. The potential problem with metadata, though, is
that it may be overly prescriptive; if the metadata can't describe
something, it can't be done.
As a concrete example, take parameter overflow handling. In the
"Overflow" section, it says:
If too many values are provided to fit into the given target
registers, Parrot will throw an exception. Note that if the
final target is a P register with the FLATTEN flag bit, then
this exception can never occur.
In Common Lisp [2] (not to mention Perl5),
If there are more values than vars, the excess values are
discarded.
CL never signals an error for overflow/underflow of return values.
Under the current calling conventions, it costs nothing to ignore extra
returns, but the new scheme (cough) makes me either supply an unused
FLATTEN return, or set up an exception handler, both of which seem
expensive.
Of course, this particular situation can be addressed by having a way
to say explicitly "I want between M and N parameters/returns", where
some value of N means "unbounded." I just want to make the point that
such escape hatches ought to be provided.
As for default values: That's tough. Optional P parameters can be
left as null when they're missing. In addition, we'll probably need
to keep a bit mask of parameter-present flags which can be queried.
I think argc* would be sufficient -- does anyone really want to support
missing positional args? And I think it would also be necessary, even
for P registers, unless there is something that prevents the caller from
passing null P values.
-- Bob
[1] E.g. http://www.lispworks.com/documentation/HyperSpec/Body/03_eac.htm
[2] E.g. the multiple-value-bind macro,
http://www.lispworks.com/documentation/HyperSpec/Body/m_multip.htm
[3] multiple-value-list,
http://www.lispworks.com/documentation/HyperSpec/Body/m_mult_1.htm
