Patch applied to trunk in r20879.
On Aug 25, 2007, at 10:47 PM, James Keenan via RT wrote:
On Sun Aug 19 08:55:30 2007, coke wrote:
This was part of the gmake extensions that we (can) support during
makefile-generation time; added because there was there no cross-
platform syntax that I knew of that we could use in all of the
Will Coleda wrote:
That said, I don't see '$(basename ...)' used anywhere in the code base.
The other three (addprefix, wildcard, and notdir), are all used by Tcl
(and only by Tcl)
I don't see where 'addprefix' or 'notdir' is used outside of where
they're defined in
$ ack addprefix | wc -l
2
$ ack -a addprefix | wc -l
3
ack, by default, searches a subset of files.
On Aug 20, 2007, at 9:24 PM, James E Keenan wrote:
Will Coleda wrote:
That said, I don't see '$(basename ...)' used anywhere in the code
base. The other three (addprefix, wildcard, and
I have been writing tests for previously untested statements in
Parrot::Configure::Step. In genfile(), there is the following block:
# documented as removing any .-based suffix
if (
$line =~ s{\$ \( basename \s+ ([^)]+) \)}{
join (' ',
This was part of the gmake extensions that we (can) support during
makefile-generation time; added because there was there no cross-
platform syntax that I knew of that we could use in all of the
various makes we have to support.
See perldoc lib/Parrot/Configure/Step.pm look for
tests. Whoever works
on this should see whether this subroutine is called anywhere in
the lib/ or config/ hierarchies.
2. Branches and conditions in various subroutines: file_checksum
(); genfile(); run_command(); cc_build(); cc_run(); cc_run_capture
(); check_progs(); slurp(). As with item
in various subroutines: file_checksum();
genfile(); run_command(); cc_build(); cc_run(); cc_run_capture();
check_progs(); slurp(). As with item (1), each subroutine should be
checked for current instances of usage during configuration.
3. There has been talk in other RT threads cc_build
chromatic wrote:
On Tuesday 21 November 2006 18:36, James E Keenan wrote:
3 identically named subroutines: 2 in modules and 1 in a script. And
all 3 will be in modules as I'm planning to refactor much of pmc2c.pl
into a module called Parrot::Pmc2c::Utils. (For drafts of these
revisions
Note the results:
[parrot] 502 $ ack 'sub gen_c'
lib/Parrot/Pmc2c.pm
1221:sub gen_c {
lib/Parrot/Pmc2c/Library.pm
134:sub gen_c {
tools/build/pmc2c.pl
821:sub gen_c {
3 identically named subroutines: 2 in modules and 1 in a script. And
all 3 will be in modules as I'm planning to refactor
On Tuesday 21 November 2006 18:36, James E Keenan wrote:
3 identically named subroutines: 2 in modules and 1 in a script. And
all 3 will be in modules as I'm planning to refactor much of pmc2c.pl
into a module called Parrot::Pmc2c::Utils. (For drafts of these
revisions, see http
On Oct 18, 2006, at 4:27 PM, Jerry Gay (via RT) wrote:
currently, this policy does not ignore subs which exit or die... it
forces the addition of a return statement in these subs. yuck. this
policy will be disabled until this is fixed.
~jerry
Fixed in Perl::Critic svn r737. This will appear
# New Ticket Created by Jerry Gay
# Please include the string: [perl #40564]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40564
currently, this policy does not ignore subs which exit or die... it
forces the
Given IMC like:
.sub main @MAIN
$P1 = whee()
print $P1
.end
.sub whee
$P2 = new PerlString
$P2 = leo\n
.return ($P2)
.end
We get a trace like:
0 set P16, PMC_C[2]- P16=PMCNULL,
3 set I0, 1- I0=0,
6 set I1, 0- I1=0,
9 set I2, 0- I2=0,
12
Huh. That's annoying. attached trace for readability.
William Coleda wrote:
garbled trace
0 set P16, PMC_C[2]- P16=PMCNULL,
3 set I0, 1- I0=0,
6 set I1, 0- I1=0,
9 set I2, 0- I2=0,
12 set I3, 0- I3=1,
15 set I4, 0-
btw, thanks to whoever fixed macros so that they could be defined outside of .sub's.
Very handy.
Mattia Barbon [EMAIL PROTECTED] wrote:
Hello,
crrently argument count is passed in I3. A comment in untils.c
near foldup says that:
TODO - IMCC and PDD 3 aren't yet in conformance.
The TODO is obsolete. IMCC is fixed (at least until it comes to overflow
which isn't handled everywhere).
Hello,
crrently argument count is passed in I3. A comment in untils.c
near foldup says that:
TODO - IMCC and PDD 3 aren't yet in conformance. This uses the current
IMCC setup, but should be changed as soon as IMCC modified to the
correct calling conventions.
while pdd03 says:
Dan Sugalski [EMAIL PROTECTED] wrote:
Interesting. However... the two programs aren't equivalent. You're
using constant values and putting results onto an existing data
structure in perl, so true 'equivalence' requires a few changes to
the source. With those in place, I get the following:
Joe Wilson [EMAIL PROTECTED] wrote:
$ time parrot -j f6.pasm
21001094.10 (note: wrong result and slower with jit)
I don't get a slow down nor a wrong result (i386/linux). On what
platform do you test?
leo
Dan Sugalski [EMAIL PROTECTED] wrote:
SArray and Array PMCs, in addition to being sparse (which has some
overhead), allow you to really store PMC *, STRING *, INTVAL, and
NUMVAL entries, which means that each slot in an SArray and Array
needs to have a flag on it that says what data type's in
Joe Wilson [EMAIL PROTECTED] wrote:
Perl's arrays do indeed accept mixed data types (see example below).
Perl's Arrays take SV's. Please use a PerlArray instead of SArray.
Parrot (still built unoptimized) is significantly faster then perl5 on this
test.
leo
Joe Wilson [EMAIL PROTECTED] wrote:
I implemented the same variable argument function varargs_adder
in both Perl 5 (addit.pl) and Parrot (f4.pasm).
I've put in the addit benchmarks and some variations of it:
- addit.pl ... as of Joe Wilson
- addit.pasm .. ditto but use PerlArray
- addit.imc ...
On Dec 28, 2003, at 1:42 AM, Leopold Toetsch wrote:
Joe Wilson [EMAIL PROTECTED] wrote:
Perl's arrays do indeed accept mixed data types (see example below).
Perl's Arrays take SV's. Please use a PerlArray instead of SArray.
Parrot (still built unoptimized) is significantly faster then perl5 on
I implemented the same variable argument function varargs_adder
in both Perl 5 (addit.pl) and Parrot (f4.pasm).
The variable arguments can be strings, integers or floats
(I wanted to excercise dynamic variable behavior).
I called the function 50 times in a loop to benchmark it.
The results
At 12:19 PM -0800 12/27/03, Joe Wilson wrote:
I implemented the same variable argument function varargs_adder
in both Perl 5 (addit.pl) and Parrot (f4.pasm).
The variable arguments can be strings, integers or floats
(I wanted to excercise dynamic variable behavior).
I called the function 50
At 4:16 PM -0500 12/27/03, Dan Sugalski wrote:
1) Perl's data structures (the equivalent of PMCs) been heavily
optimized, to date Parrot's haven't been
2) Parrot's Array and SArray values all accept mixed-type data,
which perl's arrays do *not* do, and as such have some extra speed
hits that
Dan Sugalski:
2) Parrot's Array and SArray values all accept mixed-type data, which
perl's arrays do *not* do, and as such have some extra speed hits
that perl arrays don't.
What do you mean?
Perl's arrays do indeed accept mixed data types (see example below).
$ cat addit2.pl
Joe Wilson writes:
Dan Sugalski:
2) Parrot's Array and SArray values all accept mixed-type data, which
perl's arrays do *not* do, and as such have some extra speed hits
that perl arrays don't.
What do you mean?
Perl's arrays do indeed accept mixed data types (see example below).
No,
At 2:38 PM -0800 12/27/03, Joe Wilson wrote:
--- Luke Palmer [EMAIL PROTECTED] wrote:
Joe Wilson writes:
Dan Sugalski:
2) Parrot's Array and SArray values all accept mixed-type data, which
perl's arrays do *not* do, and as such have some extra speed hits
that perl arrays don't.
At 6:17 PM -0500 12/27/03, Dan Sugalski wrote:
[reasons and some excuses for slowdowns snipped]
None of this, I should point out, in any way means we don't have a
problem, because we do. Things are *not* as fast as they should be,
and we need to address it. (And I'm glad you've brought it up,
On Sat, Dec 27, 2003 at 06:17:34PM -0500, Dan Sugalski wrote:
Also, you might want to make sure you've built Parrot with
optimizations on. By default we don't enable GCC's -O to do any
optimization, and that does slow things down a bunch. On the other
hand, it makes debugging a whole lot
I used the default ./configure options (no idea what they were).
But more to the point - no one explained why the Parrot JIT ran
the code 3 times slower and arrived at the wrong result.
--- Nicholas Clark [EMAIL PROTECTED] wrote:
On Sat, Dec 27, 2003 at 06:17:34PM -0500, Dan Sugalski wrote:
At 6:34 PM -0800 12/27/03, Joe Wilson wrote:
I used the default ./configure options (no idea what they were).
The default's no optimization. At this point we're in development, so
having a build that can be meaningfully thrown into a debugger's more
important than the ultimate speed. (Besides,
On Tue, 5 Aug 2003 12:48, Michal Wallace wrote:
It does seem like there are some snags getting
languages to talk to each other, even with the
calling conventions, but even so, I'm even more
convinced now that a generic, overridable
code-generator is the way to go.
It seems to me that if we
- Original Message -
From: Joseph Ryan [EMAIL PROTECTED]
To: Michal Wallace [EMAIL PROTECTED]
Cc: K Stol [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, August 05, 2003 12:24 AM
Subject: Re: generic code generator? [was: subroutines and python status]
Michal Wallace wrote:
On Sun
On Tue, 5 Aug 2003, Dan Sugalski wrote:
The original thought was to use the new perl 6 grammar engine/code
to do this, but I think it'll be a while before that's ready to go.
I think perl6 is definitely the way to go, once it's ready.
BTW, what's the deal with Bundle::Perl6? I tried
On Tue, 5 Aug 2003, Joseph Ryan wrote:
Okay, I don't have a good syntax in mind yet,
the point is it's a template language and you
can subclass/override/extend the template.
Maybe there's no syntax and it just uses
cleanly coded classes in some oo language.
Or perl6 with it's grammars and
At 1:35 PM -0400 8/5/03, Michal Wallace wrote:
On Tue, 5 Aug 2003, Joseph Ryan wrote:
Okay, I don't have a good syntax in mind yet,
the point is it's a template language and you
can subclass/override/extend the template.
Maybe there's no syntax and it just uses
cleanly coded classes in some
On Thu, 7 Aug 2003, Dan Sugalski wrote:
haskell_parser - ast - pirate - parrot_code -- imcc - pbc
^
|
parrot_code__templates
So the haskell
Michal Wallace wrote:
On Sun, 3 Aug 2003, K Stol wrote:
What do you think? Want to try squishing pirate/python
and pirate/lua together? :)
Yeah, I like the idea. Let's try this out.
Well, I finished reading your report[1] and
posted some of my (rather unorganized) thoughts
up
At 11:09 PM -0400 8/4/03, Michal Wallace wrote:
On Tue, 5 Aug 2003, Stephen Thorne wrote:
Thus the code generator is best suited to be in a language that can
be run from within the parrot machine, otherwise statements like
'eval()' would not be possible without binding parrot to a
On Sun, 3 Aug 2003, K Stol wrote:
What do you think? Want to try squishing pirate/python
and pirate/lua together? :)
Yeah, I like the idea. Let's try this out.
Well, I finished reading your report[1] and
posted some of my (rather unorganized) thoughts
up at [2]
It does seem like there
On Tue, 5 Aug 2003, Stephen Thorne wrote:
It seems to me that if we want to maximize the
number of languages using it, the generic
compiler shouldn't depend on anything but
C and parrot... But until we get it working,
I'd like to stick to a dynamic language like
On Fri, 1 Aug 2003, K Stol wrote:
From: Leon Brocard [EMAIL PROTECTED]
...
I don't like things becoming dead-ends. How much work do you think
it'd be to extend it some more and update it to latest Lua?
...
2: I misdesigned the code generator; that is, at the point where I
couldn't start
On Sun, 3 Aug 2003, K Stol wrote:
At this moment, I'm looking at a new version of Lua, the previous
'pirate' compiled (well, sort of :-) Lua 4 Lua 5 has some features,
such as coroutines (If I remembered well) and all kinds of neat
stuff for which Parrot has built-in support (and it dropped
On Sun, 3 Aug 2003 19:25, Michal Wallace wrote:
On Fri, 1 Aug 2003, K Stol wrote:
Really, there's a ton of overlap between the various
high level languages that parrot wants to support.
Maybe we could put together a generic code generator
that everyone could use? Obviously, it would have to
Leopold Toetsch wrote:
Luke Palmer [EMAIL PROTECTED] wrote:
You mind submitting a patch to put this in the languages/pirate
I'd appreciate that very much. Pie-thon, here we come ...
Speaking of adding new projects to languages, I have a partially complete
JVM-PIR translator done. It's
- Original Message -
From: Melvin Smith [EMAIL PROTECTED]
To: Luke Palmer [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, July 31, 2003 3:33 PM
Subject: Re: subroutines and python status
At 01:51 PM 7/31/2003 -0600, Luke Palmer wrote:
You mind submitting
K Stol sent the following bits through the ether:
Actually, I named my little project pirate (s.
http://members.home.nl/joeijoei/parrot for this) already, but it's a bit of
a dead end already (although I learnt much of it), so I don't mind.
Quick, we need more parrot jokes...
I don't like
- Original Message -
From: Leon Brocard [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, August 01, 2003 1:30 AM
Subject: Re: subroutines and python status
K Stol sent the following bits through the ether:
Actually, I named my little project pirate (s.
http://members.home.nl
At 11:04 PM +0200 7/31/03, Leopold Toetsch wrote:
Luke Palmer [EMAIL PROTECTED] wrote:
You mind submitting a patch to put this in the languages/pirate
I'd appreciate that very much. Pie-thon, here we come ...
As would I. If you're willing, Michal, we can check it in and get you
CVS repository
On Fri, 1 Aug 2003, Dan Sugalski wrote:
At 11:04 PM +0200 7/31/03, Leopold Toetsch wrote:
Luke Palmer [EMAIL PROTECTED] wrote:
You mind submitting a patch to put this in the languages/pirate
I'd appreciate that very much. Pie-thon, here we come ...
As would I. If you're willing, Michal,
Hey all,
I'm trying to get functions working
in python, and I'm not sure the best way
to do this.
What seems natural to me is to define
subroutines in the middle of the code
as I walk the parse tree:
.sub __main__
goto endsub
.sub _f
print :(\n
ret
.end
endsub
Michal Wallace:
I can store all my subroutine definitions in
a list or something and then dump them out
after the __main__ routine. Is that the
right approach? It seems strange to me,
but I'm new at this.
That seems to be the way to do it, speaking as someone who's working on a
Perl 5-to-PIL
Michal Wallace wrote:
Hey all,
What seems natural to me is to define
subroutines in the middle of the code
as I walk the parse tree:
You can do that:
.sub __main__
bsr _main
end
.end
.sub _main
.sub _f
print :)\n
ret
.end
.sub _g
print ;-)\n
ret
Hey all,
I'm trying to get functions working
in python, and I'm not sure the best way
to do this.
What seems natural to me is to define
subroutines in the middle of the code
as I walk the parse tree:
.sub __main__
goto endsub
.sub _f
print :(\n
ret
On Thu, 31 Jul 2003, Leopold Toetsch wrote:
You can do that:
.sub __main__
bsr _main
end
.end
.sub _main
...
So you have just to emit code, to call your real main at the beginning.
Well that worked, and even let me get rid of the
endsub label:
.sub __start__
call __main__
On Thu, 31 Jul 2003, Brent Royal-Gordon wrote:
Michal Wallace:
I can store all my subroutine definitions in
a list or something and then dump them out
after the __main__ routine.
That seems to be the way to do it, speaking as someone who's working
on a Perl 5-to-PIL converter (using the
On 31 Jul 2003, Luke Palmer wrote:
It now runs amk's euclid.py perfectly now.
Do we have a way to compare the speed vs python? :)
We just modify it to repeat 100,000 times or so, and compare that way.
Oh, duh. :)
Which I did. Parrot comes in about 3x slower than python on euclid.
From
One of my questions is, why do you make so many PerlNums when there
isn't a trace of a floating point number to be found...?
Because I didn't read the docs that said PerlNum means float. :)
I'll switch it to PerlInt (or maybe int?) later...
Yeah, all your auxillary data; i.e. the flags
Michal Wallace [EMAIL PROTECTED] wrote:
.sub __start__
call __main__
.end
.sub __main__
.sub _f
print :)
ret
.end
$I0 = addr _f
print $I0
end
.end
That prints :), followed by the address,
No, can't imagine that:
$ parrot -o- pirate.imc
__start__:
Luke Palmer [EMAIL PROTECTED] wrote:
You mind submitting a patch to put this in the languages/pirate
I'd appreciate that very much. Pie-thon, here we come ...
Luke
leo
At 02:54 PM 7/31/2003 -0400, Michal Wallace wrote:
Actually, between imcc and the python compiler
module, it's not nearly as hard as I thought it
would be. So far, I think the parrot version is
actually a lot simpler than the python compiler,
just because imcc is doing so much of the work.
Leo and
At 01:51 PM 7/31/2003 -0600, Luke Palmer wrote:
You mind submitting a patch to put this in the languages/pirate
directory of the parrot distro? I'd like to stay up to date, and
probably do some work (as, I imagine, would others).
I'd like to officially complain that pirate is a cooler name than
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #22745]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22745
Attached is a first try to unify the various sub types, structures and
classes.
The patch looks pretty good to me. Here is a proposal for an alternative
inheritance hierarchy. Invocable, the root of the hierarchy, is basically a
sub that is not a closure (i.e. *no* context at all, just an address).
pmclass Invocable { # I called this sublite before
/* SELF-data is always
All~
Jonathan Sillito wrote:
The patch looks pretty good to me. Here is a proposal for an alternative
inheritance hierarchy. Invocable, the root of the hierarchy, is basically a
sub that is not a closure (i.e. *no* context at all, just an address).
pmclass Invocable { # I called this sublite
On Thu, 2002-04-25 at 18:14, Dan Sugalski wrote:
Okay, fair enough. Subs in general will have the following potential
information:
*) A pointer to a template lexical scratchpad
*) A pointer to a *real* scratchpad (for co-routines and continuations)
*) A pointer to a parent lexical
Andrew J Bromage [EMAIL PROTECTED] writes:
G'day all.
On Mon, Apr 29, 2002 at 11:59:45PM +0100, Tim Bunce wrote:
[ I'm playing devils advocate for a while longer as I'm not 100% convinced ]
Understood.
Isn't compiler convienience a (the?) major issue here?
I wouldn't call it a major
I'd have to agree with Andrew. With only 32 registers of each type in
Parrot (the last time I checked) using most of them for function arguments
would cause much needless register copying within each function.
Surely 8 registers of each type would be more than sufficient for
function
subroutines... And in the case of non trivial subs then the register
saving overhead will be the same whereever it happens. The precise
breakdown will be different, but I claim that the average case will
stay roughly the same.
There's got to be a reason for making caller-save the default, but I
Actually, I _was_ saying we shouldn't do caller-save (except
possibly for a small number of registers designated for the
purpose).
Remember that the caller only has to save the stuff that is important
to it, after all, anything that might be of importance to *its*
callers will already
every
time someone does a CPAN upgrade.
Of course the ultimate solution is the old MIPS register allocation
at link time approach, but I assume that for a dynamic language like
Perl this is a bad idea. :-)
Well factored code tends to have plenty of small, trivial
subroutines... And in the case
At 9:50 AM +1000 4/29/02, Andrew J Bromage wrote:
G'day all.
On Sun, Apr 28, 2002 at 11:44:04AM -0400, Dan Sugalski wrote:
We're going caller-save. I think I made this declaration before, but
now it's backed up with pure PDD goodness. :)
The first thing to realise is that this violates
PROTECTED] To: Andrew J Bromage
[EMAIL PROTECTED], [EMAIL PROTECTED]
cc:
04/29/2002 10:53 Subject: Re: Subroutines
OO code is full of subs which a) are called very often and b) look
like this:
sub code
{
my $self = shift;
return $self-{CODE};
}
sub body
{
my $self = shift;
if (_) {
$self-{BODY} = shift;
}
[ I'm playing devils advocate for a while longer as I'm not 100% convinced ]
On Mon, Apr 29, 2002 at 10:53:40AM -0400, Dan Sugalski wrote:
At 9:50 AM +1000 4/29/02, Andrew J Bromage wrote:
G'day all.
On Sun, Apr 28, 2002 at 11:44:04AM -0400, Dan Sugalski wrote:
We're going
G'day all.
On Mon, Apr 29, 2002 at 11:59:45PM +0100, Tim Bunce wrote:
[ I'm playing devils advocate for a while longer as I'm not 100% convinced ]
Understood.
Isn't compiler convienience a (the?) major issue here?
I wouldn't call it a major issue. I think of it as a constraint.
The major
At 7:00 AM +0100 4/27/02, Piers Cawley wrote:
Andrew J Bromage [EMAIL PROTECTED] writes:
G'day all.
On Fri, Apr 26, 2002 at 08:16:27AM -0400, Melvin Smith wrote:
I also vote for reserving some caller-save registers to make
arg passing faster, however, reserving 16 is probably useless,
G'day all.
On Sat, Apr 27, 2002 at 07:00:17AM +0100, Piers Cawley wrote:
I'm trying to see how, if you want genuine continuations and/or tail
call optimization, you're going to get away with anything but 'caller
saves everything important to it', and what do you know, I
can't.
If you have
G'day all.
On Sun, Apr 28, 2002 at 11:44:04AM -0400, Dan Sugalski wrote:
We're going caller-save. I think I made this declaration before, but
now it's backed up with pure PDD goodness. :)
The first thing to realise is that this violates the principle of
callee does everything important to
At 11:44 AM 4/28/2002 -0400, Dan Sugalski wrote:
At 7:00 AM +0100 4/27/02, Piers Cawley wrote:
Andrew J Bromage [EMAIL PROTECTED] writes:
G'day all.
On Fri, Apr 26, 2002 at 08:16:27AM -0400, Melvin Smith wrote:
I also vote for reserving some caller-save registers to make
arg passing
G'day all.
On Sun, Apr 28, 2002 at 09:49:35PM -0400, Melvin Smith wrote:
I don't think I and Andrew were saying we shouldn't do caller-save, we
were just discussing that the calling convention (read activation record of
a subroutine) should support the common optimization of passing args
in
At 12:09 PM 4/29/2002 +1000, Andrew J Bromage wrote:
G'day all.
On Sun, Apr 28, 2002 at 09:49:35PM -0400, Melvin Smith wrote:
I don't think I and Andrew were saying we shouldn't do caller-save, we
were just discussing that the calling convention (read activation record of
a subroutine)
G'day all.
On Sun, Apr 28, 2002 at 10:26:12PM -0400, Melvin Smith wrote:
Ok, agreed. Sorry for speaking for you.
Not a problem. Having people try to speak for you can actually
clarify your thoughts, or so I've found.
Regarding performance, a decent compiler should be able to
analyze a
]To: [EMAIL PROTECTED]
rg cc:
Subject: Re: Subroutines
G'day all.
On Fri, Apr 26, 2002 at 08:16:27AM -0400, Melvin Smith wrote:
I also vote for reserving some caller-save registers to make
arg passing faster, however, reserving 16 is probably useless, except
for symmetry.
I think most texts agree that 5 or so are about all you need.
Fair
On Mon, Apr 22, 2002 at 01:52:30PM -0700, Brent Dax wrote:
How about we instead declare that all subs have One True Entry Point,
and the sub does whatever is needed there? Normal subs can just set up
scoping and jump to the beginning of the sub's body; coroutines retrieve
their context
At 4:42 PM -0700 4/22/02, Steve Fink wrote:
On Tue, Apr 23, 2002 at 09:28:29AM +1000, Andrew J Bromage wrote:
G'day all.
On Mon, Apr 22, 2002 at 04:31:32PM -0400, Dan Sugalski wrote:
3) We're having a new rule--you may *not* take a continuation from
within an opcode function! This is
At 10:03 AM -0500 4/25/02, Fisher Mark wrote:
I've no strong opinions on how it's done, but I do believe that
it's *very* important that subroutine calls be as fast as possible
(and significantly faster than perl5). This must be a priority.
To my mind that means that a subroutine should
G'day all.
On Mon, Apr 22, 2002 at 01:52:30PM -0700, Brent Dax wrote:
How about we instead declare that all subs have One True Entry Point,
and the sub does whatever is needed there? Normal subs can just set up
scoping and jump to the beginning of the sub's body; coroutines retrieve
Okay, I've been thinking about subroutines lately. A lot. I had
planned on putting them off a bit until we'd gotten scratchpads and
globals done, but I thin I'd as soon get this off for discussion, so
maybe we can have the rough edges worked out by the time we have
hashes.
Subroutines
Dan Sugalski:
# Okay, I've been thinking about subroutines lately. A lot. I had
# planned on putting them off a bit until we'd gotten scratchpads and
# globals done, but I thin I'd as soon get this off for discussion, so
# maybe we can have the rough edges worked out by the time we have
G'day all.
On Mon, Apr 22, 2002 at 04:31:32PM -0400, Dan Sugalski wrote:
3) We're having a new rule--you may *not* take a continuation from
within an opcode function! This is probably one of those Well, Duh!
things but better to have it up front.
I see why you say this, but I'm not sure
On Tue, Apr 23, 2002 at 09:28:29AM +1000, Andrew J Bromage wrote:
G'day all.
On Mon, Apr 22, 2002 at 04:31:32PM -0400, Dan Sugalski wrote:
3) We're having a new rule--you may *not* take a continuation from
within an opcode function! This is probably one of those Well, Duh!
things
the various tools.
* Jako compiler has more explanatory comments and the following
new features:
* Lexically scoped variables.
* Subroutines that take arguments and return values:
sub int foo(int bar) {
if (bar == 1
97 matches
Mail list logo
