> - Original Message -
> From: "Damian Conway" <[EMAIL PROTECTED]>
> To: "Perl6" <[EMAIL PROTECTED]>
> Sent: Tuesday, March 11, 2003 9:35 PM
> Subject: Re: A6: overloading multis on constness of parameters
>
>
> > Joe Gottman wrote:
> >
> > >Will it be possible in perl6 to overload mu
- Original Message -
From: "Damian Conway" <[EMAIL PROTECTED]>
To: "Perl6" <[EMAIL PROTECTED]>
Sent: Tuesday, March 11, 2003 9:35 PM
Subject: Re: A6: overloading multis on constness of parameters
> Joe Gottman wrote:
>
> >Will it be possible in perl6 to overload multis on the const-n
Brent Dax wrote:
Dave Whipp:
# But you're right, there are situations where the (base) type
# might not
# be knowable: and these could result in syntax errors.
Except they wouldn't, at least not always.
[snip]
The only part of that I'm not sure about is infix:LIKE, since such an
operator hasn't
Dave Whipp:
# But you're right, there are situations where the (base) type
# might not
# be knowable: and these could result in syntax errors.
Except they wouldn't, at least not always.
$db.select * FROM Foo WHERE Foo.bar LIKE a%b;
$db.select() *
FROM(
Luke Palmer wrote:
I'm not quite sure I follow you (I'm not familiar with that pattern).
But the macromethod I imagine is the non-polymorphic one, and the one
it expands to is the polymorphic one, if I'm guessing correctly. And
you certianly could do that.
yes: http://patterndigest.com/patterns/Te
On Wed, Mar 12, 2003 at 03:35:58PM -0800, Dave Whipp wrote:
: Larry Wall replied:
: >: my Database $db = MySqlDatabase.connect(...);
: >: $db.select * FROM Foo WHERE Foo.bar LIKE a%b;
:
: >To answer your actual question, you either need to have some keyword out
: >front to start the alternate
On Wednesday, March 12, 2003, at 05:03 PM, Deborah Ariel Pickett wrote:
Sort of a rehash on an old topic, but there's new stuff now with A6.
Mike Lazarro had been making a list of all the operators that Perl6
has.
The latest version I could find was Take 6 (at
http://archive.develooper.com/[EMAI
> Luke Palmer wrote:
>
> > Well, if you did that, it surely couldn't be polymorphic, which kind
> > of defeats most of the purpose of making it a method.
>
> I disagree. Consider the "template method" patten. This uses a
> non-polymorphic method in a base class to invoke a set of polymorphic
>
Sort of a rehash on an old topic, but there's new stuff now with A6.
Mike Lazarro had been making a list of all the operators that Perl6 has.
The latest version I could find was Take 6 (at
http://archive.develooper.com/[EMAIL PROTECTED]/msg12130.html).
So, my questions:
1. Is there a more recent
Luke Palmer wrote:
Well, if you did that, it surely couldn't be polymorphic, which kind
of defeats most of the purpose of making it a method.
I disagree. Consider the "template method" patten. This uses a
non-polymorphic method in a base class to invoke a set of polymorphic
methods in a standar
Dave Whipp wrote:
> (OK, thats not a good example, but you get the gist). If sure it would
> be possible to write the macro in such a way that it looks at its LHS
> arg -- and ignores itself if its not a Database object ... but that
> places an overly large burden on the macro writer. To avoid
Damian Conway <[EMAIL PROTECTED]> writes:
> 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) {.
Michael Lazzaro <[EMAIL PROTECTED]> writes:
> On Wednesday, March 12, 2003, at 11:14 AM, Damian Conway wrote:
>> Larry wrote:
>>
>>> : I agree. As long as it's not C!
>>> Of course not. We're trying to encourage the use of line noise,
>>> and discourage the use of the long variants, so the long
"Joe Gottman" <[EMAIL PROTECTED]> writes:
>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 versi
Larry Wall replied:
: my Database $db = MySqlDatabase.connect(...);
: $db.select * FROM Foo WHERE Foo.bar LIKE a%b;
To answer your actual question, you either need to have some keyword out
front to start the alternate parsing, or you need to treat ".select"
as an infix macro that has an ordina
Austin Hastings wrote:
But what's the vision for p6?
My expectation is that the type-checking stuff will be heavily used
for:
1- Large scale projects.
2- CPAN modules.
3- speed
When you are not on perl one liners, but maybe some inner tight loops of
some algorithm or whatever, where speed d
--- "Mark J. Reed" <[EMAIL PROTECTED]> wrote:
> On 2003-03-13 at 05:44:09, Damian Conway wrote:
> > >2- Yeah! ... umm, are we *paying* you for this?
> >
> > Not any more. In fact, like Larry and several others on the design
> team,
> > I'm now paying for the privilege of doing it. ;-)
> If the T
On 2003-03-13 at 05:44:09, Damian Conway wrote:
> >2- Yeah! ... umm, are we *paying* you for this?
>
> Not any more. In fact, like Larry and several others on the design team,
> I'm now paying for the privilege of doing it. ;-)
If the TPF isn't supporting you folks anymore, what's the best
way fo
> Agreed. It should do compile-time verification, not runtime.
>
> That said, I still think there *might* be something to be said for
> compile-time 'hints' for explicitly _untyped_ values.
Perhaps there should be a distinction between "untyped" and "Object".
Something that is explicitly an O
I think the issue of type coercion (forcing one type to another) should
be decided separately from the issue of "implicit" types (recognizing
when an untyped variable can be KNOWN at a given point to hold a
specific type, even if it isn't explicitly stated.)
As far as true coercion goes: for th
On Wednesday, March 12, 2003, at 11:07 AM, Damian Conway wrote:
Austin Hastings wrote:
In this case, I rather like the idea of being able to say
sub foo(@a is Array of Int) {...}
my @input = read_a_bunch_o_data();
foo(@input);
Where the compiler will automatically "wrap" the @input array
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Larry wrote:
>
> > : I agree. As long as it's not C!
> >
> > Of course not. We're trying to encourage the use of line noise,
> > and discourage the use of the long variants, so the long one would
> > have to be C.
>
> Riiight! Thank-you, G
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Austin Hastings wrote:
>
> > In this case, I rather like the idea of being able to say
> >
> >sub foo(@a is Array of Int) {...}
> >
> >my @input = read_a_bunch_o_data();
> >foo(@input);
> >
> >
> > Where the compiler will automaticall
Austin Hastings wrote:
But this isn't really a cognitive dissonance,
I think it is. Constructs that mean two different things in two different
contexts are always dissonances. Mind you, humans are normally quite good at
coping with that kind of contextually sensitive dissonance. Right up to the
Larry wrote:
: Can we get a final answer, for the (documented) record?
No. I have to wait till Damian isn't looking.
Ah, so it's *never* going to be revealed?
;-)
Damian
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Austin Hastings wrote:
>
> >>The design team has already considered this idea, and my problem
> >>with it then (and now) is that it's inconsistent with other forms
> >>of variable declaration:
> >>
> >> my sub foo( ?$bar is constant = 1 ) {..
On Wed, Mar 12, 2003 at 11:23:56AM -0800, Michael Lazzaro wrote:
: On Wednesday, March 12, 2003, at 11:14 AM, Damian Conway wrote:
: >Larry wrote:
: >
: >>: I agree. As long as it's not C!
: >>Of course not. We're trying to encourage the use of line noise,
: >>and discourage the use of the long v
On Wednesday, March 12, 2003, at 11:14 AM, Damian Conway wrote:
Larry wrote:
: I agree. As long as it's not C!
Of course not. We're trying to encourage the use of line noise,
and discourage the use of the long variants, so the long one would
have to be C.
Riiight! Thank-you, General Haig
Larry wrote:
: I agree. As long as it's not C!
Of course not. We're trying to encourage the use of line noise,
and discourage the use of the long variants, so the long one would
have to be C.
Riiight! Thank-you, General Haig.
Of course, C (my own preference for the name of this trait) w
Austin Hastings wrote:
In this case, I rather like the idea of being able to say
sub foo(@a is Array of Int) {...}
my @input = read_a_bunch_o_data();
foo(@input);
Where the compiler will automatically "wrap" the @input array in a
make-it-an-int converter. This, to me, is DWIM.
But to ma
On Wed, Mar 12, 2003 at 10:04:47AM -0500, John Siracusa wrote:
: On 3/12/03 1:50 AM, Mark Biggar wrote:
: > 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
On Tue, Mar 11, 2003 at 05:35:34PM -0800, Dave Whipp wrote:
: 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 m
On Tue, Mar 11, 2003 at 05:35:34PM -0800, Dave Whipp wrote:
: 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 m
Austin Hastings wrote:
The design team has already considered this idea, and my problem
with it then (and now) is that it's inconsistent with other forms
of variable declaration:
my sub foo( ?$bar is constant = 1 ) {...} # OKAY
my $bar is constant = 1; # OKAY
On Tue, Mar 11, 2003 at 04:39:05PM +0100, Matthijs van Duin wrote:
: Will infix operators be allowed to be macros instead of subs?
Yes, but they can't retroactively change the rules under which the left
argument was parsed. At most they can rearrange the returned parse
tree. The right argument i
On Wed, Mar 12, 2003 at 01:35:08PM +1100, Damian Conway wrote:
: 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 $sel
On Tue, Mar 11, 2003 at 06:08:59PM -0800, 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 m
On Wed, Mar 12, 2003 at 01:45:53PM +1100, Damian Conway wrote:
: I agree. As long as it's not C!
Of course not. We're trying to encourage the use of line noise,
and discourage the use of the long variants, so the long one would
have to be C.
Larry
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Austin Hastings wrote:
>
> > You're treading dangerously close to the S&M line there...
>
> Sure. That's exactly what types are for.
>
Granted.
> > Does it make sense to say C for this stuff?
>
> I'd much rather that simply using typed params i
--- Damian Conway <[EMAIL PROTECTED]> 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)) {...}
>
> thereby allowing:
>
>
--- John Siracusa <[EMAIL PROTECTED]> 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
>
On 3/12/03 1:50 AM, Mark Biggar wrote:
> 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 t
Larry Wall writes:
> However, if you access the last element using the length of the array,
> it may try to flatten, and fail:
>
> my @flat = (1..Inf, 1..10);
> $last = @[EMAIL PROTECTED] - 1]; # Kaboom!
>
> Still, we should be able to detect the attempt to flatten an infinite
> lis
43 matches
Mail list logo
