Re: [perl #17030] [PATCH] Implementation of Lists for languages/scheme
John Porter <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>> Juergen Boemmels <[EMAIL PROTECTED]> writes:
>> > But how do I represent them at parrot-level.
>>
>> { type => '*environment*' value => {scratchpad => aScratchPadPMC}
>
> Etc.
> The point being, we're building these things into parrot so that
> HLLs can use them natively, rather than have to invent each their
> own particular flavor of wheel.
Thanks for that John. I always relish being patronized. One wonders if
you actually read to the bottom of the message where I outlined the
beginnings of a SchemeObject.PMC to provide a consistent interface to
this sort of thing (and, potentially to *any* Object like thing).
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: [perl #17030] [PATCH] Implementation of Lists for languages/scheme
Juergen Boemmels <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> writes:
>
>
> [...]
>
>> >> Cool, applied. How far from "real" scheme are we?
>> >
>> > I think its quite far.
>> > The first thing is symbols and strings. But how do I represent them at
>> > parrot-level. PerlString maybe, but then how will they be distinct
>> > from each other. Or just leave out strings for a while.
>>
>> Symbol: [ '*symbol*', "symname" ]
>>
>> Held in a Hash (hashed on the string name).
>>
>> String: [ '*string*', "a string" ]
>>
>> Which means Pairs become: [ '*pair*', , ]
>
> That would be a possibility. The object-size increase would only be
> 33-50%. To get a working prototype this is ok. Not everything is an
> object, but everything is an array.
>
> The later way would be to have two PMCs SchemeSymbol and SchemePair,
> both inheriting from PerlString (or maybe this will be renamed to
> String). The only diffrence would be the type and maybe the stringify
> function.
>
>> (Or, more likely)
>>
>> { type => '*symbol*', value => 'symbol', (vtable => ...)? }
>> { type => '*string*', value => 'a string' }
>> { type => '*pair*', value => [ , ] }
>> { type => '*int*', value => 1 }
>> { type => '*rational*', value => 1/2 }
>
> No, I don't think so. This would be a Scheme Interpreter written in
> Perl, and compiled to Parrot, and not a Scheme program compiled to
> Parrot. If language-independent means that you can write an
> interpreter for any language the C is language independent too.
Um... I don't see what having appropriate datatypes inside the
interpreter has to do with the language in which the interpreter is
implemented. Personally I think there's a very good case for
implementing the lot directly in IMCC (apart from the Object and Class
PMCs, obviously -- see below).
>> > Lexicals are also missing. I haven't looked closely to that. Without
>> > variables a language is not very useful.
>>
>> { type => '*environment*' value => {scratchpad => aScratchPadPMC}
>
> There is already a ScratchPadPMC. Where is it? It's not in classes/,
> is it. As a first implementation a PerlHash is sufficent, (I actually
> have a patch doing exactly this, it just needs a little polish. Maybe
> I will submit it tomorrow). But most of the lexical scope can resolved
> at compile time. parrot_assembly.pod describes an op fetch_lex_p_i_i
> but this seems not implemented yet.
Up to a point Lord Copper. That's not going to fly (easily) once you
have a read eval print loop in place. I want to be able to do, say
repl> (define (make-adder n) (lambda (x) (+ n x)))
#t
repl> (define add1 (make-adder 1))
#t
repl> (add1 10)
11
in an interactive session, otherwise what would be the point?
>> > lambda-expression: this may compile just down to a sub.pmc
>> > Functions like map, apply, list?, etc. have to be implemented.
>>
>> { type => '*function*', value => {env => anEnvironment,
>> arglist => aListOfSymbols,
>> sequence => aListOfForms} }
>>
>> { type => '*compiled-function*', value => aSubPMC }
>
> I haven't thought much about this yet.
Ah. Now, to my way of thinking this is the most important
part. Functions are absolutely fundamental to Scheme and you might as
well not bother until you've worked out how you're going to implement
them.
> [...]
>
>> Implementation is a simple matter of coding. I've been reasonably
>> convinced since PerlHashes became ready for primetime that one could
>> implement a full blown, if not necessarily very *fast* version of
>> scheme whilst maintaining one's own environments, continuations and
>> all the other good stuff, but lack of tuits has tended to get in the
>> way of implementing it.
>
> I also think it would be possible to implement scheme. The major
> show-stopper the access to aggregates has been solved.
>
>> Things would almost certainly be easier with full blown PMCs handling
>> dispatch for the 'thing' that a '*function*' points at, but not
>> entirely necessary. Another option is to make first class PMCs of all
>> the various types, but I'm not sure how one would go about
>> implementing 'mixed' vtables, where some things are implemented in C,
>> others PBC and still others in one interpreted language or
>> another.
>
> IMHO this is the way to go.
> SchemeString, SchemeSymbol -> Kind of PerlString, just diffrent type.
> SchemePair -> Special Class abusing pmc->data and pmc->cache.pmc_val
> as car and cdr (this needs a custom mark function) but getting rid
> of one extra indirection.
> Envoirments -> The find_lex/fetch_lex looks promising.
> Functions -> Subs should be enough.
Not even close to enough. Unless you're going to have the
Read/Eval/Print thing I showed above compile any functions down to
parrot immediately, which would be fine, but we don't yet have the
capability to create and execute parrot code on the fly, so that's a
showstopper right there. But we *can* represent
Re: Throwing lexicals
> I'm talking about just in the same namespace, how > do we keep rules from messing with file-scoped > (or any-scoped, for that matter) lexicals or globals. > How do we get rule- or closure-scoped lexicals > that are put into $0? How about something like the following rework of the capture/hypotheticals thing: You're allowed to declare variables beginning with a 0 inside rules, eg $0foo or @0bar. Rules by default capture to $0rulename. Variables that begin with a digit are rule variables, all rule variables are always hypothetical, no other variables are hypothetical. Drop the 'let' keyword. -- ralph
[perl #17109] [PATCH] Scheme: quote, define and set!
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #17109]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17109 >
Hi,
the next patch to languages/scheme. It implements the quote and a
first cut of define and set!. They work only for values at the Moment,
functions are next.
In order to get quote working I had to change the Parser in a
fundamentel way: The tree now monitors exaktly the structure of the
parens, and not special-casing the first argument. I think this is
also neccessary to get things like ((if (= 1 0) + -) 1 2) running.
It leads to an off by one in the node children, but thats rather
trivial to fix. Anyway all tests pass.
define and set! use find_lex and store_lex to read and store its
values. As there are no functions ATM they only work for values.
bye
b.
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/37055/29973/418c30/scheme.diff
Index: MANIFEST
===
RCS file: /cvs/public/parrot/MANIFEST,v
retrieving revision 1.216
diff -u -r1.216 MANIFEST
--- MANIFEST 9 Sep 2002 07:21:48 - 1.216
+++ MANIFEST 9 Sep 2002 22:48:14 -
@@ -514,6 +514,7 @@
languages/scheme/t/harness
languages/scheme/t/io/basic.t
languages/scheme/t/logic/basic.t
+languages/scheme/t/logic/defines.t
languages/scheme/t/logic/lists.t
lib/Class/Struct.pm
lib/Make.pm
Index: languages/scheme/Scheme/Generator.pm
===
RCS file: /cvs/public/parrot/languages/scheme/Scheme/Generator.pm,v
retrieving revision 1.3
diff -u -r1.3 Generator.pm
--- languages/scheme/Scheme/Generator.pm 5 Sep 2002 15:03:55 - 1.3
+++ languages/scheme/Scheme/Generator.pm 9 Sep 2002 22:48:15 -
@@ -60,10 +60,25 @@
sub _num_arg {
my ($node, $expected, $name) = @_;
- my $children = scalar @{$node->{children}};
+ my $args = scalar @{$node->{children}} - 1;
- die "$name: Wrong number of arguments (expected $expected, got $children).\n"
-if ($children != $expected);
+ die "$name: Wrong number of arguments (expected $expected, got $args).\n"
+if ($args != $expected);
+}
+
+sub _get_arg {
+ my ($node, $num) = @_;
+ $node->{children}->[$num];
+}
+
+sub _get_args {
+ my ($node, $num) = @_;
+ $num = 1 unless defined $num;
+
+ my @args = @{$node->{children}};
+ splice @args, 0, $num;
+
+ return @args;
}
#
@@ -78,26 +93,90 @@
#
-sub _op_constant {
- my ($self,$node) = @_;
- my ($num_registers,$type) = @{$type_map->{$node->{type}}};
- my @register = _save($num_registers,$type);
- for(@register) {
-$self->_add_inst('','set',[$_,$node->{value}]);
+sub _constant {
+ my ($self, $value) = @_;
+ my $return;
+
+ if ($value =~ /^[-+]?\d+$/) {
+$return = _save_1 ('I');
+$self->_add_inst ('', 'set', [$return,$value]);
+ }
+ elsif ($value =~ /^[-+]?((\d+\.\d*)|(\.d+))([eE][-+]?\d+)?$/) {
+$return = _save_1 ('N');
+$self->_add_inst ('', 'set', [$return,$value]);
+ }
+ else {
+$return = _save_1 ('I');
+$self->_add_inst ('', 'set', [$return,0]);
}
- return $register[0];
-}
-sub _constant {
- my ($self,$value) = @_;
- return $self->_generate({value=>$value,type=>'INTEGER'});
+ return $return;
}
-#
+sub _morph {
+ my ($self, $to, $from) = @_;
+
+ if ($to =~ /P/) {
+if ($from =~ /P/) {
+ $self->_add_inst ('', 'clone',[$to,$from]);
+} elsif ($from =~ /I/) {
+ $self->_add_inst ('', 'new',[$to,'.PerlInt']);
+ $self->_add_inst ('', 'set',[$to,$from]);
+} elsif ($from =~ /N/) {
+ $self->_add_inst ('', 'new',[$to,'.PerlNum']);
+ $self->_add_inst ('', 'set',[$to,$from]);
+}
+ }
+}
# Section 4
+sub __quoted {
+ my ($self, $node) = @_;
+ my $return = _save_1 ('P');
+
+ if (exists $node->{value}) {
+my $value = $node->{value};
+if ($value =~ /^[-+]?\d+$/) {
+ $self->_add_inst ('', 'new',[$return,'.PerlInt']);
+ $self->_add_inst ('', 'set',[$return,$value]);
+}
+elsif ($value =~ /^[-+]?((\d+\.\d*)|(\.d+))([eE][-+]?\d+)?$/) {
+ $self->_add_inst ('', 'new',[$return,'.PerlNum']);
+ $self->_add_inst ('', 'set',[$return,$value]);
+}
+else { # assume its a symbol
+ $self->_add_inst ('', 'new',[$return,'.PerlString']);
+ $self->_add_inst ('', 'set',[$return,"\"$value\""]);
+}
+ }
+ elsif (exists $node->{children}) {
+$self->_add_inst ('', 'new', [$return,'.PerlUndef']);
+for (reverse @{$node->{children}}) {
+
+ my $item = __quoted ($self, $_);
+ my $pair = _save_1 ('P');
+ $self->_add_inst ('', 'new', [$pair,'.Array']);
+ $self->_add_inst ('', 'set', [$pair,2]);
+ $self->_add_inst ('', 'set', [$pair.'[0]',$item]);
+ $self->_add_inst ('', 'set', [$pair.'[
Howto packout _SC / _NC KEYs
imcc (0.0.9) has an integrated parrot interpreter and tries to write out
a PBC file too. Running code succeeds currently for ~95 % of perl6
tests (in half the time ;-).
But I've problems in writing out the .pbc, especially Const_Table, type
PFC_KEY / PARROT_ARG_SC (and _NC if one would use these).
The problem seems to be, that all other key types can be looked up by
key.cache->int_val, but not _SC and _NC as there value is the contents
of another string or number constant.
So packing a packfile seems not to be reversible.
I see currently 3 possible ways to workaround this problem:
1) make another indirection in reading an _SC or _NC key, so that
key.cache->int_val is the index into the constant table and not the
string_val or the num_val itself.
2) don't use ->data as the key->next pointer but some structure
data -> { int idx, PMC *next } and store the constant index there.
3)
The easierst solution (for me): provide the possibility to call a
callback, that fills the packed structure with the required data.
Actually I have also this packed data, because on building the keys I
assemble this packed data, which on PackFile_Constant_unpack_key()
generates all the PMCs for runtime.
1) and 2) would be a general solution but require a major rewrite of key
functions / access and have drawback for speed / memory usage.
3) is "if you want to packout _SC keys, do it yourself" ;-)
Comments welcome,
leo
Re: Throwing lexicals
Luke Palmer fretted:
> This is terrible. Calling foo which calls bar mysteriously overwrites
> $date? "Why is $date changing?" the programmer asks. He does an
> exhaustive search through his code and finally says "ohh," and has to
> change all references to the inner $date to something like $mydate.
>
> This is obviously a problem (unless I misunderstood how hypotheticals
> change their surrounding scope). For a solution, let's just look how we
> do it in subroutines.
>
> my $date;
> sub foo {
> my $date = 'Jul 17, 1984';
> # ...
> }
>
> Oh. Duh. Why don't we have such a mechanism for matches?
>
> m/ my $date := /
>
> is ambiguous to the eyes. But I think it's necessary to have a lexical
> scoping mechanism for matches, as to avoid the problem I addressed above.
> Any ideas?
Yep. Allison and I have two rather nice solutions to this problem, and as soon
as we run them by Larry, and get his agreement on one or both of them,
I'll describe them here in detail.
Rest assured that we see the problem, and we're working on a solution -- or
perhaps two -- that will satisfy everyone's concerns in this area (or, at
least, make everybody equally unhappy ;-)
Damian
Re: Goal call for 0.0.9
On Mon, 9 Sep 2002, Will Coleda wrote: > Nicholas Clark wrote: > > On Mon, Sep 09, 2002 at 03:02:55PM -0400, Andy Dougherty wrote: > > For development and testing, I believe that we should exercise (and then > > exorcise) all the bugs in all the languages we can find. > Any particular reason not to have a specific make target for the > tinderboxen? Yes. Most folks don't run a tinderbox, and not everyone pays attention to the ones that are running. Further, the tinderbox only samples a small subset of the target platforms. -- Andy Dougherty [EMAIL PROTECTED]
imcc 0.0.9 runs 100% perl6 tests + various results
"perl6 --test -r" runs (i.e. executes inside imcc) _all_ perl6 tests (including t/compiler/8_5.p6) now correctly, _if_ GC is turned off. $ perl6 --test # run through assembler / parrot All tests successful, 2 subtests skipped. Files=17, Tests=72, 1 wallclock secs ( 0.16 cusr + 0.04 csys = 0.20 CPU) real1m5.575s user1m2.100s sys 0m3.300s 8_5 fails. Here is a trace diff to correct one running per imcc: PC=462; OP=656 (save_p); ARGS=(P1) PC=464; OP=672 (restoreall) PC=465; OP=741 (ret) -Wrong type on top of stack! -Error: '/home/lt/src/parrot-leo/parrot -t t/compiler/8_5.pbc ' failed with exit +PC=4; OP=0 (end) $ time perl6 --test -r # run tests per imcc All tests successful, 2 subtests skipped. Files=17, Tests=72, 0 wallclock secs ( 0.11 cusr + 0.07 csys = 0.18 CPU) real0m29.766s user0m28.640s sys 0m0.850s All is here really all. And in less then half of the time (albeit imcc did - according to the trace diff - execute one op more then parrot ;-) With GC turned on, some longer running tests fail: Failed Test Status Wstat Total Fail Failed List of failed --- t/compiler/1.te 121 8,33% 11 t/compiler/8.te 61 16,67% 5 t/compiler/qsor 11 100,00% 1 t/rx/call.test21 50,00% 2 2 subtests skipped. Failed 4/17 test scripts, 76.47% okay. 4/72 subtests failed, 94.44% okay. $ time perl6 --test -r -Rj # run JIT Failed Test Status Wstat Total Fail Failed List of failed --- t/builtins/arra 31 33,33% 2 t/compiler/3.te 71 14,29% 7 t/compiler/8.te 61 16,67% 6 t/compiler/9.te 41 25,00% 2 t/compiler/b.te 21 50,00% 2 2 subtests skipped. Failed 5/17 test scripts, 70.59% okay. 5/72 subtests failed, 93.06% okay. real0m29.045s $ time perl6 --test -r -Rb# with bounds checking and slow_core All tests successful, 2 subtests skipped. real0m30.221s and finally, for people, who know, how predereferencing works: $ perl6 --test -RP Failed Test Status Wstat Total Fail Failed List of failed --- t/builtins/arra 31 33,33% 2 t/builtins/stri 44 100,00% 1-4 t/compiler/1.te 12 12 100,00% 1-12 t/compiler/2.te 55 100,00% 1-5 t/compiler/3.te 77 100,00% 1-7 t/compiler/4.te 33 100,00% 1-3 t/compiler/5.te 55 100,00% 1-5 t/compiler/6.te 66 100,00% 1-6 t/compiler/7.te 11 100,00% 1 t/compiler/8.te 66 100,00% 1-6 t/compiler/9.te 44 100,00% 1-4 t/compiler/a.te 33 100,00% 1-3 t/compiler/b.te 22 100,00% 1-2 t/compiler/qsor 11 100,00% 1 t/rx/basic.test 66 100,00% 1-6 t/rx/call.test22 100,00% 1-2 t/rx/special.te 22 100,00% 1-2 2 subtests skipped. Failed 17/17 test scripts, 0.00% okay. 70/72 subtests failed, 2.78% okay. All results on a 800Mhz Athlon i386-linux, verified on a second one. leo
Perl 6 summary for week ending 2002-09-08
The Perl 6 Summary for the Week Ending 20020908 Well, what a week it's been eh people? Larry's been telling the Slashdot crowd about quantum god and big knobs, there's been a call for Perl 6 programmers on Perlmonks (http://makeashorterlink.com/?L51631EB1), and the Octarine parrot took flight. So, let's start with perl6-internals, as is traditional. The Octarine Parrot flies! Jeff Goff (who deserves to suffer for his parody of *Eight Days a Week*) announced Parrot 0.0.8, available from the usual places. This release includes: Working Perl 6 rules/patterns Multidimensional keyed access JIT for ARM processors Lexical scope operators Many bugfixes and smaller subsystems Mere moments after announcing the new baby, Jeff realised he'd made a mistake with the tarball's MANIFEST, and announced the release of Parrot 0.0.8.1, which has all the same features as 0.0.8, but a MANIFEST error has been excised. MANIFEST seems to be a source of problems, Tanton Gibbs had problems with it later in the week too. http://makeashorterlink.com/?A16623DA1 -- Announcement http://www.cpan.org/src/parrot-0.0.8.1.tgz -- Tarball Goal call for 0.0.9 Soon after the 0.0.8 announcement Dan asked us what we wanted to see in 0.0.9 and offered his list. The list got rather long as Sean O'Rourke, Steve Fink and Nicholas Clark all chipped in suggestions. The `long' list ended up as: * Exceptions * Initial PMC freeze/thaw API * Sub indicators in bytecode * On-the-fly bytecode section generation * Methods (in PASM and C) * Implementation of some methods for the Perl classes * Stashes * Resolve the prompt finalization problem * PMC name, implementation cleanup(*) * Filename, line number tracking * Careful elimination of compiler warnings * Rationalization of bytecode generation (*) The PMC issue was brought up by Steve. He pointed out that, right now we have a situation where theoretically language independent PMCs often refer to, and create, Perl specific PMCs on the fly, which seems rather wrong. http://makeashorterlink.com/?S12652EB1 http://makeashorterlink.com/?I13662EB1 -- Steve's list Approximate string matching in regexes Sean O'Rourke discoursed on edit distances and approximate matching, and offered a patch implementing an "rx_amatch" opcode. http://makeashorterlink.com/?U24663EB1 More regex stack manipulations Sean also implemented a couple of opcodes for manipulating the regex engine's stack; "rx_stackdepth Ix" and "rx_stackchop Ix". Dan thought that the semantics of "rx_stackchop" were slightly off, and that the instructions were actually intstack specific and should therefore be called "intstackdepth" and respectively. Dan is also `really, *really* close to tossing the last pretense of being a stack-based system and move all the way to routine-based frames instead, which would definitely make some things easier.' (Whatever that means). Sean and Steve Fink both seemed to think that that may be a step too far, at least for something as backtrack heavy as the regex core. Steve thought he would rather not create a few thousand Exception or Continuation objects. Steve also made noises about encapsulating intstack.c's functionality in an appropriately named PMC. Later in the week, Steve delivered his patch to provide an integer array PMC, but wondered if it shouldn't be called an integer dequeue (a double ended queue). John Porter voted for dequeue. Leopold Toetsch wondered why the patch needed a pair of new ops, and questioned the entire premise of the patch, so Steve mounted a sterling defence of his patch. http://makeashorterlink.com/?P25663EB1 http://makeashorterlink.com/?J16621EB1 core.ops ARGDIR Leopold Toetsch kicked off a discussion of `the intended meaning of ARGDIR_IN/OUT'. I'm afraid to say that, whilst I understand the individual words in his message, I don't really understand the posting as a whole. Which is my own fault, and makes life rather hard for a summarizer. However, Nicholas Clark and Angel Faus seemed to understand him, and discussion ensued. http://makeashorterlink.com/?D27621EB1 -- Thread starts here. Parrot: maximizing the audience Jerome Quelin put the cat among the pigeons when he made a few observations about the perlcentricity of Parrot, and wondered what the benefits of making Parrot more explicitly vendor neutral. Jerome wondered `what could *we* do in order to open parrot to non-Perl centric people?' Markus Lair suggested renaming perl6-internals to `something better like "parrot internals"'. Sean O'Rourke wondered what effect this would have, apart from breaking his procmail setup. Dan thinks we'll probably shift to a more neutral list name eventually. J
Re: [perl #17030] [PATCH] Implementation of Lists for languages/scheme
Piers Cawley wrote: > > >> Juergen Boemmels <[EMAIL PROTECTED]> writes: > >> > But how do I represent them at parrot-level. > > Thanks for that John. I always relish being patronized. You're welcome, but that wasn't for you, that was for Juergen and anyone else who might have been wondering the same sort of thing. -- John Douglas Porter
Re: [perl #17030] [PATCH] Implementation of Lists for languages/scheme
John Porter <[EMAIL PROTECTED]> writes: > Piers Cawley wrote: >> >> >> Juergen Boemmels <[EMAIL PROTECTED]> writes: >> >> > But how do I represent them at parrot-level. >> >> Thanks for that John. I always relish being patronized. > > You're welcome, but that wasn't for you, that was for Juergen > and anyone else who might have been wondering the same sort > of thing. Cautioning against reinventing the wheel is all very well, but it isn't reinventing when the wheel doesn't actually exist yet. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Problem parsing Builtins
So, I'm almost done and ready to cut the Builtins patch, but the following problem has come up: I get no warnings or errors while it reads and parses the Builtins, but then Tree.pm throws a number of uninitialized value warnings and then Context.pm throws an error about not being able to find "ctx_right" via "P6C::class_def". My brief examination of those modules shows me that this might be related to the parser having generated an invalid tree, but that's a guess based on late-game data. Have I done something obviously dumb? If anyone wants the modified "perl6" and/or Builtin modules that I've written in order to help debug this, just let me know, and I'll fire you a tarball. $ ./perl6 -wv ajs.p6 P6C 'ajs.p6' Reading 'P6C/Builtins/CORE.p6m' Reading 'P6C/Builtins/String.p6m' Reading 'P6C/Builtins/Math.p6m' Reading 'P6C/Builtins/List.p6m' Reading 'P6C/Builtins/Misc.p6m' Use of uninitialized value in string eq at P6C/Tree.pm line 208. Use of uninitialized value in string eq at P6C/Tree.pm line 208. Use of uninitialized value in substitution (s///) at P6C/Tree.pm line 219. Use of uninitialized value in pattern match (m//) at P6C/Tree.pm line 220. Can't locate object method "ctx_right" via package "P6C::class_def" at P6C/Context.pm line 172. -- Aaron Sherman <[EMAIL PROTECTED]> http://www.ajs.com/~ajs
Re: Problem parsing Builtins
On 10 Sep 2002, Aaron Sherman wrote: > So, I'm almost done and ready to cut the Builtins patch, but the > following problem has come up: > > I get no warnings or errors while it reads and parses the Builtins, but > then Tree.pm throws a number of uninitialized value warnings and then > Context.pm throws an error about not being able to find "ctx_right" via > "P6C::class_def". I'm assuming you don't have any class definitions (or declarations) in any of your builtins. If you do, then this is something like expected behavior, since classes aren't at all implemented. > My brief examination of those modules shows me that this might be > related to the parser having generated an invalid tree, but that's a > guess based on late-game data. This seems more likely -- that it's mis-parsing something as a class def (though how it does that is beyond me). If you suspect a parsing bug, it's best to fire up the parser in interactive mode with perl prd-perl6.pl [--help] which will spit out parse trees before doing the context stuff. > Have I done something obviously dumb? If anyone wants the modified > "perl6" and/or Builtin modules that I've written in order to help debug > this, just let me know, and I'll fire you a tarball. Bring it on. /s
Re: Problem parsing Builtins
On Tue, 2002-09-10 at 09:35, Sean O'Rourke wrote:
> On 10 Sep 2002, Aaron Sherman wrote:
>
> > So, I'm almost done and ready to cut the Builtins patch, but the
> > following problem has come up:
> >
> > I get no warnings or errors while it reads and parses the Builtins, but
> > then Tree.pm throws a number of uninitialized value warnings and then
> > Context.pm throws an error about not being able to find "ctx_right" via
> > "P6C::class_def".
>
> I'm assuming you don't have any class definitions (or declarations) in any
> of your builtins. If you do, then this is something like expected
> behavior, since classes aren't at all implemented.
Heh... "class real {}" ... sigh. It was a stub for the math functions
that take floating-point parameters and might benefit from communicating
that in the signature. I'll remove it for now.
I'll take that out and see how it goes tonight... off to do day-work
now.
Thanks for the tip!
--
Aaron Sherman <[EMAIL PROTECTED]>
http://www.ajs.com/~ajs
[PATCH] Re: [perl #17091] 64-bit-int builds broken
On Mon, 9 Sep 2002, Andy Dougherty wrote: > 64-bit-int builds appear to be broken. This is from Linux/SPARC with > INTVAL='long long'. This configuration used to work quite recently. The immediate culprit was config/gen/core_pmcs.pl, which now puts out prototypes of extern void Parrot_xxx_class_init(int); while classes/pmc2c.pl is using extern void Parrot_xxx_class_init(INTVAL); This won't necessarily work if sizeof(INTVAL) != sizeof(INT). (And since the prototypes are hidden in the C file, not in a shared header file, the compiler doesn't warn about them.) Upon reflection, however, since the number is used as an entry to look up in an array, I think 'int' is indeed the appropriate type, so I've changed classes/pmc2c.pl to match. This should reclaim the 64-bit tinderboxes, unless someone else has gone and broken them again in a different way :-(. --- parrot-orig/classes/pmc2c.plThu Sep 5 14:23:01 2002 +++ parrot-andy/classes/pmc2c.plTue Sep 10 11:54:51 2002 @@ -310,11 +310,11 @@ my $initline = 1+count_newlines($OUT)+1; $OUT .= qq(#line $initline "$cfile"\n) unless $suppress_lines; $HOUT .= <
[PATCH] [perl #17091] 64-bit-int builds broken
On Mon, 9 Sep 2002, Andy Dougherty wrote:
> On Mon, 9 Sep 2002, Andy Dougherty wrote:
>
> > 64-bit-int builds appear to be broken. This is from Linux/SPARC with
> > INTVAL='long long'. This configuration used to work quite recently.
>
> I've at least figured out why it core dumps -- do_panic() assumes we've
> got a valid interpreter, and tries to print out interpreter->line and
> interpreter->flags. That's obviously not going to work if the problem is
> (as it is here) that interpreter=0x0. I think the giant print statement
> needs to be broken up into pieces which are conditional on the appropriate
> things being passed in.
This patch breaks up the giant print statement into manageable pieces,
and included paranoid checking before dereferencing pointers.
--- parrot-orig/exceptions.cWed Mar 6 10:45:28 2002
+++ parrot-andy/exceptions.cTue Sep 10 11:55:04 2002
@@ -34,33 +34,29 @@
do_panic(struct Parrot_Interp *interpreter, const char *message,
const char *file, int line)
{
-printf("Parrot VM: PANIC: %s!\n\
-C file %s, line %d\n\
-Parrot file %s, line %d\n\
-\n\
+printf("Parrot VM: PANIC: %s!\n", message ? message : "(no message available)");
+printf("C file %s, line %d\n", file ? file : "(file name not available)", line);
+printf("Parrot file %s, ", "(not available)");
+if (interpreter)
+printf("line %d\n", interpreter->current_line);
+else
+printf("line ((not available)\n");
+printf("\n\
We highly suggest you notify the Parrot team if you have not been working on \n\
Parrot. Use bugs6.perl.org or send an e-mail to [EMAIL PROTECTED] \n\
Include the entire text of this error message and the text of the script that \n\
generated the error. If you've made any modifications to Parrot, please \n\
-describe them as well.\n\
-\n\
-Version : " PARROT_VERSION "\n\
-Configured : " PARROT_CONFIG_DATE "\n\
-Architecture: " PARROT_ARCHNAME"\n\
-JIT Capable : %s\n\
-\n\
-Interp Flags: 0x%x\n\
-Exceptions : (missing from core)\n\
-\n\
-Dumping core...\n\
-\n",
-message,
-file,
-line,
-"(not available)",
-(int)interpreter->current_line,
-(JIT_CAPABLE ? "Yes" : "No"),
-interpreter->flags);
+describe them as well.\n");
+printf("Version : %s\n", PARROT_VERSION);
+printf("Configured : %s\n", PARROT_CONFIG_DATE);
+printf("Architecture: %s\n", PARROT_ARCHNAME);
+printf("JIT Capable : %s\n", (JIT_CAPABLE ? "Yes" : "No"));
+if (interpreter)
+printf("Interp Flags: 0x%x\n", interpreter->flags);
+else
+printf("Interp Flags: (not available)\n");
+printf("Exceptions : (missing from core)\n");
+printf("\nDumping core...\n\n");
dumpcore();
}
--
Andy Dougherty [EMAIL PROTECTED]
Re: chr, ord etc
Attached is a sample implementation of a minor subset of pack/unpack functionality. Code is not optimised in any way, and error checking is basically non-existent. Opcodes are: convert Sx, Iy, Iz - pack integer Iy into string Sx per type Iz convert Ix, Sy, Iz - unpack integer Ix from string Sy per type Iz Currently supported types are: 0 = 8-bit 1 = 16-bit little-endian 2 = 16-bit big-endian 3 = 32-bit little-endian 4 = 32-bit big-endian -- Peter Gibbs EmKel Systems convert.t Description: Binary data convert.h Description: Binary data convert.patch Description: Binary data convert.c Description: Binary data
Re: chr, ord etc
On Tue, 2002-09-10 at 12:01, Peter Gibbs wrote: > Attached is a sample implementation of a minor subset of > pack/unpack functionality. Code is not optimised in any way, > and error checking is basically non-existent. > > Opcodes are: > convert Sx, Iy, Iz - pack integer Iy into string Sx per type Iz > convert Ix, Sy, Iz - unpack integer Ix from string Sy per type Iz Awesome, thanks! I'll get to writing a wrapper around that for ord, chr, sprintf, pack and unpack just as soon as I get done with the overall builtins mechanism tonight. I'll probably have something within a couple days (hard to get time to work on it). Of course, the same will have to be done for floating point, but this is a major step forward. -- Aaron Sherman <[EMAIL PROTECTED]> http://www.ajs.com/~ajs
Re: chr, ord etc
On Tue, Sep 10, 2002 at 06:01:23PM +0200, Peter Gibbs wrote: > Attached is a sample implementation of a minor subset of > pack/unpack functionality. Code is not optimised in any way, > and error checking is basically non-existent. > > Opcodes are: > convert Sx, Iy, Iz - pack integer Iy into string Sx per type Iz > convert Ix, Sy, Iz - unpack integer Ix from string Sy per type Iz > > Currently supported types are: > 0 = 8-bit > 1 = 16-bit little-endian > 2 = 16-bit big-endian > 3 = 32-bit little-endian > 4 = 32-bit big-endian As well as supporting big/little endian specifically, should we support "native" ie packed in the same endian as the machine the code is being run on. Graham.
Re: chr, ord etc
Graham Barr wrote: > As well as supporting big/little endian specifically, should we support "native" > ie packed in the same endian as the machine the code is being run on. Certainly. I think we would want also want native sizes, so we can ask for short, int, long etc and get the platform's size and byteorder. If the concept gets accepted, then we can start extending. -- Peter Gibbs EmKel Systems
Re: Networking and Parrot
--- Ramesh Ananthakrishnan <[EMAIL PROTECTED]> wrote: > Is it possible to write networking code in Parrot? Not yet. Someday there will probably be a Sockets extension for parrot (not really used enough to justify being in the core) __ Yahoo! - We Remember 9-11: A tribute to the more than 3,000 lives lost http://dir.remember.yahoo.com/tribute
Bug: infinite recursion caused by unary +
The following two lines of Perl 6 causes the compiler to recurse infinitely, which shows off Perl 5's recursion detection quite nicely :) my $x = 1; $x = +$x; -- Aaron Sherman <[EMAIL PROTECTED]> http://www.ajs.com/~ajs
Scheme implementation details (was Re: Implementation of Lists for languages/scheme)
Piers Cawley <[EMAIL PROTECTED]> writes:
[...]
> > There is already a ScratchPadPMC. Where is it? It's not in classes/,
> > is it. As a first implementation a PerlHash is sufficent, (I actually
> > have a patch doing exactly this, it just needs a little polish. Maybe
> > I will submit it tomorrow). But most of the lexical scope can resolved
> > at compile time. parrot_assembly.pod describes an op fetch_lex_p_i_i
> > but this seems not implemented yet.
>
> Up to a point Lord Copper. That's not going to fly (easily) once you
> have a read eval print loop in place. I want to be able to do, say
>
> repl> (define (make-adder n) (lambda (x) (+ n x)))
> #t
> repl> (define add1 (make-adder 1))
> #t
> repl> (add1 10)
> 11
>
> in an interactive session, otherwise what would be the point?
Ah I see the point. There needs to be a way to get the lexical adress
from a string. Otherweise it would be really doubling of
information: One in the compiler to get the mapping
symbol => lexical adress, and one in the repl to get the mapping
symbol => value (which internally does something like symbol =>
lexical adress => value).
Anyway the lexical scope resolution at compile-time is some kind of
optimization that wont be in the first implementation. Always look up
a lexical via find_lex/store_lex
> >> > lambda-expression: this may compile just down to a sub.pmc
> >> > Functions like map, apply, list?, etc. have to be implemented.
> >>
> >> { type => '*function*', value => {env => anEnvironment,
> >> arglist => aListOfSymbols,
> >> sequence => aListOfForms} }
> >>
> >> { type => '*compiled-function*', value => aSubPMC }
> >
> > I haven't thought much about this yet.
>
> Ah. Now, to my way of thinking this is the most important
> part. Functions are absolutely fundamental to Scheme and you might as
> well not bother until you've worked out how you're going to implement
> them.
Yes, functions are the heart of Scheme. Slowly some ideas on
implementing them come up. Your idea of using the 3 elements env,
arglist, sequence looks like the way to go. The scheme way would be to
use a list for that. The sequence would be convertet to an entry
point, as the function can be compiled in advance. The arglist may go
away when the lexical scope resolution at compile time is fully
implemented, because the only functions having access to the arglist
are the ones which are already compiled in this scope. I haven't
thought this through in detail.
> > IMHO this is the way to go.
> > SchemeString, SchemeSymbol -> Kind of PerlString, just diffrent type.
> > SchemePair -> Special Class abusing pmc->data and pmc->cache.pmc_val
> > as car and cdr (this needs a custom mark function) but getting rid
> > of one extra indirection.
> > Envoirments -> The find_lex/fetch_lex looks promising.
> > Functions -> Subs should be enough.
>
> Not even close to enough.
Ack. Thinking a little more about it, I recognized you can't get
arround the environment pointer. But perl-subs will need this pointer
also, so it may be added to the sub.pmc
sub make_add { my $add = shift; return sub { my $x = shift; return $x
+ $add }}
$add_1 = make_add (1); print $add_1->(2);
> Unless you're going to have the
> Read/Eval/Print thing I showed above compile any functions down to
> parrot immediately, which would be fine, but we don't yet have the
> capability to create and execute parrot code on the fly, so that's a
> showstopper right there.
Read/Eval/Print-Loops use eval. Eval is not the simplest part of
Scheme, but it can be implemented in Scheme, compile to parrot with
the compiler, and then get used in a repl. Then the function will
definitly have the form :
(environments arglist sequence)
> But we *can* represent scheme functions as
> environments + arglist + sequence of forms already.
Ok, you convinced me.
[...]
> typeof is a *really* bad idea. Let the 'Object' PMC handle the
> multilevel vtable look up (in exactly the same way that one does
> lexical lookup in the environment chain) and method invocation. So,
> for instance, the bare Object would have no 'cdr' method, so to do
> C<< call_method Pn, 'cdr' >> would throw an exception. But then one
> could do
>
> pair_cdr:
> ...
> ret
>
> ...
>
> new P1, .Class
> new P2, .Sub
> set_addr I0, pair_cdr
> set P1["cdr"], P2
> set P1["classname"], "SchemePair"
> set P1["isa"], "SchemeObject"
> set P2["class"], P1
> ...
>
> set I1, 0
> set I2, 1
> set P3, "foo"
> call_method P2, "set_car"
> set P3, "bar"
> call_method P2, "set_cdr"
> call_method P2, "car"
> print P3 # prints "foo"
Intresting aproach. Doing Scheme object oriented. I have to think
about this approach another day.
> The thing is, we're going to need a Class/Object structure along these
> lines for Perl/Ruby/Parrot objects anyway, so even
Configure.pl: appending not overwriting from the command line
If I want to tell Configure.pl that it needs to look in /foo/bar for
some extra include files, is there a way to convince Configure to
append that to $Config{ccflags} other than hacking config/init/data.pl?
I did this, but it is quite ugly
perl Configure.pl --ccflags="`perl -MConfig -e 'print $Config{ccflags}'` -I/foo/bar"
-kevin
--
Oh! Smells like ANSI's been here.
./Configure for Perl
Re: Scheme implementation details (was Re: Implementation of Lists for languages/scheme)
Juergen Boemmels <[EMAIL PROTECTED]> writes: > Piers Cawley <[EMAIL PROTECTED]> writes: [...] >> typeof is a *really* bad idea. Let the 'Object' PMC handle the >> multilevel vtable look up (in exactly the same way that one does >> lexical lookup in the environment chain) and method invocation. So, >> for instance, the bare Object would have no 'cdr' method, so to do >> C<< call_method Pn, 'cdr' >> would throw an exception. But then one >> could do [...] > Intresting aproach. Doing Scheme object oriented. I have to think > about this approach another day. I lifted the idea from a scheme in scheme implementation I found in _The Seasoned Schemer_ which used functions for *everything*, including pairs, so things like car and cdr became: (define (car obj) (obj 'car)) (define (cdr obj) (obj 'cdr)) This had the advantage of allowing for new types to be added easily as the implementation got extended; just implement another generic function. The approach translated almost trivially to OO. >> The thing is, we're going to need a Class/Object structure along these >> lines for Perl/Ruby/Parrot objects anyway, so even though scheme won't >> expose these PMCs to the end user, the effort in implementing them is >> definitely worth while. And I think the extra code organizing >> capability they give us is really important. >> >> Note too, that it wouldn't be hard to set up SchemeFunc, CompiledSchemeFunc >> and NativeFunc (he said, guessing at names) so that they all looked >> like Sub PMCs when it came to function call time... >> >> NB: I have a proof of concept scheme interpreter running in Perl that >> uses these OO techniques, and it works really neatly, which is why >> I've been thinking of doing the Parrot scheme interpreter in a similar >> fashion. > > I would be very intrested to hear more about this interpreter I'll see about stripping it down (it does *scary* stuff with C to get tail call optimization) to the basic objects and a simple minded interpreter then (if I can find the source...). Who knows, maybe we can port it to functional style perl 6 faster than we can implement it in raw parrot. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: chr, ord etc
On Tue, Sep 10, 2002 at 07:26:58PM +0200, Peter Gibbs wrote: > Graham Barr wrote: > > > As well as supporting big/little endian specifically, should we support > "native" > > ie packed in the same endian as the machine the code is being run on. > > Certainly. I think we would want also want native sizes, so we can > ask for short, int, long etc and get the platform's size and byteorder. > If the concept gets accepted, then we can start extending. I think we also want unsigned (ie zero extension of values shorter than intval whereas the supplied code does sign extension of values shorter than intval) I'd quite like to see 2 bits as well as 1 (binary) and 4 (hex), but I'm not sure how useful they'd be in the general case, versus an op to unpack arbitrary bit lengths, but these are really more use for a function that unpacks to an array rather than 1 value. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [PATCH] Re: [perl #17091] 64-bit-int builds broken
On Tue, Sep 10, 2002 at 12:08:31PM -0400, Andy Dougherty wrote: > This won't necessarily work if sizeof(INTVAL) != sizeof(INT). (And since > the prototypes are hidden in the C file, not in a shared header file, the > compiler doesn't warn about them.) Upon reflection, however, since the extern prototypes in a C file not in a header === bad. Reward of 1 coffee to each person who can give any reason when it is not bad. Can we make it a coding standard that we never define prototypes for external functions in source files. If we need to share prototypes between more than one source file for parrot private functions then we should use a private header file. If we need prototypes for other people's missing prototypes then we should do that in some sort of common header file. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Another bug in code generation
Another bug. This injects a stringified reference into the IMC:
sub xyz(*@rest) { }
xyz([1,2]);
xyz([]); # This one is probably the same
Got a chance to narrow this one down while I was in a meeting :)
--
Aaron Sherman <[EMAIL PROTECTED]>
http://www.ajs.com/~ajs
Re: [perl #17030] [PATCH] Implementation of Lists for languages/scheme
Sorry if this comment is out of context, I am behind but catching
up. The patch in [perl #16797] adds a scratchpad pmc (among other
things). Hopefully it is not too far out of date to apply. I
believe Melvin is looking into it ...
--
Jonathan Sillito
On Tue, 10 Sep 2002, Piers Cawley wrote:
> Juergen Boemmels <[EMAIL PROTECTED]> writes:
>
> > Piers Cawley <[EMAIL PROTECTED]> writes:
> >> { type => '*environment*' value => {scratchpad => aScratchPadPMC}
> >
> > There is already a ScratchPadPMC. Where is it? It's not in classes/,
> > is it. As a first implementation a PerlHash is sufficent, (I actually
> > have a patch doing exactly this, it just needs a little polish. Maybe
> > I will submit it tomorrow). But most of the lexical scope can resolved
> > at compile time. parrot_assembly.pod describes an op fetch_lex_p_i_i
> > but this seems not implemented yet.
>
[perl #17120] [PATCH] further compile/link/ld cleanup
# New Ticket Created by Andy Dougherty # Please include the string: [perl #17120] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=17120 > The following patch removes two no-longer-needed hints files. They are remnants of the compile/link/ld confusion fixed in perl #17007 (HP-UX state report). The first part of this patch is to *remove* two files. The second part is to adjust MANIFEST accordingly. While fixing MANIFEST, I also decided to resort it and to delete the duplicate imcc.in entry. #!/bin/sh rm config/init/hints/dec_osf.pl rm config/init/hints/unicosmk.pl exit 0 diff -r -u parrot-orig/MANIFEST parrot-andy/MANIFEST --- parrot-orig/MANIFESTMon Sep 9 08:57:16 2002 +++ parrot-andy/MANIFESTTue Sep 10 15:59:00 2002 @@ -65,14 +65,13 @@ config/gen/makefiles.pl config/gen/makefiles/classes.in config/gen/makefiles/docs.in -config/gen/makefiles/jako.in config/gen/makefiles/imcc.in +config/gen/makefiles/jako.in config/gen/makefiles/languages.in config/gen/makefiles/miniperl.in config/gen/makefiles/perl6.in config/gen/makefiles/root.in config/gen/makefiles/scheme.in -config/gen/makefiles/imcc.in config/gen/myconfig.pl config/gen/myconfig/myconfig.in config/gen/platform.pl @@ -89,10 +88,8 @@ config/init/hints.pl config/init/hints/cygwin.pl config/init/hints/darwin.pl -config/init/hints/dec_osf.pl config/init/hints/mswin32.pl config/init/hints/os2.pl -config/init/hints/unicosmk.pl config/init/hints/vms.pl config/init/manifest.pl config/init/miniparrot.pl @@ -207,9 +204,9 @@ include/parrot/global_setup.h include/parrot/hash.h include/parrot/headers.h -include/parrot/intlist.h include/parrot/interp_guts.h include/parrot/interpreter.h +include/parrot/intlist.h include/parrot/io.h include/parrot/jit.h include/parrot/key.h @@ -237,8 +234,8 @@ include/parrot/trace.h include/parrot/unicode.h include/parrot/warnings.h -intlist.c interpreter.c +intlist.c io.ops io/TODO io/io.c -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Lexicals
I am not the best one to answer these questions, but I will make some comments anyway, though Dan is/was planning to give us an authoritative position doc on some of these issues. I have done some work on some of this, but my latest code submission has not been accepted yet. On 9 Sep 2002, Juergen Boemmels wrote: > I have several questions regarding lexicals. > > There is a discrepancy between parrot_assembly.pod and core.ops > parrot_assembly.pod says that find_lex will return a pointer, where as > core.ops uses find_lex to retrive a value and store_lex to set this > value. Which of this is correct? > I would think it will become pointers. > parrot_assembly mentions a fetch_lex_p_i_i but there is no > implementation yet. This functions would be very handy when you know > at compile time whats in the lexical scope. Is this left-out > intentional or just because nobody has yet implemented it. In the > later case, is somebody already working on this? > This is still the plan and I believe that "by index" is going to be the fastest way to access lexicals. I have been thinking about implementing something for this but I am waiting to see if my previous patch gets committed so I can be sure I am heading in a reasonable direction. On the other hand maybe I should just press forward? > How are the integers of the lexicals in the pad assigned? I assume > they get increasing numbers for each store_lex, starting at 0 for a > new pad. Correct? > > How do I store to a lexical by number? Shouldn't be there also a > store_lex_i_i_p (or set_lex to indicate that it is a change of an > already existing binding). Dan has hinted that there will be some way, in parrot assembly, to provide a static pad descriptor that could be used to put all lexicals in place when the pad is first created. > Is there a possibility to get a pointer to the current pad, to store > it in the closure? (Im not sure, maybe only the top-pad is needed). > There need also be a way to reinstate the saved lexical. I have submitted code that does this sort of thing for subroutines. -- Jonathan Sillito
Bug in argument handling
This short bit of code does a good job of pointing out two bugs. One is
that the C<*@y> sucks up ALL of the arguments, not just C<@_[1..@_]>,
and also that C<"\$x"> prints a lone backslash.
Please correct me if I've misused these operators. Thanks!
sub abc($x,*@y) {
die "Why is \$x undefined" unless defined $x;
}
abc(1,2,3);
--
Aaron Sherman <[EMAIL PROTECTED]>
http://www.ajs.com/~ajs
Perl 6 bug on integer parameter handling
Here's my latest bug, which I will work on tracking down. It's a pretty
huge blocker for everything I've been working on, so there's no sense in
spending my time elsewhere:
sub def ($arg) {
return $arg;
}
$o = 25;
$q = def($o);
die "Why is return value $q?" unless $q == $o;
The problem seems to be that any numeric argument is converted to 1 (is
that a list length?)
--
Aaron Sherman <[EMAIL PROTECTED]>
http://www.ajs.com/~ajs
Re: Perl 6 bug on integer parameter handling
On 10 Sep 2002, Aaron Sherman wrote:
>
> Here's my latest bug, which I will work on tracking down. It's a pretty
> huge blocker for everything I've been working on, so there's no sense in
> spending my time elsewhere:
>
> sub def ($arg) {
> return $arg;
> }
> $o = 25;
> $q = def($o);
> die "Why is return value $q?" unless $q == $o;
>
> The problem seems to be that any numeric argument is converted to 1 (is
> that a list length?)
Correct. List/scalar context is done at compile time, so all subs return
lists -- there is no "wantarray". I believe "($q) = def($o)" will work,
but I should probably fix that to put the last returned value in the
result if the function returns to a scalar. Or look at the "return"
statement, figure out whether it looks like a scalar, array, or
tuple/list, and use the existing logic for assigning between these things.
/s
Re: Bug in argument handling
On 10 Sep 2002, Aaron Sherman wrote:
> This short bit of code does a good job of pointing out two bugs. One is
> that the C<*@y> sucks up ALL of the arguments, not just C<@_[1..@_]>,
> and also that C<"\$x"> prints a lone backslash.
>
> Please correct me if I've misused these operators. Thanks!
>
> sub abc($x,*@y) {
> die "Why is \$x undefined" unless defined $x;
> }
> abc(1,2,3);
Heh. It appears that splat arguments have only been tested with "@_".
I'll fix this tonight. It should be easier than the return values thing.
/s
