Return a varying number of values in IMCC?

1 view
Skip to first unread message

Bob Rogers

unread,
Mar 5, 2005, 10:37:19 AM3/5/05
to perl6-i...@perl.org
I don't see a way to do this at present. What I would like is an
equivalent to .flatten_arg for a PCC return, e.g.:

.pcc_begin_return
.flatten_arg array_of_results
.pcc_end_return

Of course, ".flatten_arg" sounds a bit odd in this context, so calling
it just ".flatten" might be better. (In which case it might be good to
support ".flatten" as a synonym for ".flatten_arg" in a PCC call.)

Is this on the right track?

-- Bob Rogers
http://rgrjr.dyndns.org/

Leopold Toetsch

unread,
Mar 7, 2005, 9:50:53 AM3/7/05
to Bob Rogers, perl6-i...@perl.org

> .pcc_begin_return
> .flatten_arg array_of_results
> .pcc_end_return

Makes sense, yes. How many return values or arguments are flattened
usually?

leo

Bob Rogers

unread,
Mar 20, 2005, 10:05:00 PM3/20/05
to perl6-i...@perl.org
The attached patch is supposed to do two things:

1. Makes it possible to say ".flatten foo" as part of a
.pcc_begin_return/.pcc_end_return sequence. Remarkably, this part of
the patch is only a one-line change; the internals for call & return are
closer than the syntax.

2. Makes ".flatten" equivalent to ".flatten_arg" for all other
purposes, to emphasize the similarity.

Unfortunately, though this patch works as intended, it also has a
number of bizarre side-effects. Here's the summary of failing tests:

imcc/t/syn/macro.t 3 768 23 3 13.04% 11-12 23
t/op/string_cs.t 9 2304 28 9 32.14% 1-2 8 20 23-26 28
t/op/stringu.t 8 2048 14 8 57.14% 2-9
t/pmc/eval.t 1 256 9 1 11.11% 4

The imcc/t/syn/macro.t failures (the ones I understand, anyway) are
because it won't accept "ok" as a macro parameter name -- it thinks "ok"
is a USTRINGC and not an IDENTIFIER; the t/pmc/eval.t case seems to be
similar. The t/op/string_cs.t and t/op/stringu.t cases, on the other
hand, say

error:imcc:syntax error, unexpected LABEL

at every point where it scans a "unicode:" or "ascii:" prefix. FWIW,
all works well if I skip the lexer changes and just change pcc_return to
add "| FLATTEN target".

So clearly something is busted in the lexer. Either I made an error
(though that hardly seems likely, since the changes are so small), or I
didn't rebuild everything properly after changing imcc.y or imcc.l.
It's remotely conceivable that there's a bug in bison and/or flex (I'm
using the SuSE RPM versions bison-1.875-51.4 and flex-2.5.4a-293).

Or it could be that something else is busted. Unfortunately, I don't
have the expertise to nail it down, and am getting fed up after putting
in about 8 hours over the last five days. Is there a yacc guru out
there who could please give me a hint?

TIA,

pcc-return-flatten.patch

Leopold Toetsch

unread,
Mar 21, 2005, 4:10:31 AM3/21/05
to Bob Rogers, perl6-i...@perl.org
Bob Rogers <rogers...@rgrjr.dyndns.org> wrote:
> The attached patch is supposed to do two things:

> 1. Makes it possible to say ".flatten foo" as part of a
> .pcc_begin_return/.pcc_end_return sequence. Remarkably, this part of
> the patch is only a one-line change; the internals for call & return are
> closer than the syntax.

Yeah. Call and return are using the same argument setup code.

> 2. Makes ".flatten" equivalent to ".flatten_arg" for all other
> purposes, to emphasize the similarity.

> Unfortunately, though this patch works as intended, it also has a
> number of bizarre side-effects. Here's the summary of failing tests:

Strange. I don't get these test failures (and I can't see, why this
patch would generate such errors).

> ... The t/op/string_cs.t and t/op/stringu.t cases, on the other
> hand, say

> error:imcc:syntax error, unexpected LABEL

The sequence ENC:"STRINGC" is longer then a label token, and I get
USTRINGC as expected.

> It's remotely conceivable that there's a bug in bison and/or flex (I'm
> using the SuSE RPM versions bison-1.875-51.4 and flex-2.5.4a-293).

Could be, yes. I've: bison (GNU Bison) 1.75, flex version 2.5.4

Anyway, applied - thanks.
leo

Bob Rogers

unread,
Mar 21, 2005, 9:41:14 PM3/21/05
to l...@toetsch.at, perl6-i...@perl.org
From: Leopold Toetsch <l...@toetsch.at>
Date: Mon, 21 Mar 2005 10:10:31 +0100

Bob Rogers <rogers...@rgrjr.dyndns.org> wrote:
> . . .

> Unfortunately, though this patch works as intended, it also has a

> number of bizarre side-effects . . .

> It's remotely conceivable that there's a bug in bison and/or flex (I'm
> using the SuSE RPM versions bison-1.875-51.4 and flex-2.5.4a-293).

Could be, yes. I've: bison (GNU Bison) 1.75, flex version 2.5.4

Anyway, applied - thanks.
leo

Great; thanks. Not surprisingly, it now works for me on SuSE 9.1 after
doing "cvs update", using the versions of imcc/imcparser.h,
imcc/imclexer.c, and imcc/imcparser.c you put into CVS.

So then I tried rebuilding these files on a SuSE 9.0 machine with
flex-2.5.4a-195 and bison-1.75-109, and found that it fails the exact
same way. That certainly makes it look like SuSE broke something prior
to 9.0.

If someone would like to try to unravel what is going on for the sake
of submitting a bug report, I'd be happy to supply the broken versions
of these files off-list. As for myself, I have lost my appetite for the
chase. At least now I know that I'm not going nuts (at least not in
that particular way), which is a relief. And I've also learned that
I'll need to install flex and/or bison from tarball if I want to use
these machines to hack on IMCC syntax in the future . . .

Reply all
Reply to author
Forward
0 new messages