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
22 matches
Mail list logo
