Re: [svn:perl6-synopsis] r8572 - doc/trunk/design/syn
> "a" == autrijus <[EMAIL PROTECTED]> writes: a> +In numeric context (i.e. when casted into C or C), a Hash object s/casted/cast/. i caught this one the other day. looks like the lesson didn't take so we will have to punish you. you must rewrite pugs in python! MUAHAHAHAHAH!!! a> +becomes the number of pairs contained in the hash. In a boolean context, a a> +Hash object is true if there are any pairs in the hash. In either case, a> +any intrinsic iterator would be reset. (If hashes do carry an intrinsic a> +iterator (as they do in Perl 5), there will be a C<.reset> method on the h dangling 'h'. a> +hash object to reset the iterator explicitly.) uri, the very punishing grammar nazi. -- 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
[svn:perl6-synopsis] r8593 - doc/trunk/design/syn
Author: autrijus
Date: Thu Apr 6 01:12:52 2006
New Revision: 8593
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S13.pod
Log:
* S02/S13: s/casted/cast/, as suggested by Uri.
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podThu Apr 6 01:12:52 2006
@@ -500,11 +500,11 @@
=item *
-In numeric context (i.e. when casted into C or C), a Hash object
+In numeric context (i.e. when cast into C or C), a Hash object
becomes the number of pairs contained in the hash. In a boolean context, a
Hash object is true if there are any pairs in the hash. In either case,
any intrinsic iterator would be reset. (If hashes do carry an intrinsic
-iterator (as they do in Perl 5), there will be a C<.reset> method on the h
+iterator (as they do in Perl 5), there will be a C<.reset> method on the
hash object to reset the iterator explicitly.)
=item *
Modified: doc/trunk/design/syn/S13.pod
==
--- doc/trunk/design/syn/S13.pod(original)
+++ doc/trunk/design/syn/S13.podThu Apr 6 01:12:52 2006
@@ -120,7 +120,7 @@
=head1 Type Casting
A class can use the C<< *infix: >> submethod to declare that its objects
-can be casted to some other class:
+can be cast to some other class:
multi submethod *infix: (IO) { $*OUT }
multi submethod *infix: (Int) { 1 }
Re: [svn:perl6-synopsis] r8562 - doc/trunk/design/syn
> +If this MMD dispatch succeeds, the result becomes the result of the > +of the reduce. "MMD dispatch" ~~ "RAS syndrome" Also note the two "of the"s. > +Otherwise, if the MMD dispatch fails, then if there is one argument, > +while the single argument form can MMD dispatch based on the type of Ditto RAS. Dan, Uri's grammar Lord Haw Haw -- "It must be accepted as a principle that the rifle, effective as it is, cannot replace the effect produced by the speed of the horse, the magnetism of the charge, and the terror of cold steel." -- British Cavalry training manual, 1907 ::: http://surreal.istic.org/ pgpUYDLifjxyA.pgp Description: PGP signature
[svn:perl6-synopsis] r8594 - doc/trunk/design/syn
Author: autrijus Date: Thu Apr 6 01:29:34 2006 New Revision: 8594 Modified: doc/trunk/design/syn/S03.pod Log: * More grammar nits, from Daniel Hulme Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podThu Apr 6 01:29:34 2006 @@ -219,10 +219,10 @@ If fewer than two arguments are given, one MMD attempt is made to dispatch to the operator anyway with whatever arguments are given. -If this MMD dispatch succeeds, the result becomes the result of the -of the reduce. +If this multi-dispatch succeeds, the result becomes the result of the +reduce. -Otherwise, if the MMD dispatch fails, then if there is one argument, +Otherwise, if the dispatch fails, then if there is one argument, that argument is returned. However, this default doesn't make sense for an operator like C<< < >> that doesn't return the same type as it takes, so these kinds of operators overload the single-argument case
Re: [svn:perl6-synopsis] r8573 - doc/trunk/design/syn
HaloO, [EMAIL PROTECTED] wrote: * S02: fix the three places where the old form: $x .(...) needs to be replaced to the new form: $x. (...) -&foo.($arg1, $arg2); +&foo. ($arg1, $arg2); What is the reason for this change? I find the old definition of whitespace before the dot much more pleasing. The trailing dot looks somewhat lost and does not link to the arglist visually while the preceding dot in .() made it look like a method that binds leftwards. Same asthetics apply to postfix ops where $x .++; looks better to my eyes than $x. ++; Does the same apply for method calls? $x. foo; I've always seen the method dot as a kind of pseudo sigil. A metapher that doesn't work with whitespace between dot and identifier. --
Re: [svn:perl6-synopsis] r8573 - doc/trunk/design/syn
[EMAIL PROTECTED] skribis 2006-04-05 22:30 (-0700): > Whitespace is not allowed before the parens, but there is a corresponding > -C<.()> operator, which allows you to insert optional whitespace before the > dot: > +C<.()> operator, which allows you to insert optional whitespace after the > dot: > -&foo.($arg1, $arg2); > +&foo. ($arg1, $arg2); If done consistently, this destroys the sane multiline markup: $foo .bar(...) .baz(...) .quux(...) And I'd really hate to be forced to use this instead: $foo. bar(...). baz(...). quux(...) because then you lose visual indication that bar, baz, and quux are methods (rather than functions), and the . and the end of a line is visually lost and probably easily forgotten. Plus, I don't like continuation characters at all. Please reconsider. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: [svn:perl6-synopsis] r8573 - doc/trunk/design/syn
Juerd wrote: +C<.()> operator, which allows you to insert optional whitespace after the dot: -&foo.($arg1, $arg2); +&foo. ($arg1, $arg2); Please reconsider. We can't. The problem is that: foo .bar has to mean: foo($_.bar) So the only way to allow whitespace in dot operations is to put it after the dot. Damian
Re: [svn:perl6-synopsis] r8573 - doc/trunk/design/syn
Damian Conway skribis 2006-04-06 20:41 (+1000): > >Please reconsider. > We can't. The problem is that: > foo .bar > has to mean: > foo($_.bar) > So the only way to allow whitespace in dot operations is to put it after > the dot. Given the consequences of this constraint, I think that perhaps (probably!) sticking to foo .bar having to mean foo $_.bar is a bad idea. Parens could effectively break the method name parsing. I don't like typing parens, but I still like typing parens much better than breaking a few of the most important principles in my syntax style. And in this case, I think it breaks almost everyone's syntax style, not just that of a few. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: [svn:perl6-synopsis] r8573 - doc/trunk/design/syn
Juerd schreef: > autrijus: >> -&foo.($arg1, $arg2); >> +&foo. ($arg1, $arg2); > [...] > Please reconsider. Yes, please come up with a different character to bridge/cross/hide/cloak/skip/zap the succeeding "not allowed" whitespace. Maybe the "\", making "\" mean "s:s/\s+//". -- Groet, Ruud
Re: [svn:perl6-synopsis] r8573 - doc/trunk/design/syn
HaloO, Damian Conway wrote: We can't. The problem is that: foo .bar has to mean: foo($_.bar) So the only way to allow whitespace in dot operations is to put it after the dot. The obvious alternative is to make 'foo .bar' simply mean 'call foo and dispatch .bar on the return value'. The topic comes into play only if there's no syntactical invocant. Kind of last resort fallback to $_ before 'method on void' error. Why should the dispatch on topic get such a privilege? Note that a prominent, typical foo actually reads: self .bar; And a self($_.bar) is pretty much useless. In other words wrongly huffmanized. --
Re: [svn:perl6-synopsis] r8569 - doc/trunk/design/syn
Subversion logging messages like the one below seem to be flooding this
list right now. May I ask if that's what this list is for?
Best wishes,
Rutger
[EMAIL PROTECTED] wrote:
Author: autrijus
Date: Wed Apr 5 19:08:28 2006
New Revision: 8569
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S05.pod
Log:
* S02/S05: Excise "reference" from them.
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podWed Apr 5 19:08:28 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 10 Aug 2004
- Last Modified: 1 Apr 2006
+ Last Modified: 6 Apr 2006
Number: 2
- Version: 19
+ Version: 20
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -326,13 +326,13 @@
Sigils are now invariant. C<$> always means a scalar variable, C<@>
an array variable, and C<%> a hash variable, even when subscripting.
-Array and hash variable names in scalar context automatically produce
-references.
+Variables such as C<@array> and C<%hash> in scalar context simply
+returns themselves Array and Hash objects.
=item *
-In string contexts container references automatically dereference
-to appropriate (white-space separated) string values. In numeric
+In string contexts, container objects automatically stringify to
+appropriate (white-space separated) string values. In numeric
contexts, the number of elements in the container is returned.
In boolean contexts, a true value is returned if and only if there
are any elements in the container.
@@ -354,7 +354,7 @@
=item *
-Subscripts now consistently dereference the reference produced by
+Subscripts now consistently dereference the container produced by
whatever was to their left. Whitespace is not allowed between a
variable name and its subscript. However, there is a corresponding
B form of each subscript (C<@foo.[1]> and C<%bar.{'a'}>) which
@@ -380,9 +380,9 @@
There is a need to distinguish list assignment from list binding.
List assignment works exactly as it does in Perl 5, copying the
values. There's a new C<:=> binding operator that lets you bind
-names to array and hash references without copying, just as subroutine
-arguments are bound to formal parameters. See S06 for more about
-parameter binding.
+names to Array and Hash objects without copying, in the same way
+as subroutine arguments are bound to formal parameters. See S06
+for more about parameter binding.
=item *
@@ -442,12 +442,11 @@
=item *
-Unlike in Perl 5, the notation C<&foo> merely creates a reference
-to function "C" without calling it. Any function reference may
-be dereferenced and called using parens (which may, of course,
-contain arguments). Whitespace is not allowed before the parens,
-but there is a corresponding C<.()> operator, which allows you to
-insert optional whitespace before the dot.
+Unlike in Perl 5, the notation C<&foo> merely returns the C
+function as a Code object without calling it. You may call any Code
+object parens (which may, of course, contain arguments). Whitespace
+is not allowed before the parens, but there is a corresponding C<.()>
+operator, which allows you to insert optional whitespace before the dot.
=item *
@@ -457,7 +456,7 @@
&foo:(Int,Num)
-It still just returns a function reference. A call may also be partially
+It still just returns a C object. A call may also be partially
applied by using an argument list literal as a postfix operator:
&foo\(1,2,3,:mice)
@@ -496,12 +495,11 @@
=item *
-A hash reference in numeric context returns the number of pairs
-contained in the hash. A hash reference in a boolean context returns
-true if there are any pairs in the hash. In either case, any intrinsic
-iterator would be reset. (If hashes do carry an intrinsic iterator
-(as they do in Perl 5), there will be a C<.reset> method on the hash
-object to reset the iterator explicitly.)
+In numeric context, a Hash object returns the number of pairs contained
+in the hash. Hash in a boolean context returns true if there are any pairs
+in the hash. In either case, any intrinsic iterator would be reset. (If
+hashes do carry an intrinsic iterator (as they do in Perl 5), there will
+be a C<.reset> method on the hash object to reset the iterator explicitly.)
=item *
@@ -647,7 +645,7 @@
=item *
-The current lexical symbol table may now be referenced through the
+The current lexical symbol table is now accessible through the
pseudo-package C. The current package symbol table is visible as
pseudo-package C. The C name refers to the C symbol table
immediately surrounding the current C, and C is the one
@@ -1400,12 +1398,12 @@
numeric num Num +
string str Str ~
-There are also various reference contexts that require particular kinds of
-container referen
Re: [svn:perl6-synopsis] r8569 - doc/trunk/design/syn
On Wed, Apr 05, 2006 at 07:24:30PM -0700, Rutger Vos wrote: > Subversion logging messages like the one below seem to be flooding this > list right now. May I ask if that's what this list is for? Well, it gets the people interested in the language design first cut at the changes being made to the design docs. Which is, IMHO, part of what this list is for. That way the group can fix typoes or if there's some weird semantic, the group can send a "whoa there!" message. How else are we to keep abreast of changes in the design docs? Repeated reading of the website and hoping we notice when things change? Sending the log + diff gives an easy way to brain-filter the messages too. I can look at the log and decide if I really care about the minute changes to twigils enough to read through all of the places where it makes a difference. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: [svn:perl6-synopsis] r8573 - doc/trunk/design/syn
TSa wrote: > Note that a prominent, typical foo actually reads: > > self .bar; > > And a self($_.bar) is pretty much useless. In other words > wrongly huffmanized. FWIW, I agree with both points. Some more points: * I think both "say(.meth)" or ".meth.say" are more succinct/readable than "say .meth" for "say($_.meth)". * "say() .meth" is a parsefail according to the new rules, but can be quite useful to align things up. I committed r8573 only because of r8563 changed the dot/whitespace interaction, which caused inconsistencies in other parts of the example... The old interaction rules imho is quite easier to explain. Audrey signature.asc Description: OpenPGP digital signature
Re: [svn:perl6-synopsis] r8573 - doc/trunk/design/syn
On Thu, Apr 06, 2006 at 10:18:48PM +0800, Audrey Tang wrote: : TSa wrote: : > Note that a prominent, typical foo actually reads: : > : > self .bar; : > : > And a self($_.bar) is pretty much useless. In other words : > wrongly huffmanized. : : FWIW, I agree with both points. Some more points: : : * I think both "say(.meth)" or ".meth.say" are more succinct/readable : than "say .meth" for "say($_.meth)". : * "say() .meth" is a parsefail according to the new rules, but can be : quite useful to align things up. : : I committed r8573 only because of r8563 changed the dot/whitespace : interaction, which caused inconsistencies in other parts of the : example... The old interaction rules imho is quite easier to explain. Okay, we could revert it, and .foo would remain term/operator sensitive, and retroactively eat preceding whitespace when an operator is expected. Just so you realize that it will make missing operators errors harder to notice, particularly missing semicolon or comma. There have to be some spots in the grammar that enforce synchronization by being syntax errors, or we really will end up with a language that can parse line noise. Another option would be to duplicate the . on both ends of the whitespace when you want a delayed postfix: say. .foo. .[32]; Somebody please point out all the downsides to this approach. But you're only allowed to count "I'm not used to it yet" once. :-) Larry
Re: [svn:perl6-synopsis] r8573 - doc/trunk/design/syn
[EMAIL PROTECTED] wrote: We can't. The problem is that: foo .bar has to mean: foo($_.bar) So the only way to allow whitespace in dot operations is to put it after the dot. Damian I believe Larry's latest updates to Synopses allow for some syntactic categories to be disabled in certain context, and to allow priorities between categories. So would this make sense? -- - C<.bar> can be successfully parsed as both method call (postfixish something?) and term - when postfix is disallowed, such as at the beginning of an expression or after a paren, C<.bar> is a term and means C<$_.bar> - otherwise, it's a method call, and to get C you have to at least say C -- requiring this actually seems more readable to me. Miro
Re: [svn:perl6-synopsis] r8573 - doc/trunk/design/syn
Larry Wall skribis 2006-04-06 9:01 (-0700): > Okay, we could revert it, and .foo would remain term/operator sensitive, > and retroactively eat preceding whitespace when an operator is expected. Or change the definition so that something that looks like a method call IS a method call, and that you have to put something else in between (like parens) to avoid it. So .bar; # $_.bar foo.bar;# foo.bar foo .bar; # foo.bar foo().bar; # foo.bar foo(.bar); # foo($_.bar) foo ~.bar; # foo(~$_.bar) foo *.bar; # foo(*.bar) That makes the parsing entirely predictible. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Spaced Out (Was Re: [svn:perl6-synopsis] r8573 - doc/trunk/design/syn)
On 4/6/06, Larry Wall wrote: On Thu, Apr 06, 2006 at 10:18:48PM +0800, Audrey Tang wrote: : TSa wrote: : > And a self($_.bar) is pretty much useless. In other words : > wrongly huffmanized. : : FWIW, I agree with both points. I agree with those points too, but not necessarily the conclusion. Sometimes Huffman is trumped by the principle of Knowing What the Heck is Going On. Just so you realize that it will make missing operators errors harder to notice, particularly missing semicolon or comma. There have to be some spots in the grammar that enforce synchronization by being syntax errors, or we really will end up with a language that can parse line noise. Yes. I like cute context tricks for their aesthetic elegance, but I also like Perl 6's attempts to cut down on the number of rules I need to memorise in order to parse stuff correctly in my head. Another option would be to duplicate the . on both ends of the whitespace when you want a delayed postfix: say. .foo. .[32]; Somebody please point out all the downsides to this approach. But you're only allowed to count "I'm not used to it yet" once. :-) Since my first thought was something like that, I'm already getting used to it! Well, what I actually thought of was: foo... ...[32] ...because the longer "..." draws more attention to the fact that you're only seeing half the picture. But perhaps the pattern should be more like ...+\s*...+ so you can say: foo[32], bar.[0], sphygmomanometry...[120/80]; -David "probably not serious about that" Green
Re: [svn:perl6-synopsis] r8573 - doc/trunk/design/syn
"Ruud H.G. van Tol" schreef: > Juerd: >> autrijus: >>> -&foo.($arg1, $arg2); >>> +&foo. ($arg1, $arg2); >> [...] >> Please reconsider. > > Yes, please come up with a different character to > bridge/cross/hide/cloak/skip/zap the succeeding "not allowed" > whitespace. > > Maybe the "\", making "\" mean "s:s/\s+//". Rather an inline "s/[\]\s+//" source filter (for code). $foo\.bar(...)\.baz(...)\.quux(...) It will often look like a continuation character: $foo\ .bar(...)\ .baz(...)\ .quux(...) and should be able to eat to the left too: $foo \ .bar(...) \ .baz(...) \ .quux(...) The "#" is an alternative, and promotes multiline outlining, if you make it mean: remove everything after it until the end of the line, and itself with all whitespace in front of it, and all whitespace from the end of the current line up to the first \S (or EOF). $foo # .bar(...) # .baz(...) # .quux(...) ;) -- Affijn, Ruud "Gewoon is een tijger."
$a.foo() moved?
All~ I just noticed something claiming that C<$a. foo()> is actually C<$a.foo()> (a method call on C<$a>) and that C<$a .foo()> is actually C<$a $_.foo()> (likely a syntax error). When did this change? Why did this change? Also, I liked it better when C<$a .foo()> was a method call on C<$a>. Thanks, Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -Stan Kelly-Bootle, The Devil's DP Dictionary
Re: $a.foo() moved?
On Thu, Apr 06, 2006 at 01:58:55PM -0400, Matt Fowles wrote: : All~ : : I just noticed something claiming that C<$a. foo()> is actually : C<$a.foo()> (a method call on C<$a>) and that C<$a .foo()> is actually : C<$a $_.foo()> (likely a syntax error). : : When did this change? Why did this change? It changed at the last hackathon, but is still being debated, mostly on #perl6. The current S02 "early dot" rule is likely being abandoned, but we don't know for what yet. The reason is that term/operator lexer state is interacting badly with inconsistent retroactive whitespace cancellation. : Also, I liked it better when C<$a .foo()> was a method call on C<$a>. Sure, that one might be obvious, but quick, tell me what these mean: say .bar say .() say .1 when .bar when .() when .1 foo .bar foo .() foo .1 .foo .bar .foo .() .foo .1 I'd rather have a rule you don't have to think about so hard. To me that implies something simple that let's you put whitespace *into* a postfix without violating the "postfixes don't take preceding whitespace" rule. Larry
Re: $a.foo() moved?
Larry~ On 4/6/06, Larry Wall <[EMAIL PROTECTED]> wrote: > On Thu, Apr 06, 2006 at 01:58:55PM -0400, Matt Fowles wrote: > : All~ > : > : I just noticed something claiming that C<$a. foo()> is actually > : C<$a.foo()> (a method call on C<$a>) and that C<$a .foo()> is actually > : C<$a $_.foo()> (likely a syntax error). > : > : When did this change? Why did this change? > > It changed at the last hackathon, but is still being debated, mostly > on #perl6. The current S02 "early dot" rule is likely being abandoned, > but we don't know for what yet. The reason is that term/operator > lexer state is interacting badly with inconsistent retroactive > whitespace cancellation. > > : Also, I liked it better when C<$a .foo()> was a method call on C<$a>. > > Sure, that one might be obvious, but quick, tell me what these mean: > > say .bar > say .() > say .1 > when .bar > when .() > when .1 > foo .bar > foo .() > foo .1 > .foo .bar > .foo .() > .foo .1 > > I'd rather have a rule you don't have to think about so hard. To me > that implies something simple that let's you put whitespace *into* > a postfix without violating the "postfixes don't take preceding > whitespace" rule. That makes a good deal of sense. I don't know what I would like more, so I guess that I will wait till a more firm consensus is reached. Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -Stan Kelly-Bootle, The Devil's DP Dictionary
Re: $a.foo() moved?
On Thu, Apr 06, 2006 at 02:35:53PM -0400, Matt Fowles wrote: : That makes a good deal of sense. I don't know what I would like more, : so I guess that I will wait till a more firm consensus is reached. The current consensus on #perl6 is that, in postfix position only (that is, with no leading whitespace), m:p/\.+ \s / lets you embed arbitrary whitespace, comments, pod, etc, within the postfix operator. This allows both the short :foo. .() as well as the longer $x... .foo() Or possibly m:p/ [ \.+ \s ]+/, which would let you intermix as many dots into the whitespace as you like: $x. . . . . .() But that's a little out there. In any event $x..$y is still a range because there's no whitespace after .. and $x .. $y is still a range *because* there's whitespace before. The only casualty is $x... with trailing whitespace can't mean $x..Inf. But you almost always want to put something like a comma or bracket after it anyway. And the nice thing is that it becomes a drop-dead simple rule that postfix operators never, ever have leading whitespace, and you can always distingish an infix operator from a postfix by whitespace. No more retroactive guessing games. It's possible the $x... infinite range operator could be recast to something else like $x..* or some such, but that's a niggle compared to the enormity of cleaner parsing. Larry
Re: $a.foo() moved?
On Thu, Apr 06, 2006 at 12:10:18PM -0700, Larry Wall wrote: > The current consensus on #perl6 is that, in postfix position only (that > is, with no leading whitespace), m:p/\.+ \s / lets you embed > arbitrary whitespace, comments, pod, etc, within the postfix operator. > > This allows both the short > > :foo. .() > > as well as the longer > > $x... > .foo() The one quibble I see with this is that postfix might be a touch confusing with infix (i.e. the yada operator). Depending upon context "..." can thus be either an error (code not yet written) or layout control and valid to "execute" (I put execute in quotes because by the time you get around to executing the code the ... will have served it purpose of controlling the parsing and be gone). (This is just the one-shot "I'm not used to it yet" vote. :-) --
Re: $a.foo() moved?
On Thu, Apr 06, 2006 at 03:38:59PM -0400, John Macdonald wrote:
> On Thu, Apr 06, 2006 at 12:10:18PM -0700, Larry Wall wrote:
> > The current consensus on #perl6 is that, in postfix position only (that
> > is, with no leading whitespace), m:p/\.+ \s / lets you embed
> > arbitrary whitespace, comments, pod, etc, within the postfix operator.
> >
>
> The one quibble I see with this is that postfix dots, including 3> might be a touch confusing with infix 3 dots> (i.e. the yada operator).
There isn't an infix:<...> operator. There's
term:<...> ("yada yada yada"), and there's
postfix:<...> ("$x..Inf").
Pm
Re: 'temp $x;' with no assignment
On 3/27/06, Larry Wall <[EMAIL PROTECTED]> wrote: > On Mon, Mar 27, 2006 at 02:54:05PM -0600, Jonathan Scott Duff wrote: > : On Mon, Mar 27, 2006 at 10:46:02PM +0200, Yuval Kogman wrote: > : > On Mon, Mar 27, 2006 at 14:35:52 -0600, Jonathan Scott Duff wrote: > : > > I think that if C is the new C, then immediately after the > : > > C line, $x should hold whatever flavor of undef is appropriate. > : > > > : > > Is there some reason we're huffmannizing > : > > : > > : > Because 90% of the code that people use local for in perl 5 is for > : > counting levels and automatically unwrapping them. The other 10% are > : > for more complex values. > : > : Make me believe your 90/10 numbers. > > Doesn't matter what the numbers are, it's the right thing to do. > The default undef hack stems from the days when local() was trying > to fill the role of my() as well. Nowadays temp() should just > mean: "Please arrange to restore yourself to your current value" > and nothing more. (Well, plus the notion that, when applied to a > mutator, the save/restore instruction is passed on to the mutatee to > save itself before the mutation, not after.) > > The p5-to-p6 translator will turn > > local $x; > > into > > temp undefine $x; > > Larry > In order not do do some strange magic could you jsut do: temp($x)++; That seems clear and non magical to me. Just my 2 cents! ;) -- -- __ Eric Hodges
Re: 'temp $x;' with no assignment
On 3/27/06, Larry Wall <[EMAIL PROTECTED]> wrote: > The p5-to-p6 translator will turn > > local $x; > > into > > temp undefine $x; Are you sure that that's not: undefine temp $x; It seems to me that the other way would undefine $x and then temporize it. Luke
On signatured code attributes of a class
Can you do this? (Forgive synatical errors; I'm a bit behind on this.)
class Foo { has Code:( Str, Str --> Num ) &.somecode }
my Foo $blah .= new :somecode{ $^x cmp $^y }
my Int $x = 2;
my Num $y = Inf;
$blah.somecode( $x, $y );
Does construction of $blah fail because { $^x cmp $^y } doesn't have a
signature of :(Str, Str --> Num)? If not, does $blah.somecode($x, $y) fail
because of type mismatching? (Or is coercion attempted?) And would the
result of { $^x cmp $^y } be evaluated in numeric context? Or is the above
simply wrong?
Thanks in advance.
Postscript: It seems like a lot is happening on #perl6. It's so fast, and
often so divergent, that it would be extremely useful for some guy to
summarize what's happening on it regularly. A thought.
Re: $a.foo() moved?
On Thu, Apr 06, 2006 at 02:49:33PM -0500, Patrick R. Michaud wrote:
> On Thu, Apr 06, 2006 at 03:38:59PM -0400, John Macdonald wrote:
> > On Thu, Apr 06, 2006 at 12:10:18PM -0700, Larry Wall wrote:
> > > The current consensus on #perl6 is that, in postfix position only (that
> > > is, with no leading whitespace), m:p/\.+ \s / lets you
> > > embed
> > > arbitrary whitespace, comments, pod, etc, within the postfix operator.
> > >
> >
> > The one quibble I see with this is that postfix > dots, including 3> might be a touch confusing with infix > 3 dots> (i.e. the yada operator).
>
> There isn't an infix:<...> operator. There's
> term:<...> ("yada yada yada"), and there's
> postfix:<...> ("$x..Inf").
Hmm, yep I got the terminology wrong, but my point remains -
one operator that is "...", exactly 3 dots, and another that
can be "..." but can be spelled with a different number of
dots if you feel like it, is somewhat confusing.
--
