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 willin
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
- 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 li
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 li
- 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
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 comp
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
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
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
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- pir
> > 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. th
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.
>
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
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
> 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"
>
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"
r
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-
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 sc
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 cal
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 ma
G'day all.
On Mon, Apr 29, 2002 at 10:53:40AM -0400, Dan Sugalski wrote:
> Welcome to my world. They're all bad ideas in some way or, rather,
> they're all equally as good.
That's definitely true. :-)
I should also point out that for Perl, all this is moot. Current Perl
semantics require tha
[ 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
>>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} =
At 11:05 AM -0400 4/29/02, Melvin Smith wrote:
> >Just for chuckles, I went and benchmarked things, as meaningless
>>numbers are useful to have. With my current GCC3/-O3 build of parrot,
>>the cost to do 10,000,000 sets of saves is as follows:
>>
>>save all: 5.3 sec usertime
>>save 1: 2.6 sec
AIL PROTECTED]> To: Andrew J Bromage
<[EMAIL PROTECTED]>, [EMAIL PROTECTED]
cc:
04/29/2002 10:53 Subject: Re:
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 vi
G'day all.
On Mon, Apr 29, 2002 at 07:57:08AM +0100, Piers Cawley wrote:
> 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 have been saved. If the callee saves then it's
> going to be d
> > 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
Andrew J Bromage <[EMAIL PROTECTED]> writes:
> 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) s
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 paramet
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 m
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 subro
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
>
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
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 t
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 ha
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 p
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, except
>> for symmetry.
>>
>> I think mo
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
TED]To: [EMAIL PROTECTED]
rg> cc:
Subject: Re: Subro
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
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 subrouti
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 func
> 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 be responsible for
> setting up whatever _it_
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
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!"
>
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 su
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
# hash
> If the C modifier is used for a particular parameter, that parameter
> is lazily evaluated. This means that it is only evaluated when the
> corresponding named parameter (see below) -- or the corresponding element
> of @_ -- is accessed in some way. Passing the parameter to another
> subroutine
Say we allow instantly tied lazy subroutine definitions
like so:
@naturals = (? { my $x=1; yield $x++ while 1 })
Is the code block in there a subroutine or a method?
And why?
How about using the eminently deprecatable "reset" operator
to start a tied lazy array back at it's "original"
50 matches
Mail list logo
