On Wed 12 Mar, Michael Lazzaro wrote:
>
> On Tuesday, March 11, 2003, at 12:39 PM, Austin Hastings wrote:
> > You want C to tell the compiler to build in multiple dispatch.
> > Any invocation of C after C is going to be a penny
> > dropped into the great Pachinko game of multimethod-dispatchery.
John Siracusa wrote:
From A6:
I worry that generalized wrappers will make it impossible to compile fast
subroutine calls, if we always have to allow for run-time insertion of
handlers. Of course, that's no slower than Perl 5, but we'd like to do better
than Perl 5. Perhaps we can have the default
Austin Hastings wrote:
You're treading dangerously close to the S&M line there...
Sure. That's exactly what types are for.
Does it make sense to say C for this stuff?
I'd much rather that simply using typed params invoked type stricture.
Damian
So now putting C-style comments in p6 should be about as easy as
macro circumfix:/*...*/ () is parsed(/.*?/) { "" }
Yep.
But just to make sure I'm getting it:
macro circumfix:... () is parsed(/.*?/) {
"\n# much ranting deleted here . . . .\n"
}
will actually work? :)
Yes. Though you
> I don't know that that means we couldn't have an C
> spelling, though. And C (or something easier to spell)
> for the * case. If we have C and C, I think
> it would be appropriate to have names for the other linenoise as
well.
I'd say "please".
> (Percentage of me that really cares: 20%.
John Williams wrote:
Have you considered:
LIST ==> @var.operator:=
LIST ==> @var.STOREARRAY
LIST ==> @var.how_do_i_spell_the_assignment_method
That's probably:
LIST ==> @var.STORE(*);
which is still pretty darn ugly. ;-)
Damian
Michael Lazzaro asked:
Are you concerned about having an C spelling at all
No, not at all. It really is a shorthand for a trait, after all, so it should
almost certainly have a trait name. Besides, C is probably needed
for non-parameter variables too:
my %nickname is default("Bruce") = (
Joe Gottman wrote:
Will it be possible in perl6 to overload multis on the const-ness of a
parameter, like C++ does? For instance,
multi getX(Foo $self:) returns Int {...} #const version
multi getX(Foo $self: is rw) returns Int is rw {...} #non-const version
That second one would have to
On Tuesday, March 11, 2003, at 12:39 PM, Austin Hastings wrote:
You want C to tell the compiler to build in multiple dispatch.
Any invocation of C after C is going to be a penny
dropped into the great Pachinko game of multimethod-dispatchery. By
default, if no winning multi appears, the call falls
Will it be possible in perl6 to overload multis on the const-ness of a
parameter, like C++ does? For instance,
multi getX(Foo $self:) returns Int {...} #const version
multi getX(Foo $self: is rw) returns Int is rw {...} #non-const version
If getX were called on a const Foo object the
On Tuesday, March 11, 2003, at 05:18 PM, Damian Conway wrote:
Various folks have suggested that the default assignment syntax:
sub foo(?$bar is copy = 1) {...}
be considered merely a shorthand for something like:
sub foo(?$bar is copy is default(1)) {...}
I don't know...maybe I'm worry
The effect of a macro is lexical; but "the name may be installed in
either a package or a lexical scope". If the name is installed in a
class, can it be invoked via a variable of that class?
Example (SQL query integrated via macro):
my Database $db = MySqlDatabase.connect(...);
$db.select *
Various folks have suggested that the default assignment syntax:
sub foo(?$bar is copy = 1) {...}
be considered merely a shorthand for something like:
sub foo(?$bar is copy is default(1)) {...}
thereby allowing:
sub foo(?$bar is default(1) is copy ) {...}
and hence (mirabile dictu
On Tue, 11 Mar 2003, Damian Conway wrote:
>
> These are basically all just two edge-cases. Namely:
>
> @var <== LIST
> and:
> LIST ==> @var
>
Have you considered:
LIST ==> @var.operator:=
LIST ==> @var.STOREARRAY
LIST ==> @var.how_do_i_spell_the_assignment_method
?
Richard Proctor asked:
> If one has a simple sub such as factorial:
>
> sub factorial(int $a) {...}
>
> then one subsequently declares the multi form of factorial to pick up the
> non-integer form:
>
> multi factorial(num $a) {...}
>
> Does this promote the original declaration of factorial to a m
>From A6:
> I worry that generalized wrappers will make it impossible to compile fast
> subroutine calls, if we always have to allow for run-time insertion of
> handlers. Of course, that's no slower than Perl 5, but we'd like to do better
> than Perl 5. Perhaps we can have the default be to have wr
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> On Tuesday, March 11, 2003, at 11:19 AM, Austin Hastings wrote:
> > But you can't wrap multi-ness, as far as I can tell.
> >
> > [A6]
> > And it happens that the multimethod dispatch is smart enough to
> find
> > the ordinary single-invocant sys
On Tuesday, March 11, 2003, at 11:19 AM, Austin Hastings wrote:
But you can't wrap multi-ness, as far as I can tell.
[A6]
And it happens that the multimethod dispatch is smart enough to find
the ordinary single-invocant sysread method, even though it may not
have been explicitly declared a multim
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> On Tuesday, March 11, 2003, at 06:42 AM, Richard Proctor wrote:
> > If one has a simple sub such as factorial:
> >
> > sub factorial(int $a) {...}
> >
> > then one subsequently declares the multi form of factorial to pick
> up
> > the
> > non-inte
On Tuesday, March 11, 2003, at 06:42 AM, Richard Proctor wrote:
If one has a simple sub such as factorial:
sub factorial(int $a) {...}
then one subsequently declares the multi form of factorial to pick up
the
non-integer form:
multi factorial(num $a) {...}
Does this promote the original decla
On Tuesday, March 11, 2003, at 08:41 AM, Brent Dax wrote:
Almost makes you wish for those backwards declarations from C that
computer scientists always gripe about, eh? :^) Well, what about
this?
multi substr(Str $str, $from = $CALLER::_ is optional, $len =
Inf is optional, $new is optional)
Larry wrote:
: > multi foo (@a is Array of int) {...}
: >
: > my int @a = baz(); # is Array of int
: > my @b = baz(); # is Array of Scalar
: >
: > foo(@a);# @a is typed correctly, so OK
: > foo(@b);# @b is not explicitly typed as C; OK or FAIL?
I dunno. I can argue that i
--- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Piers Cawley wrote:
> > Coroutines end and DFG
> > Nobody explained what DFG stands for.
>
> It's a commonly used TLA standing for Data Flow Graph, which
> accompanies the CFG (Control Flow Graph). Both are necessary
> for register allocation
Simon Cozens:
# [EMAIL PROTECTED] (Luke Palmer) writes:
# > we have a definitive
# ^^
# Remember that this is Perl 6. You keep using that word, etc.
It *is* definitive, Simon...at least this week. ;^)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regex
Damian Conway:
# Brent Dax wrote:
#
# > method x ($me: $req, ?$opt, +$namedop, *%named, [EMAIL PROTECTED]) { ... }
# >
# > Yikes. And I thought we were trying to get *away* from
# line noise?
# > :^)
# >
# > Seriously, can't we use something rather prettier, like this?
# >
# > metho
Piers Cawley wrote:
Coroutines end and DFG
Nobody explained what DFG stands for.
It's a commonly used TLA standing for Data Flow Graph, which accompanies
the CFG (Control Flow Graph). Both are necessary for register allocation.
leo
Oh goody, two with one blow:
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Larry wrote:
>
> > : > multi foo (@a is Array of int) {...}
> > : >
> > : > my int @a = baz(); # is Array of int
> > : > my @b = baz(); # is Array of Scalar
> > : >
> > : > foo(@a);# @a is typed correc
Will infix operators be allowed to be macros instead of subs?
They'd be kinda necessary for infix operators for which standard sub
conventions are insufficient and need to diddle the parse tree instead,
such as short-circuiting operators.
It would also allow Damien's original <~ operator (R2L m
So now putting C-style comments in p6 should be about as easy as
macro circumfix:/*...*/ () is parsed(/.*?/) { "" }
That's so easy I might even *use* it, lol
Not that I've ever really felt the need with # and =doc/=cut.
But just to make sure I'm getting it:
macro circumfix:... () is pa
> The problem is that if you have multiple optional or named
> parameters, things start getting uncomfortably prolix, and default
> values end up a long way from their owners:
>
> multi substr(Str $str, $from is optional = $CALLER::_,
> $len is optional = Inf, $new is optional) {...
If one has a simple sub such as factorial:
sub factorial(int $a) {...}
then one subsequently declares the multi form of factorial to pick up the
non-integer form:
multi factorial(num $a) {...}
Does this promote the original declaration of factorial to a multi?
if not what happens?
Richard
-
--- Brent Dax <[EMAIL PROTECTED]> wrote:
> method x ($me: $req, ?$opt, +$namedop, *%named, [EMAIL PROTECTED]) { ... }
>
> Yikes. And I thought we were trying to get *away* from line noise?
>
> Seriously, can't we use something rather prettier, like this?
>
> method x($me: $req, $o
=head1 C and Continuations
Here's another "blend known paradigms" document from Luke. The idea
is to rethink C to provide even more information than it
already does, in an elegant way. To get us started:
As in Perl 5, the C function will return information about
the dynamic context of t
The Perl 6 Summary for the week ending 20030309
Ooh look, it's another of those Perl 6 Summaries where Piers tries to
work a gratuitous reference to Leon Brocard into a summary of what's
been happening to the Perl 6 development process this week.
As tradition dictates, we'll start
[EMAIL PROTECTED] (Luke Palmer) writes:
> we have a definitive
^^
Remember that this is Perl 6. You keep using that word, etc.
--
void russian_roulette(void) { char *target; strcpy(target, "bullet"); }
35 matches
Mail list logo
