Param count checks
Leopold Toetsch
Doesn't look too good. WRT return/results count mismatch, I think, this
should be a little less strict and allow 'void' function calls of
functions that return something [2]. But that's a different issue.
Failed Test Stat Wstat Total Fail Failed List of
Failed
------------------------------------------------------------------------
-------
t/compilers/imcc/syn/objects.t 1 256 11 1 9.09% 5
t/compilers/imcc/syn/pcc.t 1 256 21 1 4.76% 7
t/compilers/tge/grammar.t 1 256 1 1 100.00% 1
t/examples/streams.t 7 1792 12 7 58.33% 1-3 5-8
t/library/dumper.t 2 512 27 2 7.41% 12-13
t/library/parrotlib.t 1 256 6 1 16.67% 6
t/library/streams.t 8 2048 20 8 40.00% 9-11
13-16 19
t/library/test_builder_tester.t 1 256 12 8 66.67% 9-12
t/library/test_more.t 1 256 20 40 200.00% 1-20
t/pmc/coroutine.t 1 256 10 1 10.00% 2
t/pmc/mmd.t 1 256 30 1 3.33% 11
t/pmc/object-meths.t 1 256 33 1 3.03% 12
9 tests and 710 subtests skipped.
Failed 12/228 test scripts, 94.74% okay. 48/4858 subtests failed,
99.01% okay.
Punie is failing almost half of it's tests. I didn't check other
languages.
Fixes welcome
leo
[1]
--- src/inter_create.c (Revision 11421)
+++ src/inter_create.c (Arbeitskopie)
@@ -175,9 +175,9 @@
PARROT_ERRORS_off(interpreter, PARROT_ERRORS_ALL_FLAG);
/* undefined globals are errors by default */
PARROT_ERRORS_on(interpreter, PARROT_ERRORS_GLOBALS_FLAG);
+ PARROT_ERRORS_on(interpreter, PARROT_ERRORS_PARAM_COUNT_FLAG );
#if 0
/* TODO not yet - too many test failures */
- PARROT_ERRORS_on(interpreter, PARROT_ERRORS_PARAM_COUNT_FLAG );
PARROT_ERRORS_on(interpreter, PARROT_ERRORS_RESULT_COUNT_FLAG );
#endif
[2] generalized: a function could be allowed to return more
(positionals?) than get_results is using.
Roger Browne
> ... WRT return/results count mismatch, I think, this
> functions that return something [2]. But that's a different issue.
Some languages (including Amber) make a clear distinction between
queries (which return something) and commands (which return nothing).
If possible, please make the "little less strict" checking of function
calls be optional, so that fully-strict checking of the return count is
still possible.
Regards,
Roger Browne
Chip Salzenberg
> In another thread, Leopold Toetsch wrote:
> > ... WRT return/results count mismatch, I think, this
> > should be a little less strict and allow 'void' function calls of
> > functions that return something [2]. But that's a different issue.
>
> Some languages (including Amber) make a clear distinction between
> queries (which return something) and commands (which return nothing).
>
> If possible, please make the "little less strict" checking of function
Please detail this "query" vs. "command" distinction. Note I'm doing
requirements gathering rather than asking you to do the design. On
questions like:
dynamic vs. static
determined at call point vs. by called function
over what scope
by HLL?
by namespace?
other?
You can weigh in on those questions, but don't jump to Solution Land until
you've laid out the problem first.
--
Chip Salzenberg <ch...@pobox.com>
Roger Browne
> > Some languages (including Amber) make a clear distinction between
> > queries (which return something) and commands (which return nothing).
> >
> > If possible, please make the "little less strict" checking of function
> > calls be optional [...]
Chip:
> Please detail this "query" vs. "command" distinction.
In some situations, just "looking at something" shouldn't change it. For
example you don't want side-effects in an "assert" statement or the
behaviour of your program will change when you enable or disable runtime
assertion-checking.
Some languages (such as Amber and Eiffel) make a formal distinction
between commands (which can change state but do not return a value) and
queries (which return a value but cannot change state). This is called
command-query separation
http://c2.com/cgi/wiki?CommandQuerySeparation
and is of course very different from the C tradition where "throwing
away the return value" is permitted and commonplace.
In a language where a query cannot change state but can only return a
value, it is necessarily a bug if the returned value is not used.
Therefore, I would like to be able to detect this situation and throw an
exception.
(In its current state, Amber for Parrot does not enforce command-query
separation - but I am moving towards enforcing it at least for
preconditions, postconditions and other assertions).
> dynamic vs. static
Dynamic. The number of return values expected by the caller must match
the number of return values supplied by the dynamically-selected callee.
> determined at call point vs. by called function
Determined at every call point, according to the rules of the calling
language.
> over what scope
> by HLL?
> by namespace?
> other?
The scope is a single call point, in the sense that each test occurs at
a single call point and does not care about the rest of the program.
Furthermore, the test is at the caller's end. For example: if Amber code
calls a Python function, then the Amber code must use the Python return
value according to the rules of Amber. On the other hand, if Python code
calls an Amber function, the Amber function doesn't care what Python
does with the function's return value.
> You can weigh in on those questions, but don't jump to Solution Land ...
A solution is already defined. Leo suggested making it a little less
strict...
Leo> > ... WRT return/results count mismatch, I think, this
Leo> > should be a little less strict and allow 'void' function
Leo> > calls of functions that return something
... which would probably make life easier for implementors of many
languages, but I'm hoping to retain the option to use the strictest
checking (which will make life easier for me).
Regards,
Roger Browne
Chip Salzenberg
> Some languages (such as Amber and Eiffel) make a formal distinction
> between commands (which can change state but do not return a value) and
> queries (which return a value but cannot change state).
Interesting terminology.
> A solution is already defined. Leo suggested making it a little less
> strict...
> Leo> > ... WRT return/results count mismatch, I think, this
> Leo> > should be a little less strict and allow 'void' function
> Leo> > calls of functions that return something
That's a sound idea. It's even an optimization. In pasm:
get_results
with no parameters, not even a string, should express that the subsequent
call is a void call, without our having to create a new void-call opcode.
I'm struggling with good PIR syntax for it, though. A simple call without
an '=' is, AFAIK, already taken to mean a call where the get_returns was
already spelled out by the user in some way. Void calls will be common, so
it'd be nice to express them easily. Hm.
...
On a tangential matter: To address the question of describing parameters and
return context, Audrey, Leo, and I considered a "signature" abstraction in
Austria lo these many months ago. A Signature object would describe all the
parameter and return information for a subroutine. Sadly, describing return
contexts that way is dauntingly expensive. You don't want to go to the
expense of creating a Signature pmc to describe every single call/return,
not to mention the effect on cache coherency. Thus, it's possible we'll
have signature objects for subs and more limited introspection on return
signatures.
--
Chip Salzenberg <ch...@pobox.com>
Roger Browne
> I'm struggling with good PIR syntax for it
> them easily.
How about a 'void' keyword:
void foo(bar, baz)
Roger
Chip Salzenberg
Being the first proposal, it's pretty much the best one so far. :-,
--
Chip Salzenberg <ch...@pobox.com>
Jerry Gay
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. it
was added in order to make it easier for code generators, which
previously needed to special-case function calls with no returns, or
where they are ignored.
~jerry
Chip Salzenberg
> 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!)
--
Chip Salzenberg <ch...@pobox.com>
Bob Rogers
Date: Mon, 6 Feb 2006 08:22:21 -0800
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/
Joshua Isom
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"?
Chip Salzenberg
> 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." :-)
> 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.
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?
--
Chip Salzenberg <ch...@pobox.com>
Bob Rogers
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 <lon...@ritalin.shout.net>
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