response to apo6 transfinite semantics challenge
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
list and give a better diagnostic than Perl 5's Out of memory.
Either that, or someone should just up and figure out how to subscript
arrays using transfinite numbers.
We've got Inf, right? So we know that scalar(()=(1..Inf) is Inf.
Inf - 1 is still Inf.
The only thing we need to define is what @arr[Inf] means.
It seems clear from the previous several paragraphs that Larry wants
someone to suggest, as part of the transfinite package, that
@arr[Inf]
can be defined as sugar for
{
my $_ = pop @arr;
push @arr, $_;
$_;
}
And this might even just be a special case that perl6 array-FETCH is
supposed to know about. (or create a LAST tie operator.)
The range specs that know their own length without flattening (see
a few paragraphs prev. in apo6) and counting would know if they are Inf.
--
David Nicol, independent consultant and contractor
perl -Mcoroutine0 -e'$c=new coroutine0 VARS=[],BODY=qYIELD 74;
YIELD 65;YIELD 80;YIELD 72; YIELD 10;;print chr$_ while$_=$c;'
Re: Wrappers vs. efficiency - quick comment
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 to do better than Perl 5. Perhaps we can have the default be to have wrappable subs, and then turn that off with specific declarations for speed, such as is inline. I think there's a lot of room between allow this subroutine to be wrapped and inline this subroutine. Whatever the specific declaration for speed is that forbids runtime wrapping of a subroutine, it should not be spelled inline. (although inline may imply dontwrapmeplease or whatever :) I don't see how a sub being inline-able prevents being wrap-able. I did say may... :) (anyway, my original point still stands) -John
Re: Wrappers vs. efficiency - quick comment
--- 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 than Perl 5. Perhaps we can have the default be to have wrappable subs, and then turn that off with specific declarations for speed, such as is inline. I think there's a lot of room between allow this subroutine to be wrapped and inline this subroutine. Whatever the specific declaration for speed is that forbids runtime wrapping of a subroutine, it should not be spelled inline. Hmm. In this area, I'm surprised that Larry didn't know better. My confidence in the implementation team's ability to produce fast functions, regardless of wrappage, is pretty high. I agree with you, John -- make this fast and make this inline aren't the same thing by a long shot. =Austin
Re: A6: Signature zones and such
--- 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:
sub foo(?$bar is default(1) is copy ) {...}
and hence (mirabile dictu):
sub foo(?$bar = 1 is copy ) {...}
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
my sub foo( ?$bar = 1 is constant ) {...} # OKAY
my $bar = 1 is constant; # KABOOM!
and thereby lays a cognitive trap for programmers.
1- Good catch, and all, but that's the kind of thing (like @ in
strings) that gets a warning emitted from the compiler -- not the kind
of thing that makes it prohibitive to support the feature.
I don't know...maybe I'm worrying too much.
But then, that's part of my job. ;-)
2- Yeah! ... umm, are we *paying* you for this?
=Austin
Re: A6: Strict signature checking - was: Complex Parameter Types
--- Damian Conway [EMAIL PROTECTED] wrote:
Austin Hastings wrote:
You're treading dangerously close to the SM line there...
Sure. That's exactly what types are for.
Granted.
Does it make sense to say Cuse strict params; for this stuff?
I'd much rather that simply using typed params invoked type
stricture.
Sure, but there's a difference between C (Boy Scout Oath) strictness
and C++ (FBI will visit your home and do a thorough background check
before we proceed) strictness.
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.
Connecting this with some thinking/talking about wrappage, it occurs to
me that:
Ccall is just a keyword. Which means that instead of doing
foo.wrap({ ...; call; ... });
I could just as easily do:
sub wrapper(...) { ...; call ; ... }
foo.wrap(wrapper);
Right?
I think there may be a library of wrapper helper-functions used by
both the compiler and module-writers. Things that do coercive behavior
rather than try-but-maybe-fail behavior.
So the use strict signatures; wouldn't be a switch invoking type
stricture, per se. What it would do is convert from DWIM stricture to
Patriot Act stricture.
=Austin
Re: A6: Signature zones and such
On Wed, Mar 12, 2003 at 01:45:53PM +1100, Damian Conway wrote: : I agree. As long as it's not Cis slurpy! 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 Cis slurpificatious. Larry
Re: A6: multi promotion
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 Cmulti to tell the compiler to build in multiple dispatch. : Any invocation of Cfoo after Cmulti foo 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 out the bottom and : winds up invoking the original sub(). No, a sub declaration must continue to be a strong claim that it is the only implementation *in scope*. : OK, hmm. What Damian is saying is that, tentatively, it's the : reverse... it calls the sub if theres a sub, then the multi if there's : a multi. So overriding a sub with a multi wouldn't work, but it would : *silently* not work, because you could just never get to the multi : version (well, not without a bit of introspection). It would silently not work in exactly the same sense that any other sub that is out of scope is invisible. : I agree that the issue of overriding an inherited/preexisting Csub -- : like one from a CPAN module -- with a set of Cmulti implementations : is a useful capability; it would allow you to extend predefined : routines to handle different arguments without getting into OO. But I : sure worry that it makes accidental redefinition of subs invisible in : many cases. There's no reason you can't write a multi that calls the sub. That multi would be visible anywhere the sub wasn't. Larry
Re: A6: overloading multis on constness of parameters
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 $self: is rw) returns Int is rw {...} #non-const version
:
: That second one would have to be:
:
: multi getX(Foo $self is rw:) returns Int is rw {...}
:
:
: Then we have the issue that Perl 6 objects can't really be constant,
: since Cis constant is a compile-time trait of *containers*...really just
: a don't assign to this container marker.
:
: However, within those limitations, I guess it's possible. After all, we
: have to check for lvaluability of Cis rw parameters anyway.
Might be one of those things that is taken as a tie-breaker, all other
things being equal. I'm thinking return types fall into the same category.
Larry
Re: Infix macros?
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 is fair game for any parsing shenanigans you want to try. (See other message on a .select macro, for instance.) Larry
Re: A6: Signature zones and such
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
my sub foo( ?$bar = 1 is constant ) {...} # OKAY
my $bar = 1 is constant; # KABOOM!
and thereby lays a cognitive trap for programmers.
1- Good catch, and all, but that's the kind of thing (like @ in
strings) that gets a warning emitted from the compiler -- not the kind
of thing that makes it prohibitive to support the feature.
Quite possibly. Except that, the more of these kinds of cognitive dissonances
a language has, the harder it is to learn and use. I see part of my job as
being to keep an eye on how many such special cases we're adding (and
removing!) from Perl 6. With the goal that the overall cognitive load of the
language doesn't go up.
I don't know...maybe I'm worrying too much.
But then, that's part of my job. ;-)
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. ;-)
Damian
Re: A6: macro invocants
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 macro): : : my Database $db = MySqlDatabase.connect(...); : $db.select * FROM Foo WHERE Foo.bar LIKE a%b; : : Could I implement this with the select function being a macro on the : Database base class: but invoked via the $db invocant? I am aware that : the macro would be a compile-time operation: but it could resolve into a : run-time mechanism that uses the invocant. If you use a module or class that defines macros, you can import the syntax at that point as well as the name. Might take an explicit import of the particular name to accomplish that though. But basically, yes, you can do that. Macros would be pretty darn useless if you couldn't import them. Larry
Re: A6: macro invocants
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 macro): : : my Database $db = MySqlDatabase.connect(...); : $db.select * FROM Foo WHERE Foo.bar LIKE a%b; : : Could I implement this with the select function being a macro on the : Database base class: but invoked via the $db invocant? I am aware that : the macro would be a compile-time operation: but it could resolve into a : run-time mechanism that uses the invocant. 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 ordinary expression on the left ($db) and a specially parsed argument on the right (* FROM Foo WHERE Foo.bar LIKE a%b) Larry
Re: Wrappers vs. efficiency - quick comment
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 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 wrappable : subs, and then turn that off with specific declarations for speed, such as : is inline. : : I think there's a lot of room between allow this subroutine to be wrapped : and inline this subroutine. Whatever the specific declaration for speed : is that forbids runtime wrapping of a subroutine, it should not be spelled : inline. : : (although inline may imply dontwrapmeplease or whatever :) : : I don't see how a sub being inline-able prevents being wrap-able. : : I did say may... :) Just like I did say such as. :-/ Larry
Re: A6: Strict signature checking - was: Complex Parameter Types
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 many others it's not DWIS (Do What I Said). To them, types are about
compile-time checking of constraints on the run-time compatibility of data.
So they would argue that declaring Cfoo like that implies that any argument
passed to Cfoo ought to guarantee that it already contains Ints, rather than
specifying a (possibly unsuccessful) run-time coercion to ensure that
condition. And many would argue that implicit coercions on typed parameters is
one of the major *problems* with C++.
My own problem with this wrapping notion is that I consider it incompatible
with the reference semantics of normal Perl 6 parameters. Specifically, I
*don't* want the aliasing mechanism to be capable of implicit type coercions.
On the other hand, I have *no* problem with this:
sub foo(@a is Array of Int is copy) {...}
^^^
doing the kind of coercive wrapping you're suggesting.
Connecting this with some thinking/talking about wrappage, it occurs to
me that:
Ccall is just a keyword. Which means that instead of doing
foo.wrap({ ...; call; ... });
That has to be:
foo.wrap({ ...; call; ... });
I could just as easily do:
sub wrapper(...) { ...; call ; ... }
foo.wrap(wrapper);
Right?
foo.wrap(wrapper);
But, yes.
I think there may be a library of wrapper helper-functions used by
both the compiler and module-writers. Things that do coercive behavior
rather than try-but-maybe-fail behavior.
Quite possibly. Though wrapping is probably too heavy a mechanism for type
coercions. When I imagine type coercions in Perl 6, I imagine them as
compile-time detectable, and explicit.
So the use strict signatures; wouldn't be a switch invoking type
stricture, per se. What it would do is convert from DWIM stricture to
Patriot Act stricture.
I still believe that the default level of type-checking you're proposing is
the wrong way round.
Damian
Re: A6: Signature zones and such
Larry wrote: : I agree. As long as it's not Cis slurpy! 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 Cis slurpificatious. Riiight! Thank-you, General Haig. Of course, Cis variadic (my own preference for the name of this trait) would probably have much the same effect. ;-) Damian
Re: A6: Signature zones and such
On Wednesday, March 12, 2003, at 11:14 AM, Damian Conway wrote: Larry wrote: : I agree. As long as it's not Cis slurpy! 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 Cis slurpificatious. Riiight! Thank-you, General Haig. Of course, Cis variadic (my own preference for the name of this trait) would probably have much the same effect. ;-) Can we get a final answer, for the (documented) record? @list is variadic @list is slurpy @list is greedy @list is slurpificatious @list is slurptacular @list is bloated :-) MikeL
Re: A6: Signature zones and such
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 Cis slurpy! : 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 Cis slurpificatious. : : Riiight! Thank-you, General Haig. : : Of course, Cis variadic (my own preference for the name of this : trait) would probably have much the same effect. ;-) : : Can we get a final answer, for the (documented) record? No. I have to wait till Damian isn't looking. Larry
Re: A6: Signature zones and such
--- 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 ) {...} # OKAY
my $bar is constant = 1; # OKAY
my sub foo( ?$bar = 1 is constant ) {...} # OKAY
my $bar = 1 is constant; # KABOOM!
and thereby lays a cognitive trap for programmers.
1- Good catch, and all, but that's the kind of thing (like @ in
strings) that gets a warning emitted from the compiler -- not the
kind
of thing that makes it prohibitive to support the feature.
Quite possibly. Except that, the more of these kinds of cognitive
dissonances
a language has, the harder it is to learn and use. I see part of my
job as
being to keep an eye on how many such special cases we're adding (and
removing!) from Perl 6. With the goal that the overall cognitive load
of the language doesn't go up.
But this isn't really a cognitive dissonance, so much as perl6 being
willing to forgive ordering in cases where the meaning is obvious.
I HOPE this doesn't work:
my sub foo( ?$bar = 1 is constant ) {...} # OKAY, but redundant.
my sub foo( ?$bar is rw = 1 is constant) {...} # const if defaulted?
Unless the second case works, and I hope it doesn't, there's only one
meaning to is trait in a signature. Since there's only one meaning,
just warn the developer if the order doesn't agree with declaration
order.
I don't know...maybe I'm worrying too much.
But then, that's part of my job. ;-)
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. ;-)
You're a point of light, Damian. (*)
=Austin
*: Borrowed from the other George Bush.
Re: A6: Signature zones and such
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
Re: A6: Signature zones and such
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
point where their context tracking system overloads and they have to go off
and become Lisp programmers. I'm just trying to make sure we don't
incrementally boil the frog to that point.
I HOPE this doesn't work:
my sub foo( ?$bar = 1 is constant ) {...} # OKAY, but redundant.
my sub foo( ?$bar is rw = 1 is constant) {...} # const if defaulted?
No, its an error. Under either proposed syntax.
Damian
Re: A6: Strict signature checking - was: Complex Parameter Types
--- 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 automatically wrap the @input array in a
make-it-an-int converter. This, to me, is DWIM.
But to many others it's not DWIS (Do What I Said). To them, types
are about compile-time checking of constraints on the run-time
compatibility of data.
No problem so far. And when they run -w, perl should tell them
subroutine call not provably (in)correct at line 3
So they would argue that declaring Cfoo like that implies that any
argument passed to Cfoo ought to guarantee that it already
contains Ints, rather than specifying a (possibly unsuccessful)
run-time coercion to ensure that condition.
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.
I expect that the folks who want to do one-liners will still want to be
able to say Cperl6 -MCPAN whatever
So the strict bits have to be forgiving of the non-strict callers.
To me, the way around this is NOT to force interface contracts down to
some lowest common denominator, but rather to document what is
expected, and then allow the developer to accept responsibility for
stepping on his crank.
If you say, Give me an Array of Hash of (String = Array of BigNum)
and I say, Here's an Array of Scalars. They're OK, I promise and
things gang agley, it's my fault. I can deal with that.
And if you have said Array of Hash of (String = Array of BigNum)
then I can theoretically give you a typed array and let the compiler
check it.
However, if you have been forced to say Give me an Array in the
interests of avoiding typewhacking one-liners, then (1) you've got to
check and throw the exception, slowing up your code; and (2) there's no
option for me if I *DO* want to conform to the rigid rules.
And many would argue that implicit coercions on typed
parameters is one of the major *problems* with C++.
Of course it is. And why is that? Because they've GOT strongly typed
parameters, but sometimes the data doesn't match the signature. This
has been exacerbated by differentiating const from non-const types, and
by that foul fire-hose of code known as the template mechanism.
But at the bottom, the C++ problem is a problem of its own making --
people want coercion. Just like me. I want coercion. I want the ability
to take advantage of the really nifty, carefully written code available
from dedicated, rigorous hackers like this Conway fellow. But I want to
do it as a slap-dash hack with no thought given to type stuff. How?
My own problem with this wrapping notion is that I consider it
incompatible with the reference semantics of normal Perl 6
parameters. Specifically, I *don't* want the aliasing mechanism to
be capable of implicit type coercions.
Maybe you could expand on that a little?
On the other hand, I have *no* problem with this:
sub foo(@a is Array of Int is copy) {...}
^^^
doing the kind of coercive wrapping you're suggesting.
What's the difference? (Aside from the obvious, that is...)
I think there may be a library of wrapper helper-functions used
by
both the compiler and module-writers. Things that do coercive
behavior
rather than try-but-maybe-fail behavior.
Quite possibly. Though wrapping is probably too heavy a mechanism
for type
coercions. When I imagine type coercions in Perl 6, I imagine them as
compile-time detectable, and explicit.
Ahh, but if you don't want heavy, just comply with the expected type,
or do your own coercion. I certainly imagine them as compile-time
detectable (I don't want all subcalls to be wrapped), but obvious,
implicit coercions should get a configurable warning and a wrapper.
sub foo(@a of Scalar) {...}
foo(1, 2, 3); # OKAY
foo(@a, @b, @c); # WARNING: foo(List of Array) will be coerced to
foo(Array of Scalar) using foo.wrap(__flattenArrays)
foo(**(@a, @b, @c)); # OKAY: Fixed it using SuperMario operator.
So the use strict signatures; wouldn't be a switch invoking type
stricture, per se. What it would do is convert from DWIM
stricture to Patriot Act stricture.
I still believe that the default level of type-checking you're
proposing is the wrong way round.
Hmm. Okay. I'll let you reverse the default levels if you give me a
single-letter command line switch to go back to slouch-mode..
=Austin
Re: A6: Signature zones and such
--- Damian Conway [EMAIL PROTECTED] wrote:
Larry wrote:
: I agree. As long as it's not Cis slurpy!
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 Cis slurpificatious.
Riiight! Thank-you, General Haig.
Of course, Cis variadic (my own preference for the name of this
trait) would
probably have much the same effect. ;-)
my macro sucks() is parsed(/null/) { is slurpificatious }
=Austin
Re: A6: Strict signature checking
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 in a
make-it-an-int converter. This, to me, is DWIM.
But to many others it's not DWIS (Do What I Said). To them, types
are about compile-time checking of constraints on the run-time
compatibility of data.
So they would argue that declaring Cfoo like that implies that any
argument passed to Cfoo ought to guarantee that it already contains
Ints, rather than specifying a (possibly unsuccessful) run-time
coercion to ensure that condition. And many would argue that implicit
coercions on typed parameters is one of the major *problems* with C++.
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. Take the example:
sub foo(str $s) {...}
my str $a = 'blah'; # type 'str'
my $b = 'blah'; # untyped, but set to a constant 'str'
my $c = $a; # untyped, but set to a known typed 'str'
my $d = $a + $b; # untyped, but known to be of type 'str'
foo($a); # OK
foo($b); # COMPILE ERROR
foo($c); # COMPILE ERROR
foo($d); # COMPILE ERROR
With strict typing, the last three lines are errors. But it is known
that $b,$c,$d were all set to known Cstr values and have not since
been altered. So the compiler *could* infer the type of these
variables without them explicitly being stated, we *might* choose to
catch those cases and make them non-errors. (You can actually track
the 'type' hints quite a ways, if the operations you're doing produced
typed values.)
That would allow the use of quickie untyped temporary variables. For
example, if you have a little ten-line script that uses type-aware
CP6AN subs, but yer a lazy slob.
Again, POMTC (percentage of me that cares), 50%. Not a showstopper.
Just an idea.
MikeL
A6: Type Coercions (was Re: A6: Strict signature checking)
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 the sake of example, let's assume we
have a class, CMyClass, that doesn't inherit from str, but that can
be converted to a str if necessary.
sub foo(str $s);
my str $a = 'blah';
my MyClass $myclass = MyClass.new;
foo($a); # OK
foo($myclass);# COMPILE ERROR; WRONG TYPE
That last line is a type coercion... we know it's one type, but it
needs to be another. Previous implication is that you'd do it like
this:
foo($myclass.str); # OK
I'm not keen on that syntax, personally, because it means you're
cluttering up the method namespace of MyClass with every possible
type/class you want to be able to convert to, which I have to think
would cause problems in larger libraries. I at one point suggested:
class MyClass {
to str {...}
to num {...} # etc
}
foo($myclass to str);
as a way to separate the 'coercions' namespace from the normal
'methods' namespace. But regardless, the A6 question being asked is
whether the Csub or Cmulti can know when it's allowed to implicitly
coerce arguments from one type to another, such that
foo($myclass);
can work without having to first define 'foo' variants to explicitly
handle each and every possible type. Possibilities:
(1) If MyClass isa str, or MyClass implements str, problem solved -- it
will work on anything that a str works on, right? (But maybe you don't
want your class to actually _implement_ str, because we don't
ordinarily want it to be considered a str... we actually just want a
one-directional way to _convert_ instances to strs.)
(2) Maybe we can mark a given Cmulti as being specifically willing to
coerce an argument if necessary, probably with a trait:
multi foo (str $s) {...} # Normal syntax
multi foo ($s to str) {...} # OK, should attempt to COERCE $s to
a str
multi foo (str from $s) {...} # alternate spelling???
... thereby identifying that we want to convert it if the compiler
and/or runtime can figure out how. Would something like that achieve
the desired effect?
My main points being, untyped-to-typed coercion is different from true
type coercion, and that the 'coerce to' and 'implements' relationships
might be worthy of syntactic separation.
POMTC: 70%
MikeL
Re: A6: Strict signature checking
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 Object must be dynamically cast to
conform to a narrower type (however dynamic casting actually works).
If a variable is untyped, i.e. not explicitly anything at all, it
could be subject to run-time automatic coercion (of course resulting
in an exception if they are incompatible). That would allow us
lazy folks to still get what we want with weak typing.
Take the example:
sub foo(str $s) {...}
my str $a = 'blah'; # type 'str'
my $b = 'blah'; # untyped, but set to a constant 'str'
my $c = $a; # untyped, but set to a known typed 'str'
my $d = $a + $b; # untyped, but known to be of type 'str'
foo($a); # OK
foo($b); # COMPILE ERROR
foo($c); # COMPILE ERROR
foo($d); # COMPILE ERROR
Requiring this kind of behavior (from a standard writer point of
view) wouldn't be such a good idea, though. You could say it's up to
the compiler to do whatever sort of data flow analysis it wants, and
may catch these things at compile time if it can. Consider this:
sub baz(Int $x) {...}
my $read = 0;
my $foo = 'Glippy glop gloopy';
for 1..10 {
$foo = if $read;
}
baz $foo; # ERROR: type incompatibility.
A smart compiler could catch that one, but a dumb one should be
allowed not to and defer it until runtime. But---it's probably the
case that there will still only be one Perl, so it's not really an
issue. Except for the doc folks.
Naturally, in a threaded environment, declaring something as Cis
shared would be much like Cvolatile in C.
Luke
Re: A6: Signature zones and such
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 for those of us out in the field to contribute financial support to the development of Perl6? -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: A6: Signature zones and such
--- 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 TPF isn't supporting you folks anymore, what's the best way for those of us out in the field to contribute financial support to the development of Perl6? Oh, how cool. I can use Pavlovian conditioning on Damian. Damian: The answer is Austin: Cool, I like that answer... PayPal: Ding! Damian has more money.. After a few exegeses, he'll be a drooling slave to my whim ... =Austin
Re: A6: Strict signature checking - was: Complex Parameter Types
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 does matter, we (the low level PASM folks :) have achieved a speed increase of x100 and more, on a now of course hand crafted assembler routine compared to $HLInterpLang. These are the margins that a good optimizer will be able to hopefully reach, which are for plain integers near or beyond gcc -O3 performance with the JIT runtime. When the flexibility of all the lanugage comes in, this is of course not possible, and the more of those features (caller, %MY, leave, exceptions) are used, the less, optimizations can be used. But for what is the type-checking stuff: for sure for better diagnostic messages and for performance, when needed. =Austin leo
Re: A6: macro invocants
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 ordinary expression on the left ($db) and
a specially parsed argument on the right (* FROM Foo WHERE Foo.bar LIKE a%b)
This feels a bit clunky. The sort of hack one makes when its too late to
fix it.
If we define .select as an infix macro, it is then not scoped to the
invocant. This means that it would confict with any other .select method
that one might wish to call. E.g.
$io.select(...);
(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 this burden,
I'd like to propose Cmacromethod as a counterpart to Csubmethod. A
macromethod would enable me to write an invocant-scoped macro, without
polluting the lexical namespace:
class Database
{
...
macromethod select ($lhs, $rhs:) is parsed /sql.select.body/
{
$lhs.do_sql('select $rhs')
}
}
Without this mechanism, then we need a way to prevent an infinite
regress on macro processing. I am assuming that, if the output of a
macro is a string, then that string will be re-parsed and any macros in
it will be expanded. How would an infix macro indicate that it didn't
want to handle the $io.select example? If it returns its input,
unchanged, then that would be an infinite loop.
Dave.
--
http://dave.whipp.name
Re: A6: overloading multis on constness of parameters
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 version
If getX were called on a const Foo object then the first getX would be
called, and if it were called on a non-const Foo object the second one would
be.
Speaking of multis and constants, Greg McCarroll wondered on IRC if
this would work:
multi factorial (Int 0) { 1 }
multi factorial (Int $n) { $n * factorial($n-1) }
Disregarding the fact that you should really write that as:
sub factorial (Int $n) {
my multi tail_fac ($result, 0) { $result }
my multi tail_fac ($result, $n) { tail_fac( $result * $n, $n - 1 ) }
tail_fac(1, $n);
}
(Assuming you want to do it recursively that is...)
--
Piers
Re: A6: Signature zones and such
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 Cis slurpy! 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 Cis slurpificatious. Riiight! Thank-you, General Haig. Of course, Cis variadic (my own preference for the name of this trait) would probably have much the same effect. ;-) Can we get a final answer, for the (documented) record? @list is variadic @list is slurpy @list is greedy @list is slurpificatious @list is slurptacular @list is bloated @list is greedy Anyone? -- Piers
Re: A6: macro invocants
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 this burden,
I'd like to propose Cmacromethod as a counterpart to Csubmethod. A
macromethod would enable me to write an invocant-scoped macro, without
polluting the lexical namespace:
class Database
{
...
macromethod select ($lhs, $rhs:) is parsed /sql.select.body/
{
$lhs.do_sql('select $rhs')
}
}
Without this mechanism, then we need a way to prevent an infinite
regress on macro processing. I am assuming that, if the output of a
macro is a string, then that string will be re-parsed and any macros in
it will be expanded. How would an infix macro indicate that it didn't
want to handle the $io.select example? If it returns its input,
unchanged, then that would be an infinite loop.
Well, if you did that, it surely couldn't be polymorphic, which kind
of defeats most of the purpose of making it a method. Yeah, namespace
pollution is a little issue, but not really. You could scope the
macro to the Database class, so it would be CDatabase::select
Interestingly, it would be almost impossible to get effective methods
that use an Cis parsed trait. Is it legal to do so?
Luke
Operators and context
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 version of this list?
2. Perhaps this list ought to be expanded to specify how the operators
relate to context (e.g., C+ applies numeric context to LHS and RHS).
I'm happy to give this a go, but I'd prefer the most recent operator
list first.
3. Speaking of context, what's the complete tree of contexts now?
Am I missing anything from this? Are ArrayRef and HashRef et al still
needed, or are we going away from the %{...} notation for dereferencing
a hash?
Type context
|
+--- Scalar
||
|+--- Bool
||
|+--- Num
|||
||+--- Int
||
|+--- Str
||
|+--- Ref
| |
| +--- HashRef
| |
| +--- ArrayRef
| |
| +--- CodeRef
| |
| +--- ScalarRef
|
+--- List
||
|+--- (lazy and eager?)
|
+--- Void
(Is there a Pair context? PairRef? My guess is no.)
What about other, orthogonal, context-like things?
Lvalue/Rvalue (i.e., do to with C=)?
Binding/Nonbinding (i.e., to do with C:=)?
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
Have you ever seen anything so wonderful in your entire life? Wow, cool!
But, err, what is it? I don't know, but I bet Scuttle will. - _The Little
Mermaid_
Re: A6: macro invocants
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 standard sequence. I would consider my macromethod in a similar vain. 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. But the actual Iparsing could not be polymorphic. Thus, this wouldn't work: my $db = new Database; $db.select ... Because the compiler [may] not know that $db is a Database until runtime, after it's been parsed. However, this could work: my Database $db = new Database; $db.select ... Which may just be the price you have to pay to use Cmacromethod. But then, the only advantage that I'm seeing to macromethod, other than the namespace pollution bit, is that it can handle arbitrarily complex variable names, which macros ought to do anyway. Which means you usually have to use a parse tree instead of simple string substitution (I trust Larry to make it sufficiently easy to do that). So, what I'm essentially saying is that Cmacromethod doesn't buy you much save syntactic sugar. Perhaps you can give a concrete counterexample? Luke
Re: Operators and context
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/[EMAIL PROTECTED]/msg12130.html
So, my questions:
1. Is there a more recent version of this list?
Nope, I think that version is still good. There will be the addition
of the piping ops == and ==, and I'm not sure if (a) the Unicodeness
of op was ever decided upon, and (b) whether there's still an
op vs. op issue.
Note also that some of the things may or may not be real operators,
but those should all be clearly marked in that version.
2. Perhaps this list ought to be expanded to specify how the operators
relate to context (e.g., C+ applies numeric context to LHS and RHS).
I'm happy to give this a go, but I'd prefer the most recent operator
list first.
It'll be huge, but needs to be done, that's for sure. I'd certainly be
happy if you gave it a shot!
3. Speaking of context, what's the complete tree of contexts now?
Am I missing anything from this? Are ArrayRef and HashRef et al still
needed, or are we going away from the %{...} notation for dereferencing
a hash?
A6 implies that there will be a knowable context for every type, so
your type-context tree probably looks nearly identical to the P6 type
hierarchy. But what that full type tree is, I dunno. :-) We left it
hanging...
-- Is a Cnum a CNum, or is a CNum a Cnum?
-- Is an Cint a Cnum, or are they both subclasses of Cnumeric?
-- Are things like CHashRef actually called CRef::Hash or similar?
-- Is there a difference between CArray and CList context?
-- etc.
We also talked on-list about whether 'void' could be considered a type,
but nothing came out of it. So this is definitely an area that needs
some serious help...
Type context
|
+--- Scalar
|+--- Bool
|+--- Num
||+--- Int
|+--- Str
|+--- Ref
| +--- HashRef
| +--- ArrayRef
| +--- CodeRef
| +--- ScalarRef
+--- List
|+--- (lazy and eager?)
|
+--- Void
(Is there a Pair context? PairRef? My guess is no.)
(There's also Object, Code, and all the others in A6, approx. page 8.)
MikeL
Re: A6: macro invocants
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 parsing, or you need to treat .select
: as an infix macro that has an ordinary expression on the left ($db) and
: a specially parsed argument on the right (* FROM Foo WHERE Foo.bar LIKE
: a%b)
:
: This feels a bit clunky. The sort of hack one makes when its too late to
: fix it.
:
: If we define .select as an infix macro, it is then not scoped to the
: invocant. This means that it would confict with any other .select method
: that one might wish to call. E.g.
:
: $io.select(...);
:
: (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 this burden,
: I'd like to propose Cmacromethod as a counterpart to Csubmethod. A
: macromethod would enable me to write an invocant-scoped macro, without
: polluting the lexical namespace:
:
: class Database
: {
:...
: macromethod select ($lhs, $rhs:) is parsed /sql.select.body/
: {
: $lhs.do_sql('select $rhs')
: }
: }
I am uncomfortable with the notion of depending on the declared type of
the left argument for deciding which macro to use, because its failure
mode potentially includes totally misparsing the right argument, and
because the declared type of the object is not necessarily the same
as the actual type, so if a derived class had its own idea of the macro,
the wrong macro would be used according to at least one viewpoint.
: Without this mechanism, then we need a way to prevent an infinite
: regress on macro processing. I am assuming that, if the output of a
: macro is a string, then that string will be re-parsed and any macros in
: it will be expanded. How would an infix macro indicate that it didn't
: want to handle the $io.select example? If it returns its input,
: unchanged, then that would be an infinite loop.
If the declaration is essentially nailing down a particular class in
a non-virtual sense, then there's really nothing gained over writing
IO::select $io: ...
DB::select $db: ...
other than the obvious obfuscational benefit of having the class
selection defined elsewhere.
I'm not saying that what you want is bad. I'm just uncomfortable
with it. Certainly a macro could be written to pay attention to the
declared type of its left argument, and we could even arrange for
some kind of compile-time multimethod dispatch with whatever syntax
is deemed appropriate. But mixing such compile-time semantics with
a notation that supposedly mandates run-time dispatch is a recipe
for a certain amount of confusion no matter how well we do it.
Larry
Re: A6: macro invocants
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/TemplateMethod.html But the actual Iparsing could not be polymorphic. Thus, this wouldn't work: my $db = new Database; $db.select ... Because the compiler [may] not know that $db is a Database until runtime, after it's been parsed. However, this could work: my Database $db = new Database; $db.select ... To a large extent, this depends on how powerful the type-inference mechanisms are. In theory, if MyDatabase.new returns Database, then the type of $db can be inferred. Even if the return type is not explicitly defined, we can look in the method-body, and see that its constructing/returning an object of base-type Database. But you're right, there are situations where the (base) type might not be knowable: and these could result in syntax errors. So, what I'm essentially saying is that Cmacromethod doesn't buy you much save syntactic sugar. Perhaps you can give a concrete counterexample? I admit that I have a sweet-tooth: I like syntactic sugar ;-). And I'm one of those environmentalists who don't like (namespace) pollution. The sugar I'm using here is to go from $db.do_sql(select * from Foo); to $db.select * from Foo; I'm sure there is nice way to represent this with a leading keyword: but one of the things that Perl6 is doing (over perl5) is to make (almost) everything callable as methods. Thus if we allow (as a standard macro -- though a macromethod would also support it) select $db: * from Foo; then we should also allow the method-call syntax. I'll admit that this is one of those cases where the user already knows that there's some magic happenning -- that select is introducing a new syntax -- but it would be nice to keep the invocant part looking like Perl6 code. Perhaps I should back off a bit: Perl6 *will* be powerful enough support the Macros::macromethod module, so perhaps I'll be able to write it in a year's time, or so. It'll be a good test of the extensability mechanisms. Dave. -- http://dave.whipp.name
RE: A6: macro invocants
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(
Foo(
WHERE(
Foo.bar()
)
) LIKE (
a % b
)
);
The only part of that I'm not sure about is infix:LIKE, since such an
operator hasn't been declared. But I assume you get the idea--you could
conceivably have Very Bad Things happen if Perl doesn't catch a
macromethod call.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
How do you test this 'God' to prove it is who it says it is?
If you're God, you know exactly what it would take to convince me. Do
that.
--Marc Fleury on alt.atheism
Re: A6: macro invocants
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 been declared. But I assume you get the idea--you could conceivably have Very Bad Things happen if Perl doesn't catch a macromethod call. But in such cases, the $db variable would not (could not) have a run-time .select method: so you'd still get an error -- albeit at run time. Dave. -- http://dave.whipp.name
Re: A6: overloading multis on constness of parameters
- 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-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 be:
multi getX(Foo $self is rw:) returns Int is rw {...}
Then we have the issue that Perl 6 objects can't really be constant,
since Cis constant is a compile-time trait of *containers*...really just
a don't assign to this container marker.
However, within those limitations, I guess it's possible. After all, we
have
to check for lvaluability of Cis rw parameters anyway.
How would I take a get a reference to the second one? I assume I could
get a reference to the first by
$ref = getX(Foo);
Joe Gottman
Re: A6: overloading multis on constness of parameters
- 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-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 be:
multi getX(Foo $self is rw:) returns Int is rw {...}
Then we have the issue that Perl 6 objects can't really be constant,
since Cis constant is a compile-time trait of *containers*...really just
a don't assign to this container marker.
However, within those limitations, I guess it's possible. After all, we
have
to check for lvaluability of Cis rw parameters anyway.
How would I take a get a reference to the second one? I assume I could
get a reference to the first by
$ref = getX(Foo);
Well, if there's overloading based on traits, siglets must support
traits. So, it would have to be:
$ref = getX(Foo is rw:);
(The first would be)
$ref = getX(Foo:);
Backwhacking those couldn't hurt, either.
Luke
