Larry Wall wrote:
On Fri, Jul 08, 2005 at 03:17:42PM -0400, Chip Salzenberg wrote:
: foo('a' => 1) <== ('b' => 2, ...)
[ ... ]
Plus it settles the whole issue of what to do with multiple pipes into
the same function. But I don't think Parrot has to worry about that,
Thanks. Again. I
On Fri, Jul 08, 2005 at 03:17:42PM -0400, Chip Salzenberg wrote:
: Larry on p6i? I didn't expect some kind of Perlish Exposition!
Hey, I'm the chief Lurky Turkey around here...
: Incidentally, under the "appropriate amount of fun" topic: An
: interesting Parrot/Perl6 intersection problem with na
Larry on p6i? I didn't expect some kind of Perlish Exposition!
On Fri, Jul 08, 2005 at 11:18:01AM -0700, Larry Wall wrote:
> Even in the absence of a hash representation, the brute force approach
> will often beat the finessed approach for a small number of arguments,
Well-taken. (Not that the
On Fri, Jul 08, 2005 at 11:13:27AM -0400, Chip Salzenberg wrote:
: Tt makes sense to scan the pairs containing named arguments by
: iterating through the list of pairs (if any), not by iterating through
: the parameters and doing a sequential scan for an appropriately named
: pair for each one.
Ac
On Fri, Jul 08, 2005 at 03:58:50PM +0200, Leopold Toetsch wrote:
> This needs more parsing rules in imcc.y so it's not (yet) implemented.
Grammar changes shouldn't be such an issue. It's just yacc.
> But I've now implemented :opt_count ...
>.param pmc p1 :optional
>.param pmc p2 :optio
On Fri, Jul 08, 2005 at 03:58:50PM +0200, Leopold Toetsch wrote:
> Chip Salzenberg wrote:
> >Thus, this is probably better:
> >
> > .sub "foo"
> > .param int beta
> > .param string gamma :optional(have_gamma)
> > .param string delta :optional(have_delta)
>
> This nee
Chip Salzenberg wrote:
And I just realized my proposal fails to address something important.
But I'm not entirely sure it's Parrot's job to do the important thing
in question. Still, the possibility exists. Thus:
On Thu, Jul 07, 2005 at 12:02:40PM -0400, Chip Salzenberg wrote:
.sub "foo"
On Jul 7, 2005, at 18:02, Chip Salzenberg wrote:
Say a new bit
":opt_count", which means that the given register should be assigned
the count?
.sub "foo"
.param int beta
.param string gamma :optional
.param string delta :optional
.param int optc :opt_co
On Thu, Jul 07, 2005 at 12:11:53PM -0400, Chip Salzenberg wrote:
> Thus, this is probably better:
>
> .sub "foo"
> .param int beta
> .param string gamma :optional(have_gamma)
> .param string delta :optional(have_delta)
> .param pmc epsilon :slurpy
As y
And I just realized my proposal fails to address something important.
But I'm not entirely sure it's Parrot's job to do the important thing
in question. Still, the possibility exists. Thus:
On Thu, Jul 07, 2005 at 12:02:40PM -0400, Chip Salzenberg wrote:
> .sub "foo"
> .param int b
On Thu, Jul 07, 2005 at 12:02:40PM -0400, Chip Salzenberg wrote:
> On Thu, Jul 07, 2005 at 10:43:45AM -0500, Patrick R. Michaud wrote:
> > With something like
> >
> > .sub "foo"
> > .param int beta
> > .param string gamma :optional
> > .param string delta :optional
> >
Patrick R. Michaud wrote:
... get_argc (which perhaps should be called something
else)
Better names are welcome.
So, all we really need is something that can tell us how many :optional
arguments were filled in.
Sounds reasonable.
op optional_count(out INT)
Another question: do we want
On Thu, Jul 07, 2005 at 10:43:45AM -0500, Patrick R. Michaud wrote:
> With something like
>
> .sub "foo"
> .param int beta
> .param string gamma :optional
> .param string delta :optional
> .param pmc epislon :slurpy
>
> So, all we really need is something that
On Thu, Jul 07, 2005 at 10:43:45AM -0500, Patrick R. Michaud wrote:
> In fact, this might be greatly preferable, since if
> I later decide I need another non-optional parameter
>
> .sub "foo"
> .param int beta
> .param int omega
> .param string gamma :optional
>
On Thu, Jul 07, 2005 at 11:22:27AM -0400, Chip Salzenberg wrote:
> On Thu, Jul 07, 2005 at 10:09:27AM -0500, Patrick R. Michaud wrote:
> > On Thu, Jul 07, 2005 at 11:05:00AM -0400, Chip Salzenberg wrote:
> > > On Thu, Jul 07, 2005 at 10:57:40AM -0400, Will Coleda wrote:
> > > > To manage varargs-st
Chip Salzenberg wrote:
On Thu, Jul 07, 2005 at 03:36:01PM +0200, Leopold Toetsch wrote:
Instead we have the new opcode:
get_argc(out INT)
which returns the argument/result count of the recent call/return.
Why do we need this?
To know, if :optional args where passed in or not.
leo
On Thu, Jul 07, 2005 at 10:09:27AM -0500, Patrick R. Michaud wrote:
> On Thu, Jul 07, 2005 at 11:05:00AM -0400, Chip Salzenberg wrote:
> > On Thu, Jul 07, 2005 at 10:57:40AM -0400, Will Coleda wrote:
> > > To manage varargs-style subroutines?
> >
> > But that's what :slurpy is for.
>
> But :slurp
On Thu, Jul 07, 2005 at 11:05:00AM -0400, Chip Salzenberg wrote:
> On Thu, Jul 07, 2005 at 10:57:40AM -0400, Will Coleda wrote:
> > To manage varargs-style subroutines?
>
> But that's what :slurpy is for.
But :slurpy always pulls things into a PMC (and creates PMCs
along the way).
We need get_ar
On Thu, Jul 07, 2005 at 10:57:40AM -0400, Will Coleda wrote:
> To manage varargs-style subroutines?
But that's what :slurpy is for.
--
Chip Salzenberg <[EMAIL PROTECTED]>
To manage varargs-style subroutines?
On Jul 7, 2005, at 10:55 AM, Chip Salzenberg wrote:
On Thu, Jul 07, 2005 at 03:36:01PM +0200, Leopold Toetsch wrote:
Instead we have the new opcode:
get_argc(out INT)
which returns the argument/result count of the recent call/return.
Why do we n
On Thu, Jul 07, 2005 at 03:36:01PM +0200, Leopold Toetsch wrote:
> Instead we have the new opcode:
> get_argc(out INT)
> which returns the argument/result count of the recent call/return.
Why do we need this?
--
Chip Salzenberg <[EMAIL PROTECTED]>
On Thu, Jul 07, 2005 at 03:36:01PM +0200, Leopold Toetsch wrote:
> I've now implement full type conversions, thus making argument passing
> strictly positional. This also implies that we don't need separate
> argument counts per register type, these are gone now.
>
> Instead we have the new opco
I've now implement full type conversions, thus making argument passing
strictly positional. This also implies that we don't need separate
argument counts per register type, these are gone now.
Instead we have the new opcode:
get_argc(out INT)
which returns the argument/result count of the r
23 matches
Mail list logo