Outlaw to declare a lexical twice in the same scope
Hello, perhaps I've missed a discussion about it, but I can't find a reason for a (IMHO infelicitous) specification. In S04 is said: If you declare a lexical twice in the same scope, it is the same lexical I would argue for: If you declare a lexical twice in the same scope, it is an error! Well, this error happens most likely due to my tiredness and I want the compiler to wake me up. This can be important because I would expect that C my $x = 7; does not change/overwrite the value of an existing $x. If I want to change the defined $x, I don't declare it again. Does anybody agree? Regards Stefan - Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
Re: Outlaw to declare a lexical twice in the same scope
On Mon, Sep 11, 2006 at 04:35:08AM -0700, Steve Lukas wrote: I would argue for: If you declare a lexical twice in the same scope, it is an error! Well, this error happens most likely due to my tiredness and I want the compiler to wake me up. This can be important because I would expect that C my $x = 7; does not change/overwrite the value of an existing $x. If I want to change the defined $x, I don't declare it again. Does anybody agree? I don't. I often will do this during early development or debugging: my $x = 'some initial state'; my $x = 'a different state'; I add the second line to try out a different code path. I do it this way rather than just change the first line to the second because: a) it's easier to restore the initialization back to its original state if I change something else, b) I won't forget to restore the initialization because I will get a warning, c) I can keep a bunch of different states in the file to try and just have to cut-and-paste to try a new one, without troubling myself with commenting out the unwanted states. Presumably you will be able to make warnings fatal as in Perl 5 so you should be able to get the behaviour you want, too. -- Rick Delaney [EMAIL PROTECTED]
Re: multi method dispatching of optional arguments (further refined)
On Mon, Sep 04, 2006 at 10:52:35PM -0700, Trey Harris wrote:
: In a message dated Tue, 5 Sep 2006, Ph. Marek writes:
: I now had a look at http://dev.perl.org/perl6/doc/design/syn/S06.html
: but didn't find what I meant. Sorry if I'm just dumb and don't
: understand you (or S06); I'll try to explain what I mean.
:
: I don't think you're dumb; the Synopses just require that you intuit
: certain things from each other, from examples in other Synopses, and so on
: in a Perlish sort of way; what you're looking for is not spelled out
: explicitly. It can be found by noticing how you specify subtypes, along
: with noticing that subtypes can be specified as parameter types. There's
: also an example showing explicitly what you want in S12.
:
: In Perl5 this looks like
:
: sub SomeThing
: {
:my($a, $b)[EMAIL PROTECTED];
:
:return b+2 if ($a == 4);
:return a+1 if ($b == 3);
:return a*b;
: }
: [...]
: What I am asking is whether there will be some multimethod dispatch
: depending
: on the *value*, not the *type*, of parameters.
: Perl6 could possibly do something with given; but matching on multiple
: variables seems to be verbose, too.
: I'm looking for something in the way of
:
: sub SomeThing(Num $a, Num $b) where $a==4 is $b+2;
: sub SomeThing(Num $a, Num $b) where $b==3 is $a+1;
: sub SomeThing(Num $a, Num $b) { return $a * $b }
:
: It's just
:
:multi sub SomeThing(Num $a where {$^a == 4}, Num $b) { $b + 2 }
:multi sub SomeThing(Num $a, Num $b where {$^b == 3}) { $a + 1 }
:multi sub SomeThing(Num $a, Num $b) { $a * $b }
:
: but without specifying the signature multiple times (or maybe we should,
: since
: it's MMD). Now
:
: Yes, the signatures are different--the first two multis specify subtypes
: as their signatures, the last specifies a canonical type.
Every scalar value is a one-element subset of its type, so you can just write:
multi sub SomeThing(Num 4, Num $b) { $b + 2 }
multi sub SomeThing(Num $a, Num 3) { $a + 1 }
multi sub SomeThing(Num $a, Num $b) { $a * $b }
or even just
multi sub SomeThing(4, Num $b) { $b + 2 }
multi sub SomeThing(Num $a, 3) { $a + 1 }
multi sub SomeThing(Num $a, Num $b) { $a * $b }
Though 3 and 4 are arguably going to match against Int rather than Num...
Larry
META vs meta
Hi all, There is currently a mismatch between S12 and Pugs. The former specifies $obj.META, the latter has implemented $obj.meta. Is there any reason I shouldn't change the tests from meta to META, make the corresponding changes in Pugs.Prim, and then fix any other examples or modules it broke? Am I missing anything else? Best, David.
Re: META vs meta
On Mon, Sep 11, 2006 at 08:59:51AM -0700, David Brunton wrote: : Hi all, : : There is currently a mismatch between S12 and Pugs. The former specifies $obj.META, the latter has implemented $obj.meta. .META is more correct at the moment. : Is there any reason I shouldn't change the tests from meta to META, make the corresponding changes in Pugs.Prim, and then fix any other examples or modules it broke? : : Am I missing anything else? Only that I'm thinking of renaming all the meta-ish methods to use interrogative pronouns: .META - .HOW .SKID - .WHO .PKG- .WHAT .VAR- .WHERE or some such. Not sure what .WHEN or .WHY would mean offhand... Another possible scheme is to keep .META and have .WHO, .WHAT, etc. default to .META.WHO, .META.WHAT, etc. (Delegated by Object, presumably.) Not sure if the added flexibility of allowing override of bare .WHO etc. buys us anything though. Also, arguably VAR() is in a different category entirely. In which case .WHERE might be the full package name, and .WHAT the short name. Larry
Re: Outlaw to declare a lexical twice in the same scope
Steve Lukas skribis 2006-09-11 4:35 (-0700): If you declare a lexical twice in the same scope, it is the same lexical I would argue for: If you declare a lexical twice in the same scope, it is an error! I agree. The reason that I love my $foo is that it always gives me a new variable. I can safely use this anywhere in the code, without any need to read all the existing code. This is, for me, one of the most important aspects of having lexicals in the language: I can add (debugging or otherwise temporary) code to any existing project without getting to know the structure of the project's code. Perl 5 warns that a second declaration masks the first. This is fine: it tells me about the stupid mistake I made and lets me fix it. A compile error would be fine too. In fact, even better because then my probably broken code isn't executed then. Just ignoring the declaration is bad, just like implicit declaration. If we do this, we get only typo checking, and none of the other nice protection that lexical declaration gives us. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: META vs meta
On 9/11/06, Larry Wall wrote: Only that I'm thinking of renaming all the meta-ish methods to use interrogative pronouns: .META- .HOW .SKID- .WHO .PKG - .WHAT .VAR - .WHERE .WHO and .WHAT strike me as better being swapped. Maybe... or some such. Not sure what .WHEN or .WHY would mean offhand... I'd say .WHY should return a chunk of POD representing the associated documentation. Also, arguably VAR() is in a different category entirely. In which case .WHERE might be the full package name, and .WHAT the short name. In that case, .WHO definitely makes more sense for the name. -David
Re: META vs meta
On Mon, Sep 11, 2006 at 10:59:20AM -0600, David Green wrote: : In that case, .WHO definitely makes more sense for the name. I don't see it. Who I am is my identity. What I am is a Person or some such. Larry
Re: Reduced assignment operator?
On Mon, Sep 11, 2006 at 11:58:28AM +0800, Audrey Tang wrote: : Consider these cases: : [=] $x, $y, $z; : [+=] $a, $b, $c; : : S03 is currently inconsistent. It first says these are not supported: : : The final metaoperator in Perl 6 is the reduction operator. Any : infix operator (except for non-associating operators and assignment : operators) can be surrounded by square brackets in term position to : : But then implies it is on the defaulting table below: : : [=]() # undef(same for all assignment operators) : : I don't see an obvious problem in supporting them as a syntactic : expansion. Except that the left side of an = determines the scalar/list parsing of the right side, while reduce operators are all list ops, at least syntactically. So should this: [=] $x, @y, 0 mean this: $x = @y = 0; or should it mean this: $x = @y[0] = @y[1] = @y[2] ... = 0; : But would it be useful? And is there some hidden corners that I missed? Seems like [=] @x, 0 is vaguely useful if we take the latter interpretation. (And I do think that's the correct interpretation.) But maybe that's better written as @x »=« 0 in any case. On the other hand, I'm not sure how else you'd write [+=] @x, 0 Maybe @x = reverse [\+] reverse @x; So I guess we can allow [=] and friends, provided it's understood that no LHS dwimmery is done. Larry
Re: META vs meta
On Mon, Sep 11, 2006 at 09:18:19AM -0700, Larry Wall wrote: : .PKG - .WHAT I should have said .ref- .WHAT there, since it was the intention to rename .ref that brought all this on in the first place. (And what you actually get from .WHAT is the prototype object that stringifies to the package name.) In any case, .ref is bogus in a language that doesn't have references. Its use as typeof in Perl 5 was something of an accident. And its boolean use is bogus whether you view Perl 6 as mandating all references or no references. Or however you say that in English... Larry
Re: but semantics (was Re: Naming the method form of s///)
On Mon, Sep 04, 2006 at 08:54:02PM +0200, TSa wrote:
: But are assignment ops allowed as initializer?
:
: my $z = $p but= { .y = 17 };
Why not? It's only the first = that's potentially special. (And it's
only for non-my, since my's = is an ordinary assignment at normal
run time.) I don't see much syntactic difference between your example and
state $z = $p += 17;
The fact that both of them modify $p in passing is unrelated to the
eventual use of the value to initialize something else.
Larry
Re: but semantics (was Re: Naming the method form of s///)
On Mon, Sep 11, 2006 at 11:12:00AM -0700, Larry Wall wrote:
: On Mon, Sep 04, 2006 at 08:54:02PM +0200, TSa wrote:
: : But are assignment ops allowed as initializer?
: :
: : my $z = $p but= { .y = 17 };
:
: Why not? It's only the first = that's potentially special. (And it's
: only for non-my, since my's = is an ordinary assignment at normal
: run time.) I don't see much syntactic difference between your example and
:
: state $z = $p += 17;
:
: The fact that both of them modify $p in passing is unrelated to the
: eventual use of the value to initialize something else.
Well, okay, I should clarify that. The meaning of $p += 17 is
unrelated. However, the declarator before the = does control when
and how often that expression is evaluated.
Larry
Re: Outlaw to declare a lexical twice in the same scope
Steve (): If you declare a lexical twice in the same scope, it is the same lexical I would argue for: If you declare a lexical twice in the same scope, it is an error! I agree. Enforcing one and only one declaration feels like a Good Thing, for Juerd's reasons. With me, multiple 'my' for the same variable is usually a copy-and-paste error -- one that I would want to catch. So I wouldn't mind getting a compile-time error, actually. // masak
Re: not and true appear unspec'ed, too
Mark Stosberg wrote: The formal definition of Inf appears to be missing from the spec documents. Since I'm not exactly sure how Perl 6 treats Inf, I'll leave submitting this patch to someone else. Once the spec is added, a smart link to it should be added from: t/builtins/math/infinity.t Along the same lines, I couldn't find a spec for either not or true, which both have passing tests for pugs in t/builtins/bool/ Mark
Re: Inf appears to be unspec'ed
Mark Stosberg wrote: The formal definition of Inf appears to be missing from the spec documents. Since I'm not exactly sure how Perl 6 treats Inf, I'll leave submitting this patch to someone else. Once the spec is added, a smart link to it should be added from: t/builtins/math/infinity.t TimToady caught me on IRC and pointed out where Inf, not and true are mentioned in the spec, if only briefly. Smart links have been added for them now. Mark
