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. But for pir native code(not associated
with a specific hll), I believe it'd be best to be strictest with all
errors on, that way for any code that requires loose callings it would
have to explicitly disable errors.
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"?
On Feb 6, 2006, at 9:02 PM, Bob Rogers wrote:
From: Chip Salzenberg <[EMAIL PROTECTED]>
Date: Mon, 6 Feb 2006 08:22:21 -0800
On Mon, Feb 06, 2006 at 07:33:08AM -0800, jerry gay wrote:
since we already have (as will reminded me) syntax that can be used to
express this difference, and it's tested, i may as well mention it.
() = foo(42)
works and is tested (the last two tests) in t/compilers/imcc/pcc.t.
No, when error checking is enabled, that throws an exception when
foo
returns something. (And if it doesn't, it should!)
So maybe that could mean "I want exactly zero values," whereas
foo(42)
could mean "I want any number of values"? That way, the compiler could
specify whether or not extra values were OK in any given case.
So what is missing is the ability to allow additional values after
one or more expected values. I can say "Take between zero and two
values" like this:
($P41 :optional, $I41 :opt_flag, $P40 :optional, $I40
:opt_flag)
= $P85($P45, $P46)
But there is no way to specify that three or more args are OK, without
actually specifying an explicit :slurpy register that will consume time
and memory. Maybe Parrot should support an ":ignore_extras" keyword in
the last position? So that
(:ignore_extras) = foo(42)
is equivalent to the version above without the "=". (Which preserves
orthogonality for code generators; you can do it all with the
parenthesized list syntax.)
And something equivalent ought to be done for parameters. Allowing
.param :ignore_extras
would be directly equivalent, but ugly. How about one of
.ignore_extras
.ignore_extra_params
instead?
I see the handwriting on the wall -- it says that someday soon,
Parrot will insist on strict arg/return checking all the time. 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. Doing so for parameters is less
necessary,
but also useful.
-- Bob Rogers
http://rgrjr.dyndns.org/
