Michael Lazzaro writes:
>
> Think, think. What do these things have in common?
>
> # known from A4
>
> for @a, sub ($x) {...} # primitive spelling
> for @a -> $x {...} # pointy sub, looks great
>
> map {...} @a # old-style map syntax
>
Damian Conway writes:
>
> There's no second iterator. Just C walking through an array.
>
( questions in the form of answers :-)
so :
* "for" impose array context for first argument and doesnt care about
"nature" of the array which it was given eventually as an argument .
no multiple st
Damian Conway writes:
> David Wheeler asked:
>
> > How will while behave?
>
> C evaluates its first argument in scalar context, so:
>
>
> > while <$fh> {...}# Iterate until $fh.readline returns EOF?
>
> More or less. Technically: call <$fh.next> and execute the loop
> body i
Larry Wall <> writes:
>
> It would be really funny to use cent ¢, pound £, or yen ¥ as a
> sigil, though...
>
> > C'mon, everybody's doing it! First one's free, kid... ;-)
>
> People who believe slippery slope arguments should never go skiing.
>
just (re)reading *old* threads :
Luke Palmer writes:
>
> for parallel(<>, 0..Inf) -> $line, $count {
> FIRST { $line //= "#!/usr/bin/perl" }
> # processing...
> NEXT { print STDERR "Next line...\n" }
> LAST { print STDERR "Done\n" }
> }
>
>
> Also, keep in mind that that C function can be any (p
Damian Conway writes:
> Micholas Clarke asked:
>
> > If a subroutine explicitly needs access to its invocant's topic, what is so
> > wrong with having an explicit read-write parameter in the argument list that
> > the caller of the subroutine is expected to put $_ in?
>
> Absolutely nothin
Larry Wall writes:
> Correct, $_ is always lexical. But...
>
> : or * will it be implicitely "my $_" -- class/package lexical
>
> There's no such thing as a "class/package lexical". I think you
> mean file-scoped lexical here.
ooo, now I understand : *scope* is orthogonal concept to cl
Piers Cawley writes:
>
> FMTWYENTK about ":="
> Bravely declining to expand the acronym in his subject, arcardi posted a
> summary of his current understanding of the behavior of ":=", the
its "far more then what you ever need to know"
and after Damian Conway answer it becomes JEOWY
Timothy S. Nelson writes:
> Hi all. I hope this hasn't been discussed before. I Googled for
> "perl6 meta-operators" and found nothing; likewise practically
> nothing searching the perl6-language archive for meta-operators.
>
> Question: are there any plans to have user-defined met
Me writes:
> Sorta. To quote an excellent summary:
>
> "Topic is $_".
>
>
>
> > is $_ always lexical variable.
>
> Yes.
>
>
> > Or I can have $MyPackage::_ ?
>
> You can copy or alias any value.
>
so if I understand correctly ,
Every topicalizer defines a top
Larry Wall <> writes:
> But at the moment I'm thinking there's something wrong about any
> approach that requires a special character on the signature side.
> I'm starting to think that all the convolving should be specified
> on the left. So in this:
>
> for parallel(@x, @y, @z) -> $x
Me writes:
> In the hope this saves Allison time, and/or
> clarifies things for me, I'll attempt some
> answers.
>
Thanks .
> > In your article at perl.com you describes
> > various ways and situations when perl
> > creates a topic and this is described as
> > perl making the following
I just want to be sure I understand correctly :
In your article at perl.com you describes various ways and situations
when perl creates a topic and this is described as perl making the
following binding on my behalf:
$_ := $some_var ; *1*
and probably marking $_ with some additional properti
Peter Haworth writes:
>
> @a ^[alpha_op] +3
>
> You can parse this in two ways:
> * "array a", "hyperop alpha_op", "unary plus", "literal 3"
> * "array a", "binary xor", "call alpha_op and put result in arrayref",
>"binary plus", "literal 3"
>
I think this was already discusse d
this is not a description or definition of something. It is just set
of questions and confusions that I have when I encounter words like
"variable" , "name" , "alias", "assign" in perl . In the form of
explanation. But actually these are questions .
so , what follows is not the "how it actuall
Luke Palmer writes:
>
> What _are_ you talking about. IIRC, there were never any plans for
> such a "placeholder." There were the placeholder _variables_, $^x et
> al., but the underscore was never used for such a thing. That could
> be why I've been so confused by some of your examples.
Ed Peschko writes:
> I agree with all that you said above, I'm just saying we should make typing []
> *optional*. 99% of the time, people are not going to need it, as they are not
> defining their own operators as you did above.
>
> Ed
>
>
long ago ( when xor was "!" and ^ was called h
Larry Wall <> writes:
> On Fri, Nov 01, 2002 at 11:51:17AM -0700, John Williams wrote:
> > Right. ^= is rather pointless, because = already understands list
> > context.
>
> They're not quite the same because list assignment truncates first. To wit:
>
> @a = [1,2,3];
> @b = [4,5
to me , this discussion approaches the conclusion that
^[] and v[] are *just* another operators with their own behavior
that accept as ( optional ) argument a Code reference .
to follow the beautifull philosophy of perl6 -- "A is just B" we can
say ( following Larry Wall )
...
>
Michael Lazzaro writes:
> magical whitespace modifier:
>
>_ - When used at the end of a line or between
>statement elements, acts to "remove" whitespace
>when interpreting the statement. (Allows
>whitespace to appear without invoking any
>
Ed Peschko writes:
>
> So again, I don't see the difference between the two. ^[+]= and ^+= are synonyms
> as far as I can see, and hence no need for the first form.
>
> Ed
>
>
>
somebody before ( dont remember who)
showed how they can be different if the first argument is scalar.
a
Luke Palmer writes:
> >
> > All that said, can anyone come up with a case to
> > confuse with <$File_Handle>?
>
> sub postfix:bar returns handle;
> $y = undef ;
>
> That has two syntactically valid interpretations. It wouldn't take
> even that much to confuse the parser, thou
for @a -> $x, $y { ... $x is topic ... }
for @a ; @b ->
$x, $y ; $z { ... WHAT is topic ? ... }
what is topic in multi stream loop ?
arcadi
Larry Wall writes:
>
> sub postfix:! (num $x) { $x < 2 ?? $x :: $x * ($x - 1) ! }
>
> which could be fixed with the _:
>
> sub postfix:! (num $x) { $x < 2 ?? $x :: $x * ($x - 1) _! }
>
> Weird, but it's all consistent with the distinction we're already
> making on curlies, whic
Erik Steven Harrison writes:
>
>
> All that said, can anyone come up with a case to
> confuse with <$File_Handle>?
>
>
it seems that parser cannot confuse them because is operator and
parser expect operator, while <$File_Handle> is a term .
but human can confuse .
I personally also
Me writes:
> > > A ^ prefix visually interferes a lot more
> >
> > I know it clutters up things a bit, that's my very argument; that
> > ^[ ] clutters up things even *more*. especially, with use of arrays:
> >
> > @array[1,2,3] ^[+=] @array[4,5,6];
> >
> > bleah.
> >
> > @array[1,2,3
Damian Conway writes:
>
> BTW, Both Larry and I do understand the appeal of interleaving
> sources and iterators. We did consider it at some length back
> in January, when we spent a week thrashing this syntax out.
>
> Of course, I can't speak for Larry, but in the end I concluded
> that i
Me writes:
> > > > > union:
> > > > > intersection :
> > > >
> > > > %a ^is strict_keys;
> > > > %b ^is no_strict_keys;
> >
> > in the resulting hash only ( and all ) keys of %a will be present.
> > because %b *admits* unknown keys but %a does not.
>
> Yes, but the general case
Michael Lazzaro writes:
> OK, by my count -- after editing to reflect Larry's notes -- only a few
> issues remain before the ops list can be completed.
>
>
>
> 1) Need a definitive syntax for hypers,
> ^[op] and «op»
> have been most seriously proposed -- something that k
> Thats ugly, IMO.
>
> Now this is going to sound wild (probably) and I have not thought too much
> about it and there are probably others who can see the pitfalls quicker
> then me. But could () be available for hyper operators ?
>
> I will sit back now and watch the firewaorks, as I wont
Larry Wall writes:
> On Thu, 31 Oct 2002 [EMAIL PROTECTED] wrote:
> : %a ^[op]= @b # hash v array
> : @a ^[op]= %b # array v hash
>
> What would those mean? Are you thinking only of hashes with numeric keys?
>
> Larry
>
>
>
no but hash can have property that tells how to
Larry Wall writes:
> On Thu, 31 Oct 2002, Me wrote:
> : That's one reason why I suggested control of this sort
> : of thing should be a property of the operation, not of
> : the operands.
>
> I think that by and large, the operator knows whether it wants to
> do union or intersection. When
Me writes:
> > > union:
> > > intersection :
> >
> > How would this work for hashes with differing properties?
> >
> > %a ^is strict_keys;
> > %b ^is no_strict_keys;
> >
> > What would happen?
>
in the resulting hash only ( and all ) keys of %a will be present.
because %b *admits*
Austin Hastings writes:
> > but I am not shure ...
>
> "sure"
>
thanks . sorry that I write so badly . I'll try to be better .
> (Unless you do this on purpose :-)
>
> Cheers,
>
> =Austin
>
> __
> Do you Yahoo!?
> HotJobs - Searc
Austin Hastings writes:
>
> --- [EMAIL PROTECTED] wrote:
> > I agree. But I think that we can get away here with just hash
> > properties , just like hash behaviour in is controlled by
> > properties .
> >
> > e.g.
> > union:
> >
> > (%a,%b) ^is no_strict_keys ;
> > (%a %b) ^is de
Me writes:
> > > %a ^:union[op] %b
> > >
> > > %a :foo[op]:bar %b
> >
> > I think that any operators over 10 characters should
> > be banished, and replaced with functions.
>
I agree. But I think that we can get away here with just hash
properties , just like hash behaviour in is
Michael Lazzaro writes:
> OK, by my count -- after editing to reflect Larry's notes -- only a few
> issues remain before the ops list can be completed.
>
>
>
> 1) Need a definitive syntax for hypers,
> ^[op] and «op»
> have been most seriously proposed -- something that k
Uri Guttman writes:
>
> %hash1.values [+]= %hash2{%hash1.keys} ;
>
but here is exactly example analogous to
my Dog $x = new Dog .
which was discusse dand turned to
my Dog $x .= new ;
It's (almost) clear what you want when you write
%hash1 [+]= %hash2 ;
so why to screen the m
So is it usefull to make sence out of these :
hash ^[op] hash
hash ^[op] array
hash ^[op] scalar
array ^[op] array
array ^[op] scalar
Actually ,
I just want to understand , why so much accent is put on vectorizing
atomic operations with arrays . It seems that hashes are at least as
freq
Dave Storrs writes:
>
>
> On Wed, 30 Oct 2002, Angel Faus wrote:
>
> > Then let's make the parens required when there is more than one
> > stream.
> >
> > Sane people will put them there anyway, and it will force the rest of
> > us to behave.
> >
> > It also solves the ";"-not-a-line-
Dave Storrs writes:
> is a Bad Thing and is going to cause a lot of bugs. I have the following
> problems with it:
>
> for @a; @b -> $x is rw; $y { $x = $y[5] };
>
> 1) This is (AFAIK) the ONLY place in Perl where a semicolon that
> is not enclosed in parens is used for anything
Michael Lazzaro writes:
>
> On Wednesday, October 30, 2002, at 12:48 PM, Dave Storrs wrote:
> >for @a; @b -> $x is rw; $y { $x = $y[5] };
>
> I agree that it's an eyeful. How many of your issues could be solved
> if the above were just written:
>
> for (@a;@b) -> ($x is rw; $
!! Sorry, in previos post I had a mistake
Proposal : Vector operations for Hashes
(
this is just a joke
%a ^{+} %b
)
the direct generalization would be as follows :
@a ^[op] @b
for @a ; @b ->
$x ; $y {
$x op $y
}
%a ^[op] %b
# f
Proposal : Vector operations for Hashes
%a ^{+} %b
the direct generalization would be as follows :
@a ^[op] @b
for @a ; @b ->
$x ; $y {
$x op $y
}
%a op %b
# find common keys
@k = keys hash{ map { { _=>1 } } *( %a.keys , %b.keys ) };
#return has
Larry Wall writes:
>
> Well, "v" for vector makes a little more sense, maybe. Could be lots of things:
>
> @a *[+] @b
> @a .[+] @b
> @a =[+] @b
> @a ![+] @b
> @a ^[+] @b
> @a _[+] @b
> @a :[+] @b
> @a '[+] @b
> @a v[+] @b
>
> There's a problem w
Larry Wall writes:
>
> So despite the beauty of
>
> @a [+] @b
>
> I think it cannot survive in its current form. It overloads square
> brackets too heavily.
>
> Larry
>
so may be @a <+> @b
@a < => > @b
@a < , > @b
@a < .= > replace ( // -> { "bar" } )
but
@c = @a < <=>
Michael Lazzaro writes:
>
> Any ideas on what
>
> { $^a op $^b }
>
> would become?
>
> MikeL
maybe
{ $_a op $_b }
{ _ op _ }
and we have simple ( ? ) rules to distinguish it from "space-eater" _
* _ surrounded by spaces is placeholder if term is ex
Jonathan Scott Duff writes:
> On Tue, Oct 29, 2002 at 11:12:28AM -0800, Brian Ingerson wrote:
> > On 29/10/02 09:58 -0800, Larry Wall wrote:
> > > On Tue, 29 Oct 2002, Jonathan Scott Duff wrote:
> > > : On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote:
> > >
> > > So I would look
Brian Ingerson writes:
> On 29/10/02 09:58 -0800, Larry Wall wrote:
> > On Tue, 29 Oct 2002, Jonathan Scott Duff wrote:
> > : On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote:
> >
> > So I would look favorably on finding a replacement for "superposition".
>
> How about "christm
Damian Conway wrote:
: > or
: >
: > given ( "/home/temp/", $f )
: > -> ( str $x , int $n ) {
: > $x ~ ["one, "two", ... , "hundreed"][$n]
: > };
: >
: > it seems that the last does not work because given take only one argument.
:
: That's right. But th
but what about placeholders ?
arcadi .
_ as space eating grammar rule .
just beautifull!
this is in harmony with
$x = 123_567 ;
and we can use it as explicite space
$x =_$a++_+_++$a ;
or even as separator in *ugly* looking operators
@x ^_~~ s/.../.../
arcadi
> I think it would be cool if there were a way to pull the arguments out
> to the front, because then we really could write in Japanese word order:
>
> @args wa $*OUT de print yo!
>
> : also , is here the following DWIMmery in place
> :
> : sub pairs ( $x,$y ){ $x => $y } ;
> : sub tripl
Larry Wall writes:
> sub term:qa (str $quotestr) is parsed /qa/ { ... }
Michael Lazzaro writes :
> my Pet @list = qm : << name type breed >> {
> fido dog collie
> fluffy cat siamese
> };
doesnt it have to be
my Pet @list = qm << name type breed >> : { ...
: my @attrs = qw{ name type breed }
: my Pet @list=qw{
:fido dog collie
:fluffy cat siamese
: } ~~ sub (@x) { map { _ => _ } @attrs x Inf ^, @x }
:~~ sub (@x) { map { { _ , _ , _ } } @x ;
by the way , ~~ seems to work like u
In-reply-to: <[EMAIL PROTECTED]>
>
> my Pet @list = qm : << name type breed >> {
> fido dog collie
> fluffy cat siamese
> };
>
>That's still a lot easier to type than some of the alternatives I've
>had to do for larger structures.
on the second thought :
my @at
In-reply-to: <[EMAIL PROTECTED]>
>
> my Pet @list = qm : << name type breed >> {
> fido dog collie
> fluffy cat siamese
> };
>
>That's still a lot easier to type than some of the alternatives I've
>had to do for larger structures.
why ?
my @attrs=qw{ name type
References: <[EMAIL PROTECTED]>
Questions :
* are stream separators ";" "&" "|" in the "for" loop - operators
in the usual sence ( like "," ) or they are pure grammar ?
* is prototype of the subrotine more regexp then expression ?
to what extent it is a regexp ? where it is stored , can we
Damian Conway wrote:
>I certainly wouldn't mind seeing it return to that role, now that
>it's not needed elsewhere. And, of course, that would actually be:
>
> $x ~ $y string concatentation
> $x ~= $ystring append
> ~$x stringification
> ...
> $st
>
>And I really do like | for any(). And I can see using it like this:
>
>@cases ^|= @newcases;
>
>to mean
>
>for @cases | @newcases -> $x is rw | $y {
> $x = any($x, $y);
>}
>
but then probably we should also have
@cases = @cases ^| @newcases; is same as ( @cases ^|= @newcas
>I don't think the C construct would be dealing with real
>superpositions at the top level. I was just thinking about stealing
>the | and & notation.
so, "|", "&", are special "meta-comma" operators that create a (meta:-) "list"
with additional relation between entries. this (meta)list expands
in
http://archive.develooper.com/perl6-language%40perl.org/msg11451.html
Larry Wall wrote:
> for @cases ^| @newcases -> $x is rw | $y {...}
do I understand correctly that what happens is (more or less) --
any($a,$b) := any($x,$y)
?
arcadi
in
http://archive.develooper.com/perl6-language%40perl.org/msg11440.html
Larry Wall wrote:
>I'm wondering whether the single ones could indicate parallel streams.
>We had the difficulty of specifying whether the C loop should
>terminate on the shorter or the longer stream. We could say that |
>t
63 matches
Mail list logo
