Re: How are types related to classes and roles?
On Wed, Feb 23, 2005 at 12:17:19PM -0800, Larry Wall wrote: > : And how does all this combine with the notion of context? > > Lazily, for the most part. In some cases we can determine context at > compile time, but often not. Certainly a subroutine cannot determine > what context it was called in until it's actually called, unless we > venture into return-value MMD, which has problems resolving against > parameter MMD. Ugh. Pugs currently does return-value based MMD, and it has indeed the core reason behind my recently-reported dilemma on MMD tiebreaking. If we lose retval-MMD, many sensible cases can then be resolved without the need of "is default". However, retval-based MMD is neccessary to ensure compile-time dispatch, and plays really well with type inferencing in general. So another solution is to mark ambiguate retval-based dispatches as ill-typed, and let the programmer resolve it by explicit type annotation. But making it default is probably too much B&D. So, I think late binding is a sensible (and practical) default, but do you think it may be a good thing to have a type inference mode that assign static contexts to expressions, and prebind as much as possible? It may be possible to enable via a pragma or a compiler switch... Thanks, /Autrijus/ pgpNecWz3n4T6.pgp Description: PGP signature
Re: How are types related to classes and roles?
On Fri, Feb 25, 2005 at 12:45:45AM +0800, Autrijus Tang wrote: > On Wed, Feb 23, 2005 at 12:17:19PM -0800, Larry Wall wrote: > > : And how does all this combine with the notion of context? > > > > Lazily, for the most part. In some cases we can determine context at > > compile time, but often not. Certainly a subroutine cannot determine > > what context it was called in until it's actually called, unless we > > venture into return-value MMD, which has problems resolving against > > parameter MMD. > However, retval-based MMD is neccessary to ensure compile-time > dispatch, and plays really well with type inferencing in general. > So another solution is to mark ambiguate retval-based dispatches as > ill-typed, and let the programmer resolve it by explicit type > annotation. But making it default is probably too much B&D. Not that the tail should wag the dog, but as I remember it, parrot can do return-value MMD "for free", because the continuation-passing style of function calling means that actually there's no difference between a function call and a function return. [It's all just one maze of non-local gotos :-)] So if I understand it correctly, there's no speed hit in doing return- value MMD. Just a sanity hit. Nicholas Clark
Re: How are types related to classes and roles?
On Thu, Feb 24, 2005 at 05:17:50PM +, Nicholas Clark wrote: : On Fri, Feb 25, 2005 at 12:45:45AM +0800, Autrijus Tang wrote: : > On Wed, Feb 23, 2005 at 12:17:19PM -0800, Larry Wall wrote: : > > : And how does all this combine with the notion of context? : > > : > > Lazily, for the most part. In some cases we can determine context at : > > compile time, but often not. Certainly a subroutine cannot determine : > > what context it was called in until it's actually called, unless we : > > venture into return-value MMD, which has problems resolving against : > > parameter MMD. : : > However, retval-based MMD is neccessary to ensure compile-time : > dispatch, and plays really well with type inferencing in general. : > So another solution is to mark ambiguate retval-based dispatches as : > ill-typed, and let the programmer resolve it by explicit type : > annotation. But making it default is probably too much B&D. : : Not that the tail should wag the dog, but as I remember it, parrot can do : return-value MMD "for free", because the continuation-passing style of : function calling means that actually there's no difference between a : function call and a function return. [It's all just one maze of non-local : gotos :-)] So if I understand it correctly, there's no speed hit in doing : return- value MMD. Just a sanity hit. I belive that mechanism doesn't actually combine with parameter MMD to pick the original routine to call based on context. If I recall, it only comes into play at the time you actually try to return. Larry
Re: How are types related to classes and roles?
On Fri, Feb 25, 2005 at 12:45:45AM +0800, Autrijus Tang wrote: : On Wed, Feb 23, 2005 at 12:17:19PM -0800, Larry Wall wrote: : > : And how does all this combine with the notion of context? : > : > Lazily, for the most part. In some cases we can determine context at : > compile time, but often not. Certainly a subroutine cannot determine : > what context it was called in until it's actually called, unless we : > venture into return-value MMD, which has problems resolving against : > parameter MMD. : : Ugh. Pugs currently does return-value based MMD, and it has indeed : the core reason behind my recently-reported dilemma on MMD tiebreaking. : If we lose retval-MMD, many sensible cases can then be resolved without : the need of "is default". Though not all. : However, retval-based MMD is neccessary to ensure compile-time : dispatch, and plays really well with type inferencing in general. : So another solution is to mark ambiguate retval-based dispatches as : ill-typed, and let the programmer resolve it by explicit type : annotation. But making it default is probably too much B&D. Depends on where it has to be marked. Anyone can choose their B&D level within their own lexical scope, as long as they don't impose it on other lexical scopes. : So, I think late binding is a sensible (and practical) default, but : do you think it may be a good thing to have a type inference mode that : assign static contexts to expressions, and prebind as much as possible? : It may be possible to enable via a pragma or a compiler switch... It's certainly something to explore. If I recall, I took some kind of compromise position in the Apocalypse where I said we probably wouldn't treat return-type-MMD with the same authority as parameter MMD, but we might be able to use return type as a tie-breaker on otherwise equivalent routines. Basically, instead of writing a single routine with a big switch statement in it, you'd be able to write multiple routines with the same parameters but different return types as a form of syntactic sugar over the switch statement. It's not clear if such an approach would buy us anything in terms of type inferencing, except insofar as sub declarations are easier to mine the return types out of than an embedded switch statement. Maybe that buys us a lot, though, just as having class metadata available at compile time is a big improvement over Perl 5's @ISA. Anyway, I don't profess to have thought deeply about type inferencing. But I do know that I don't want to turn Perl 6 into ML just yet... Larry
Re: How are types related to classes and roles?
On Thu, 2005-02-24 at 12:42, Larry Wall wrote: > On Fri, Feb 25, 2005 at 12:45:45AM +0800, Autrijus Tang wrote: > : On Wed, Feb 23, 2005 at 12:17:19PM -0800, Larry Wall wrote: > : > Certainly a subroutine cannot determine > : > what context it was called in until it's actually called, unless we > : > venture into return-value MMD, which has problems resolving against > : > parameter MMD. > : > : Ugh. Pugs currently does return-value based MMD, and it has indeed > : the core reason behind my recently-reported dilemma on MMD tiebreaking. > : If we lose retval-MMD, many sensible cases can then be resolved without > : the need of "is default". > > Though not all. Is there any reason at all that 6.0 should have return MMD? I mean, it's way-the-heck cool and all, but it became a "thing" when Parrot produced this capability as a by-product of the way MMD was implemented in conjunction with return continuations that doesn't mean we HAVE to use it. My gut feeling is that there are many places where Perl 6 has not had a chance to get felt out (or is that up?) by the community, and we're walking out on a dangerous limb by implementing features on top of some of those questionable areas. Sometime after we've all gotten a sense of what MMD means for Perl and how that differs from what MMD means to other popular languages, perhaps then we should explore what return-MMD could do for our lives. Just a thought. -- â 781-324-3772 â [EMAIL PROTECTED] â http://www.ajs.com/~ajs
scoping functions as list operators?
Giving scoping functions the status of list operators would allow to drop parentheses when not used in conjunction with initializer so one could write: my $a, $b, $c; instead of my ($a, $b, $c); Most people use scoping functions as the top most function of the corresponding statement AST so that should not bite unsuspecting people. Probably many more people that don't use stricture are currently caught by the current convention that obliges to parenthesize when multiple variables are declared. In a sense, so many people have been bitten by surprising precedence, that they cargo-cult parentheses as the list operator. In my detestation of gratuitous parenthesses, I would additionally propose a low precedence assignement operator if I could find a good sign for it. my $a, $b, $c := 1..3 ; # too bad := is already taken. # set? I don't think so. my $a, $b, $c set 1..3 ; # alphabetic like and, or, xor? # and what precedence relative to them? -- stef
Re: scoping functions as list operators?
StÃphane Payrard writes:
>
> Giving scoping functions the status of list operators
> would allow to drop parentheses when not used in conjunction
> with initializer so one could write:
>
> my $a, $b, $c;
>
> instead of
>
> my ($a, $b, $c);
Hmm, but that kills the Perl 5 ability to do concise inline 'my's:
while my $line = =$fh {...}
However, since 'for' is getting revamped so that there isn't a need to
use inline 'my' as much, your proposal might be going somewhere. As you
point out, we don't have a low precedence equals, so we're just creating
a red herring:
my $x, $y; # fine
my $x, $y = (1, 2); # oops!
We have discussed making equals low precedence enough to eliminate the
parentheses in the standard swap:
$x, $y = $y, $x;
But there are a couple of arguments against that. First, Perl
programmers like to make assignments within listops. Second, the
parentheses make a nice visual "pill" so that you can easily see the
multiple assignment.
I don't think it's a good idea to make a new low precedence assignment.
Let's say we made it <-. Does that imply that there is also
low-precedence binding :<- and compile-time binding ::<- ? Those don't
look right. I think we're weighing making good ol' assignment low
precedence vs. having parentheses on 'my'.
Luke
Re: scoping functions as list operators?
On Fri, Feb 25, 2005 at 03:56:06AM +0100, Stéphane Payrard wrote: > > Giving scoping functions the status of list operators > would allow to drop parentheses when not used in conjunction > with initializer so one could write: > > my $a, $b, $c; > > instead of > > my ($a, $b, $c); Too bad that in English there is no plural for my. In French it would work fine mon $a; # French for C, singular # C as a list operator mes $a, $b, $c; # French for C, plural -- stef
Re: How are types related to classes and roles?
On Thu, Feb 24, 2005 at 09:42:30AM -0800, Larry Wall wrote: > > Anyway, I don't profess to have thought deeply about type inferencing. > But I do know that I don't want to turn Perl 6 into ML just yet... > > Larry > Speaking of ML, it appears to me that Perl6 rules are a mechanism that can act very much like ML variant pattern matching. What I fail to see in Perl6 is the equivalent of ML variant constructors. Perhaps, you don't want to turn Perl 6 into ML just yet. :) But if it comes for almost free... -- stef
Re: scoping functions as list operators?
> "SP" == Stéphane Payrard <[EMAIL PROTECTED]> writes: SP> On Fri, Feb 25, 2005 at 03:56:06AM +0100, Stéphane Payrard wrote: >> >> Giving scoping functions the status of list operators >> would allow to drop parentheses when not used in conjunction >> with initializer so one could write: >> >> my $a, $b, $c; >> >> instead of >> >> my ($a, $b, $c); SP> Too bad that in English there is no plural for my. SP> In French it would work fine SP> mon $a; # French for C, singular SP> # C as a list operator SP> mes $a, $b, $c; # French for C, plural well, our is a form of a plural my but it is not a plural of the things that are mine/ours but rather the group owning it (which is the namespace). so we can try: all, mine, these, those, them and the brooklynese variants: dese, dose, dem. :) southern variant: y'all or yall. maybe yall is expanded as yall mine! yall $a, $b, $c = 1 .. 3 ; larry? uri PS if this gets in, i will stop being so bigoted against southern accents! :) -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: scoping functions as list operators?
Luke Palmer wrote: We have discussed making equals low precedence enough to eliminate the parentheses in the standard swap: $x, $y = $y, $x; $x, $y <== $y, $x; -- Rod Adams
Re: scoping functions as list operators?
On Thu, Feb 24, 2005 at 11:09:24PM -0500, Uri Guttman wrote: > > "SP" == Stéphane Payrard <[EMAIL PROTECTED]> writes: > > SP> On Fri, Feb 25, 2005 at 03:56:06AM +0100, Stéphane Payrard wrote: > >> > >> Giving scoping functions the status of list operators > >> would allow to drop parentheses when not used in conjunction > >> with initializer so one could write: > >> > >> my $a, $b, $c; > >> > >> instead of > >> > >> my ($a, $b, $c); > > SP> Too bad that in English there is no plural for my. > SP> In French it would work fine > > SP> mon $a; # French for C, singular > > SP> # C as a list operator > SP> mes $a, $b, $c; # French for C, plural > > well, our is a form of a plural my but it is not a plural of the things > that are mine/ours but rather the group owning it (which is the > namespace). > > so we can try: all, mine, these, those, them > and the brooklynese variants: dese, dose, dem. :) > southern variant: y'all or yall. > maybe yall is expanded as yall mine! > > yall $a, $b, $c = 1 .. 3 ; > > larry? > > uri > > PS if this gets in, i will stop being so bigoted against southern accents! :) > > -- > You have got to find a plural form for all the kind of scopes supported by Perl. Ant that gets us half-way because of the = assignement operator precedence which is wrong in your example. -- stef
Re: scoping functions as list operators?
Rod Adams writes: > Luke Palmer wrote: > > >We have discussed making equals low precedence enough to eliminate the > >parentheses in the standard swap: > > > > $x, $y = $y, $x; > > > $x, $y <== $y, $x; Heh, oh yeah. I guess I wasn't so off suggesting <-, then. Well, there's half the problem. Now we just need to determine if 'my' can leave its post as a unary declarator. Luke
Re: scoping functions as list operators?
> "LP" == Luke Palmer <[EMAIL PROTECTED]> writes: LP> Rod Adams writes: >> Luke Palmer wrote: >> >> >We have discussed making equals low precedence enough to eliminate the >> >parentheses in the standard swap: >> > >> > $x, $y = $y, $x; >> > >> $x, $y <== $y, $x; LP> Heh, oh yeah. I guess I wasn't so off suggesting <-, then. LP> Well, there's half the problem. Now we just need to determine if LP> 'my' can leave its post as a unary declarator. that fixes Stéphane's problem with my yall proposal. and yall solves the unary my problem. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: scoping functions as list operators?
Luke Palmer wrote: Now we just need to determine if 'my' can leave its post as a unary declarator. Don't see why not... If you ever need it unary, you can just put the () back in. The question becomes which is more common: Scoping a single variable in a list context, or scoping several variables at once. Likely the later. This also reminds me of the thought someone had a while back about making = not copy in list context, making people use ==>/<== for all list assignments. It would certainly take care of the : $x, $y = $y, $x; problem that will have people scratching their heads. (assuming that doesn't trigger a warning/error). Overall, I like the protection it provides, but dislike the extra three keystrokes it means for something I use so often. -- Rod Adams
Re: scoping functions as list operators?
Uri Guttman wrote: that fixes Stéphane's problem with my yall proposal. and yall solves the unary my problem. :) Stop misusing "y'all" before this Texan has to hurt you. And y'all wonder why we hate you damn yankees. Can't even speak properly up there. :-) We should instead have a list attribute, so we can say: $x, $y, $z are mine! mine! mine!; (Must be spoken like a three year old when read.) -- Rod Adams
Re: scoping functions as list operators?
> "RA" == Rod Adams <[EMAIL PROTECTED]> writes: RA> Uri Guttman wrote: >> that fixes Stéphane's problem with my yall proposal. and yall solves the >> unary my problem. :) >> >> RA> Stop misusing "y'all" before this Texan has to hurt you. RA> And y'all wonder why we hate you damn yankees. Can't even speak RA> properly up there. RA> :-) be glad your (losing) battle with damian was on email. between his VERY southern accent and yours ... :) you should try to meet him at a conf this spring/summer. RA> We should instead have a list attribute, so we can say: RA> $x, $y, $z are mine! mine! mine!; RA> (Must be spoken like a three year old when read.) but what does unary postfix ! mean? and does are distribute across mines? uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: scoping functions as list operators?
On Fri, Feb 25, 2005 at 12:54:20AM -0500, Uri Guttman wrote: > > "RA" == Rod Adams <[EMAIL PROTECTED]> writes: > > RA> Uri Guttman wrote: > >> that fixes Stéphane's problem with my yall proposal. and yall solves the > >> unary my problem. :) > >> > RA> Stop misusing "y'all" before this Texan has to hurt you. > RA> And y'all wonder why we hate you damn yankees. Can't even speak > RA> properly up there. > > RA> :-) > > be glad your (losing) battle with damian was on email. between his VERY > southern accent and yours ... :) Indeed, Damian might just say that the answer to this problem is to *again* use junctions, and eliminate the 'm' in C, leaving: y all($x, $y, $z) = 1..3; Sorry, couldn't help myself. :-) :-) :-) Pm
Re: scoping functions as list operators?
Luke Palmer wrote: > I don't think it's a good idea to make a new low precedence assignment. > Let's say we made it <-. Does that imply that there is also > low-precedence binding :<- and compile-time binding ::<- ? Those don't > look right. I think we're weighing making good ol' assignment low surely they could be <:- and <::- those look a lot nicer :) > precedence vs. having parentheses on 'my'. > > Luke TTFN, Struan
Re: scoping functions as list operators?
> "PRM" == Patrick R Michaud <[EMAIL PROTECTED]> writes: PRM> On Fri, Feb 25, 2005 at 12:54:20AM -0500, Uri Guttman wrote: >> > "RA" == Rod Adams <[EMAIL PROTECTED]> writes: >> RA> Uri Guttman wrote: >> >> that fixes Stéphane's problem with my yall proposal. and yall solves the >> >> unary my problem. :) >> >> RA> Stop misusing "y'all" before this Texan has to hurt you. RA> And y'all wonder why we hate you damn yankees. Can't even speak RA> properly up there. >> RA> :-) >> >> be glad your (losing) battle with damian was on email. between his VERY >> southern accent and yours ... :) PRM> Indeed, Damian might just say that the answer to this problem is PRM> to *again* use junctions, and eliminate the 'm' in C, leaving: PRM>y all($x, $y, $z) = 1..3; PRM> Sorry, couldn't help myself. :-) :-) :-) AAGG!! but the () snuck back in and one of the goals is to remove them. actually i like the () to mark a list context. so would it be: y all $x, $y, $z <== 1..3; and all() doesn't have ordering since it is set-like (hi rod! :), so how do 1..3 get assigned? uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
