From: Chip Salzenberg <[EMAIL PROTECTED]>
Date: Tue, 7 Feb 2006 08:26:46 -0800
On Mon, Feb 06, 2006 at 10:02:40PM -0500, Bob Rogers wrote:
> I see the handwriting on the wall -- it says that someday soon,
> Parrot will insist on strict arg/return checking all the time.
"... by default." :-)
I figured that's what you had in mind. On the other hand, if a definite
loose vs. strict choice is made for each syntax alternative, then each
compiler can emit syntax that specifies exactly what it requires, and
the default doesn't matter. That seems cleaner than having a dynamic
switch that runs roughshod over compiler expectations.
To put that another way, I think it's necessary to provide a syntax
choice that means "never signal an error," and another (possibly a
variation on the first) that means "always signal an error." Given
these choices, why would I need anything else? What is the advantage
for having additional syntax that means "do whatever the last person to
mangle C<errorson> said"?
> In order to support Common Lisp correctly (and efficiently), I would like
> to be able to shut this off for returns without having to add a useless
> :slurpy register everywhere.
Yes, we've observed that same need elsewhere (e.g. PGE). It'll be
provided.
Excellent; thank you.
A question though: Does CL code want to make sure to ignore extra
values it receives from a call, or does it want to force its callers
(CL or not) to ignore extra values when it returns them?
This is all about receiving values from called functions; it has to be
CL semantics when compiling CL code to receive values, regardless of
where the values came from. On non-CL receivers of Lisp return values,
the spec is silent. ;-} But I think the receiving language rules
should prevail in that case, too.
Though, come to think of it, someone calling into CL from a stricter
language may have to take extra measures to deal with an indeterminate
number of return values. I have noticed that writers of Common Lisp
tend to be sloppy about the number of trailing NIL values, since that's
the only supported default. That could be handled by a wrapper, which
may sometimes be necessary anyway (e.g. for named argument passing).
From: Joshua Isom <[EMAIL PROTECTED]>
Date: Mon, 6 Feb 2006 21:23:35 -0600
From what I can tell, the biggest concern is how different languages
will want it done. Why not allow it to be hll specific? Perhaps
either using a .HLL directive or perhaps a sub with a :hll_init or
something that is called whenever entering that hll, so strictness can
be defined per hll and make it easier for hll's to interoperate with
regards to differences in what's allowed. Some languages are very
strict, some are very loose . . .
That's why I would like to see syntax variants that cover all bases.
The code emitted to accept parameters or returns can then specify
directly what is supposed to happen, effectively making it HLL-specific
without requiring hidden magic. (HLL-specific magic may still be needed
behind the scenes to define what class of error to signal, but that's a
lesser detail.)
For syntax, I think it'd be expected that few will combine pasm calling
conventions, the long pir conventions, and/or the short pir
conventions. So then why not say "foo(42)" just means "ignore
returns", and combining the various conventions to be "undefined
behavior"?
That's OK as far as it goes, but it still doesn't support "take up to
two values and ignore any more."
-- Bob
