Re: Perl6 Operator List (REMAINING ISSUES)
[Apologies for late reply, but it takes a long time to read this many messages] On Wed, 30 Oct 2002 16:37:09 -0800, Michael Lazzaro wrote: 1) Need a definitive syntax for hypers, ^[op] and «op» have been most seriously proposed -- something that keeps a bracketed syntax, but solves ambiguity issues. 2) Possible inclusion of unary prefix ^, meaning complement. (Assuming doesn't conflict with (1)) If ^ means xor (and complement), then we can't use it for hypering. Consider this example: @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 The operator doing the least at present seems to be ! (my recent attempts to reclaim it aside). If we keep ^ as the only xor/complement operator, we can use ! as the hyperoperator indicator without ambiguity: @a ![alpha_op] +3 Or (since people seem to like using ^ for hyperness), we could steal ! back as doing all the xor/complement things that ^ is doing now, and leave ^ doing just hyperstuff. This stops ! being a (mostly) synonym for ^, which I didn't really like, but does bring back the confusion between !! and ||. If we want to have a sigil meaning the next set of brackets surround a hyperoperator, it pretty much can't be the same as any of the other operators, since that introduces ambiguity all over the place. This is unfortunate, since perl seems to use every printable ASCII character for something. Using French quotes gets around this, since they aren't being used for anything else. OT3H, I can't find the «» keys on my keyboard, but I'm sure I'm just not looking hard enough. -- Peter Haworth [EMAIL PROTECTED] Are you the police? No ma'am, we're musicians.
Re: Perl6 Operator List (REMAINING ISSUES)
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 dbefore . ^ - xor and ^[] vectorization can coexist because perl takes longest known operator sequence ( and the vectorization is ^[] not ^ [ ]) so ^[] is vectorization and ^ [foo] *cannot* just like ~~ is binding and ~ ~ is ( string scalar context ( string scalar context ( so if you mean xor -- write ^ [...] arcady
Re: Perl6 Operator List
On Thu, 31 Oct 2002, Larry Wall wrote: On Fri, 1 Nov 2002 [EMAIL PROTECTED] wrote: : does it mean that *all* postfix operators have to be attached : without space to their operand or used with space eater modifyer : : or : : only those for which parser ( or we ) knows that they may be confused : with binary op or term ? I think a postfix has to be attached always. If there is no postfix, then a binary operator doesn't need to have space before it. Otherwise it does. And if there is no binary, then the postfix can have a space before it? Or are we introducing this new restriction to perl6 just because someone can define a binary operator:++ ? perl5 -le '$a = [[42]]; print $$a [0] [0] ++; print $$a[0][0]' 42 43 ~ John Williams
Re: Perl6 Operator List
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Date: Fri, 1 Nov 2002 11:01:34 -0700 (MST) From: John Williams [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] X-OriginalArrivalTime: 01 Nov 2002 18:01:34.0398 (UTC) FILETIME=[B70BCDE0:01C281D0] X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/ On Thu, 31 Oct 2002, Larry Wall wrote: On Fri, 1 Nov 2002 [EMAIL PROTECTED] wrote: : does it mean that *all* postfix operators have to be attached : without space to their operand or used with space eater modifyer : : or : : only those for which parser ( or we ) knows that they may be confused : with binary op or term ? I think a postfix has to be attached always. If there is no postfix, then a binary operator doesn't need to have space before it. Otherwise it does. And if there is no binary, then the postfix can have a space before it? Or are we introducing this new restriction to perl6 just because someone can define a binary operator:++ ? perl5 -le '$a = [[42]]; print $$a [0] [0] ++; print $$a[0][0]' 42 43 Ah, however: perl -le 'print($a ++)' syntax error at -e line 1, next char ) Execution of -e aborted due to compilation errors. So there's some mysterious rule like this in perl5, but I think it's got a couple more special cases, or something. Luke
Re: Perl6 Operator List
On Fri, Nov 01, 2002 at 11:01:34AM -0700, John Williams wrote: On Thu, 31 Oct 2002, Larry Wall wrote: On Fri, 1 Nov 2002 [EMAIL PROTECTED] wrote: : does it mean that *all* postfix operators have to be attached : without space to their operand or used with space eater modifyer : : or : : only those for which parser ( or we ) knows that they may be confused : with binary op or term ? I think a postfix has to be attached always. If there is no postfix, then a binary operator doesn't need to have space before it. Otherwise it does. And if there is no binary, then the postfix can have a space before it? Sure, as long as you also put the space-eater. I'm not going to change my mind in the space of two messages. (Well, not this time...) Or are we introducing this new restriction to perl6 just because someone can define a binary operator:++ ? We are introducing a regularity. In a few spots it will look like a restriction. perl5 -le '$a = [[42]]; print $$a [0] [0] ++; print $$a[0][0]' 42 43 That will not parse in Perl 6. I promise. Larry
Re: Perl6 Operator List (REMAINING ISSUES)
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
Re: Perl6 Operator List (REMAINING ISSUES)
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 turn its keys to
integer indexes if it fins itself in the ^[op] situation .
just like %hash can have a property that tells it how to behave in
regexp /%hash/ . And then just like here there may be some default
value for that property . I dont know what it should be . is it sane ?
%hash is if_in_vectorized_op_map_keys_to_integers_as { some function
returning integer }
arcadi .
Re: Perl6 Operator List
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, which gave a great increase in readability.
does it mean that *all* postfix operators have to be attached
without space to their operand or used with space eater modifyer
or
only those for which parser ( or we ) knows that they may be confused
with binary op or term ?
probably the same question for prefix operators .
aracdi
Re: Perl6 Operator List
On Fri, 1 Nov 2002 [EMAIL PROTECTED] wrote: : does it mean that *all* postfix operators have to be attached : without space to their operand or used with space eater modifyer : : or : : only those for which parser ( or we ) knows that they may be confused : with binary op or term ? I think a postfix has to be attached always. If there is no postfix, then a binary operator doesn't need to have space before it. Otherwise it does. : probably the same question for prefix operators . You can always put a space after a prefix operator, since you can only get one of those when a term is expected. Larry
Re: Perl6 Operator List, Damian's take
On Tue, 29 Oct 2002, Austin Hastings wrote: Any of you OO guys know of a case where $a = $a + $b; # A [+]= B; -- A = A [+] B; and $a += $b; # A [+=] B; should be different? They are different in the scalar [op] list case, as explained here: http://archive.develooper.com/perl6-language%40perl.org/msg10961.html ($a = 0) [+=] b; # sum ($a = 1) [*=] b; # product ($a ='') [~=] b; # cat ~ John Williams
Re: Perl6 Operator List, Damian's take
On Wed, 30 Oct 2002, John Williams wrote: : They are different in the scalar [op] list case, as explained here: : http://archive.develooper.com/perl6-language%40perl.org/msg10961.html : : ($a = 0) [+=] b; # sum : ($a = 1) [*=] b; # product : ($a ='') [~=] b; # cat That's almost a reduce. Pity you have to include a variable. But since rvalues are illegal on the left side of an assignment, we *could* go as far as to say that 0 [+=] b; # sum 1 [*=] b; # product '' [~=] b; # cat dwim into reduce operators rather than being illegal. Larry
Re: Perl6 Operator List, Damian's take
Larry wrote:
That's almost a reduce. Pity you have to include a variable.
But since rvalues are illegal on the left side of an assignment, we
*could* go as far as to say that
0 [+=] b; # sum
1 [*=] b; # product
'' [~=] b; # cat
dwim into reduce operators rather than being illegal.
ETOOCLEVERBYHALF, IMHO. ;-)
I'd much rather see these common reductions be predefined Csum,
Cproduct, and Ccat methods of Array, and the more obscure
and bizarre reductions be explicitly marked with a Creduce:
my $countersequence = reduce {$^x-$^y}, b
Damian
Re: Perl6 Operator List, Damian's take
On Thu, 31 Oct 2002, Damian Conway wrote:
: Larry wrote:
:
: That's almost a reduce. Pity you have to include a variable.
: But since rvalues are illegal on the left side of an assignment, we
: *could* go as far as to say that
:
: 0 [+=] b; # sum
: 1 [*=] b; # product
: '' [~=] b; # cat
:
: dwim into reduce operators rather than being illegal.
:
: ETOOCLEVERBYHALF, IMHO. ;-)
That's why I said *could*. But I couldn't not say it. :-)
: I'd much rather see these common reductions be predefined Csum,
: Cproduct, and Ccat methods of Array, and the more obscure
: and bizarre reductions be explicitly marked with a Creduce:
:
: my $countersequence = reduce {$^x-$^y}, b
I agree.
Larry
Re: Perl6 Operator List, Damian's take
Damian Conway writes: My personal favorite solution is to use square brackets (for their dual array and indexing connotations, and because they highlight the operator so nicely): $count = a + b; sums = a [+] b; Mmm, yummy. I do have a question though (and apologies if I've merely missed the answer). We've got two productive operation-formation rules: one saying add a final = to operate-and-assign, and the other saying wrap in [] to vectorise. But no-one's said which order they apply in. That is, which of these should I type: x [+]= y; x [+=] y; Of course, the rule ordering didn't matter with the add a leading ^ to hype rule. I think I prefer the first one, by the way -- it strikes me as more obviously a vector add. -- Aaron Crane * GBdirect Ltd. http://training.gbdirect.co.uk/courses/perl/
Re: Perl6 Operator List, TAKE 4
On Monday, October 28, 2002, at 01:25 PM, Michael Lazzaro wrote:
Again, I'm wondering if we're going about this wrong way -- perhaps we
need to go to more effort to save ^ as xor, and use something
different for hypers, like h+ or h[+] or `+ or ~+ or ~~+, etc?
OK, I'm calling Warnock's on this one. Is this just so far-fetched
that nobody's touching it with a ten foot pole, or am I missing
something, or ?
I know this was dealt with many months ago, but that was before we
changed ~ to stringify, making the xor situation worse. Isn't there
any way to keep ^, since we've just stated that the super meaning one
($a ^ $b ^ $c) is actually a worthwhile concept? (Yes, we would also
need to think about altering { $^a op $^b } in the same way.)
I'll shut up now on this one. But nobody's taking the bait, eh?
MikeL
Re: Perl6 Operator List, Damian's take
On Tuesday, October 29, 2002, at 11:21 AM, Damian Conway wrote:
My personal favorite solution is to use square brackets (for their dual
array and indexing connotations, and because they highlight the
operator
so nicely):
$count = a + b;
sums = a [+] b;
Any ideas on what
{ $^a op $^b }
would become?
MikeL
Re: Perl6 Operator List, Damian's take
DC == Damian Conway [EMAIL PROTECTED] writes: DC Oh boy, I just *hate* the idea of CX for xor. DC Hate it, hate it, hate it! Yuck, yuck, yuck! tell us how you _really_ feel! :-) DC My personal favorite solution is to use square brackets (for their dual DC array and indexing connotations, and because they highlight the operator DC so nicely): DC $count = @a + @b; DC @sums = @a [+] @b; DC [op] - around any unary/binary operator, vectorizes the operator that is actually very neat IMO. it does read well and makes sense too. DC unary (prefix) operators: DC ! - force to bool context, negate DC ~ - force to string context DC +^- force to numeric context, complement DC ~^- force to string context, complement what is a string complement? bitwise? i take it the numeric is one's complement. DC binary operators: DC ~ - string concatenation DC ~=- string append what happens to _? DC ||^^// - boolean operations DC = ||= ^^= //= DC and orxor err DC ++|+^- bitwise operations DC += +|= +^= = = i would add the word integer there. they do bitwise math on the integer part of a scalar value. DC ~~|~^- charwise operations DC ~= ~|= ~^= and these do bitwise operations but on the string part of a scalar. charwise isn't the best name for that. DC ??|?^- [maybe] C-like bool operations DC ?= ?|= ?^= - (result is always just 1 or 0) hmm. DC~~ !~- smart match, smart non-match is that also bind for tr///? uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org
Re: Perl6 Operator List, Damian's take
Michael Lazzaro wrote:
Any ideas on what
{ $^a op $^b }
would become?
It would be unchanged. Placeholders have nothing to do with hyperoperators.
And never have had.
Damian
Re: Perl6 Operator List, Damian's take
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Tue, 29 Oct 2002 11:36:20 -0800
Cc: [EMAIL PROTECTED]
From: Michael Lazzaro [EMAIL PROTECTED]
X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
On Tuesday, October 29, 2002, at 11:21 AM, Damian Conway wrote:
My personal favorite solution is to use square brackets (for their dual
array and indexing connotations, and because they highlight the
operator
so nicely):
$count = @a + @b;
@sums = @a [+] @b;
Any ideas on what
{ $^a op $^b }
would become?
Hmm... I was thinking something along the lines of:
{ $^a op $^b }
[i.e. this change doesn't make any difference]
Luke
Re: Perl6 Operator List, Damian's take
Uri Guttman wrote: what is a string complement? bitwise? i take it the numeric is one's complement. String complement treats the value as a string then bitwise complements every bit of each character. Integer complement treats the value as a int then bitwise complements every bit. DC ~ - string concatenation DC ~=- string append what happens to _? Someone hasn't been playing along at home! ;-) We're contemplating reshuffling the ops to eliminate it. DC ++|+^- bitwise operations DC += +|= +^= = = i would add the word integer there. they do bitwise math on the integer part of a scalar value. Good point. Thanks. DC~~ !~- smart match, smart non-match is that also bind for tr///? That's still being discussed at the moment. Damian
Re: Perl6 Operator List, Damian's take
On Tuesday, October 29, 2002, at 11:47 AM, Luke Palmer wrote:
[i.e. this change doesn't make any difference]
Doh! You're right, of course. For some reason I was thinking a long
while back that it would be confusing to have
{ $^a op $^b }
if ^ went back to meaning xor. But there's the sigils there, so never
mind. The problem was imaginary.
MikeL
Re: Perl6 Operator List, Take 3
Scott Duff wrote: Actually, I think we need a universal method on scalars that gives the eigenstates of that value. It might be C$val.eigenstates or maybe just C$val.states. The method would work on non-superimposed values as well, in which cases it would just return a list containing the value itself. Sure, but I'd leave the name eigenstates just so the casual programmer knows they're dealing with something from another universe if they happen to run across it :-) But they're *not*, that's the point. This stuff just ain't that hard. It's just set theory with a few interesting behaviour variations that make it act more like natural English. Much more on this in the next few posts. Damian
Re: Perl6 Operator List, Damian's take
On Wed, Oct 30, 2002 at 06:51:14AM +1100, Damian Conway wrote: String complement treats the value as a string then bitwise complements every bit of each character. Is that the complement of the codepoint or the individual bytes? (I'm thinking utf8 here). -- Nothing ventured, nothing lost.
Re: Perl6 Operator List, Damian's take
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 _
* sp _ sp surrounded by spaces is placeholder if term is expected
* sp _postfixop carriage-returns and binds the operator to
previous term
* term_ sp eats to the next word but leaves zerowidth word boundary
* explicitely named placeholders in
{ $_a op $_b }
will have to begin with _ : $_a , $_b ( as before with ^ )
to remind that they are placeholders : named _ ;
I cannot quite see if that is totally consistent .
aracadi
Re: Perl6 Operator List, Damian's take
Aaron Crane wrote: Mmm, yummy. I do have a question though (and apologies if I've merely missed the answer). We've got two productive operation-formation rules: one saying add a final = to operate-and-assign, and the other saying wrap in [] to vectorise. But no-one's said which order they apply in. That is, which of these should I type: x [+]= y; x [+=] y; Of course, the rule ordering didn't matter with the add a leading ^ to hype rule. I think I prefer the first one, by the way -- it strikes me as more obviously a vector add. Yep. Damian
Re: Perl6 Operator List, Damian's take
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Tue, 29 Oct 2002 21:37:32 +
From: Aaron Crane [EMAIL PROTECTED]
Content-Disposition: inline
X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
Damian Conway writes:
My personal favorite solution is to use square brackets (for their dual
array and indexing connotations, and because they highlight the operator
so nicely):
$count = @a + @b;
@sums = @a [+] @b;
Mmm, yummy. I do have a question though (and apologies if I've merely
missed the answer). We've got two productive operation-formation rules: one
saying add a final = to operate-and-assign, and the other saying wrap in
[] to vectorise. But no-one's said which order they apply in. That is,
which of these should I type:
@x [+]= @y;
@x [+=] @y;
Of course, the rule ordering didn't matter with the add a leading ^ to
hype rule.
Hmm. Well, they're different:
@x [+]= @y;
@x = @x [+] @y;
@x [+=] @y;
for @x | @y - $x is rw | $y {
$x += $y
}
:) Is there any advantage in differentiating that? Or would the
former *always* optimize to the latter?
Luke
I think I prefer the first one, by the way -- it strikes me as more
obviously a vector add.
--
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/courses/perl/
Re: Perl6 Operator List, Damian's take
Interesting point, especially if operator:+= can be overloaded.
@a [+=] @b;
implies iteratively invoking operator:+=, whereas
@a [+]= @b;
implies assigning the result of iteratively invoking operator:+
It only matters when they're different. :-|
And, of course, if they ARE different then the implication is that
signature-matching may also be involved, such that the version of
operator:+ (or +=) that gets used can change...
Hell, we might as well throw in multiple dispatch.
Any of you OO guys know of a case where
$a = $a + $b; # @A [+]= @B; -- @A = @A [+] @B;
and
$a += $b; # @A [+=] @B;
should be different? (Intuitively, I get the feeling that these cases
exist, especially in the weird cases kind of like the and
operators that C++ redefined for I/O. But I'm not sure if that's
paranoia causing me to accept lousy design, or what...)
Or should there be an overloadable operator:[op]= that takes arrays or
lists as its normal context? (Kind of like C++ differentiating between
new and new[])
=Austin
--- Luke Palmer [EMAIL PROTECTED] wrote:
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Tue, 29 Oct 2002 21:37:32 +
From: Aaron Crane [EMAIL PROTECTED]
Content-Disposition: inline
X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
Damian Conway writes:
My personal favorite solution is to use square brackets (for
their dual
array and indexing connotations, and because they highlight the
operator
so nicely):
$count = @a + @b;
@sums = @a [+] @b;
Mmm, yummy. I do have a question though (and apologies if I've
merely
missed the answer). We've got two productive operation-formation
rules: one
saying add a final = to operate-and-assign, and the other saying
wrap in
[] to vectorise. But no-one's said which order they apply in.
That is,
which of these should I type:
@x [+]= @y;
@x [+=] @y;
Of course, the rule ordering didn't matter with the add a leading
^ to
hype rule.
Hmm. Well, they're different:
@x [+]= @y;
@x = @x [+] @y;
@x [+=] @y;
for @x | @y - $x is rw | $y {
$x += $y
}
:) Is there any advantage in differentiating that? Or would the
former *always* optimize to the latter?
Luke
I think I prefer the first one, by the way -- it strikes me as more
obviously a vector add.
--
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/courses/perl/
__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
Re: Perl6 Operator List, Damian's take
[EMAIL PROTECTED] (Dave Mitchell) writes: (I'm thinking utf8 here). I'd strongly advise against that. -- Ermine? NO thanks. I take MINE black. - Henry Braun is Oxford Zippy
Re: Perl6 Operator List, Damian's take
On 30 Oct 2002, Simon Cozens wrote: : [EMAIL PROTECTED] (Dave Mitchell) writes: : (I'm thinking utf8 here). : : I'd strongly advise against that. Actually, it works out rather well in practice, because the string abstraction in Perl is that of a sequence of codepoints. But at least in Perl 5, as long as your codepoints don't get above 255, it can still all be done with good old byte-ops. Larry
Re: Perl6 Operator List, Damian's take
At 1:20 AM + 10/30/02, Simon Cozens wrote: [EMAIL PROTECTED] (Dave Mitchell) writes: (I'm thinking utf8 here). I'd strongly advise against that. I'd agree. Thinking UTF-8 is generally a bad idea. If you think anything, think fixed-size code points, since that's what you're ultimately going to get. Probably 8 bit if you're ASCII, Latin1, or EBCDIC, 16 if you're Shift-JIS or Big5 (either one), and 32 if you're dealing with Unicode. It's possible you'll get UTF-8 (or UTF-16) but I think you'll be hard-pressed to get there, at least without explicit hoop-jumping. I certainly hope so, at least. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Perl6 Operator List, Damian's take
Luke Palmer [mailto:fibonaci;babylonia.flatirons.org] wrote:
for x | y - $x is rw | $y {
$x += $y
}
This superposition stuff is getting to me: I had a double-take,
wondering why we were iterating with superpositions (Bitops
never entered my mind). Did the C; ever officially change
to C| as the low-precidence list composer?
Dave.
ps. for readability, I think most situations require parenthesis
round these mega-lists.
RE: Perl6 Operator List, Damian's take
On Tue, 29 Oct 2002, David Whipp wrote:
: Luke Palmer [mailto:fibonaci;babylonia.flatirons.org] wrote:
:
:for x | y - $x is rw | $y {
:$x += $y
:}
:
: This superposition stuff is getting to me: I had a double-take,
: wondering why we were iterating with superpositions (Bitops
: never entered my mind). Did the C; ever officially change
: to C| as the low-precidence list composer?
No. It's still officially C;.
Larry
Re: Perl6 Operator List, Damian's take
On Tue, 29 Oct 2002, Austin Hastings wrote: Hell, we might as well throw in multiple dispatch. Actually, I am really hoping we do. Any of you OO guys know of a case where $a = $a + $b; # A [+]= B; -- A = A [+] B; and $a += $b; # A [+=] B; should be different? Any time that evaluating $a produces a side effect--for example, if $a is a tied variable implementing a counter and increments itself by one every time its value is fetched. If it started with a value of 5, then $a += 3 leaves it with a value of 8, but $a = $a + 3 leaves it with a value of 9. Dave Storrs
Re: Perl6 Operator List, Take 3
On Sunday, October 27, 2002, at 12:57 PM, Michael Lazzaro wrote: .= .|= .\= = = - (depending on operants) s/operants/operands/ Sorry bout that. Typing too fast. MikeL
RE: Perl6 Operator List, Take 2
On Sun, 27 Oct 2002 [EMAIL PROTECTED] wrote:
: 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 this does:
: :
: : for /home/temp/, $f
: : - str $x , int $n {
: : $x ~ [one, two, ... , hundreed][$n]
: : }
: :
: : Damian
:
: except that it will not tolerate list in block signature
:
: for /home/temp/, @f
: - str $x , int @y {
:...
:}
:
: am I right ?
for is special in that it provides a list context to its, er,
list, while looking for scalars in the signature to map it against.
So the problem with that example is not the signature, which nicely
specifies a scalar reference to an array, but that the list context
would naturally flatten @f. You'd have to pass it as \@f, unless
you actually mean @f to contain a list mapping to:
(Array of int, (str, Array of int) is repeated).
: Now it will be
:
: given [/home/temp/, @f]
: - [ str $x , int @y ]{
:...
:}
:
: ?
Though that doesn't iterate like for can:
for /home/temp/, \@f,
/home/notsotemp, \@g,
- str $x , int @y {
...
}
Larry
Re: Perl6 Operator List, Take 3
On Sun, 27 Oct 2002, Michael Lazzaro wrote: : If \ meant xor, and some of the other discussed changes: I mislike \ for xor, primarily because it doesn't fit into the current escape mystique of \. Larry
Re: Perl6 Operator List, Take 3
Since xor is really low frequency, why not make xor mean xor? $zero = $a xor $a; $a xor= $b; $b xor= $a xor= $b xor= $a; # Swap'em @a ^xor= @b; # Is this right? =Austin --- Larry Wall [EMAIL PROTECTED] wrote: On Sun, 27 Oct 2002, Michael Lazzaro wrote: : If \ meant xor, and some of the other discussed changes: I mislike \ for xor, primarily because it doesn't fit into the current escape mystique of \. Larry __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/
Re: Perl6 Operator List, Take 3
On Mon, Oct 28, 2002 at 09:41:37AM -0800, Larry Wall wrote: On Sun, 27 Oct 2002, Michael Lazzaro wrote: : If \ meant xor, and some of the other discussed changes: I mislike \ for xor, primarily because it doesn't fit into the current escape mystique of \. Does xor really need the punctuation? Does xor really need to be a primitive? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Perl6 Operator List, Take 3
On Monday, October 28, 2002, at 09:58 AM, Jonathan Scott Duff wrote: Does xor really need the punctuation? Does xor really need to be a primitive? Though bitwise xor is seldom used for most people, other versions are likely to be more frequent: the 'superpositional' flavor, for example, is likely to have significant meaning. Same with 'none', I expect. | \ ! all any one none So supporting a punctuation for xor-like operations is more useful than it might at first appear. MikeL
Re: Perl6 Operator List, Take 3
On Mon, Oct 28, 2002 at 10:11:43AM -0800, Michael Lazzaro wrote: Though bitwise xor is seldom used for most people, other versions are likely to be more frequent: the 'superpositional' flavor, for example, is likely to have significant meaning. Same with 'none', I expect. | \ ! all any one none So supporting a punctuation for xor-like operations is more useful than it might at first appear. Maybe. How do we get at the eigenstates of a superposition? The punctuation for one and none could go away if could just count the eigenstates. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Perl6 Operator List, Take 3
On Mon, 28 Oct 2002, Michael Lazzaro wrote: : On Monday, October 28, 2002, at 09:58 AM, Jonathan Scott Duff wrote: : Does xor really need the punctuation? Does xor really need to be a : primitive? : : Though bitwise xor is seldom used for most people, other versions are : likely to be more frequent: the 'superpositional' flavor, for example, : is likely to have significant meaning. Same with 'none', I expect. : : | \ ! :all any one none : : So supporting a punctuation for xor-like operations is more useful than : it might at first appear. Well, I don't believe in none since it's really easy to say !any(), but exclusive-or can certainly use the punctuation. Or, actually, I'm currently thinking, non-punctuation. I kept thinking to myself that it's a shame that x is already taken, and then I looked crosseyed at the // vs \\ proposals, and I realized we have a superposition of / and \ that is spelled X. :-) So at the moment I'm thinking we have $a X $b # super xor $a XX $b# logical high precedence xor $a X= $b# assignment xor $a +X $b# intbits xor $a ~X $b# strbits xor $a ^XX $b # hyper xor $a xor $b # low precedence xor +X $a # int complement ~X $a # str complement Larry
Re: Perl6 Operator List, Take 3
On Mon, Oct 28, 2002 at 11:55:24AM -0800, Larry Wall wrote: Well, I don't believe in none since it's really easy to say !any(), but exclusive-or can certainly use the punctuation. Or, actually, I'm currently thinking, non-punctuation. I kept thinking to myself that it's a shame that x is already taken, and then I looked crosseyed at the // vs \\ proposals, and I realized we have a superposition of / and \ that is spelled X. :-) Hmm. I wonder if people aren't going to expect some relationship between x and X .. So at the moment I'm thinking we have $a X $b # super xor $a XX $b # logical high precedence xor $a X= $b # assignment xor $a +X $b # intbits xor $a ~X $b # strbits xor $a ^XX $b # hyper xor $a xor $b # low precedence xor +X $a # int complement ~X $a # str complement And presumably these as well? $a ^X= $b # hyper assignment xor $a ^+X $b # hyper intbits xor $a ^~X $b # hyper strbits xor $a ^xor $b# hyper low precedence xor ^+X $a# hyper int complement ^~X $a# hyper str complement Sometimes when I look at stuff like this I start to Cozenify and ask myself what language is this again? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
RE: Perl6 Operator List, Take 3
Larry Wall:
# and then I looked crosseyed at the // vs \\ proposals, and I
# realized we have a superposition of / and \ that is spelled X. :-)
use Perl::Caseless;
print foo x 6;#?!?
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: Perl6 Operator List, Take 3
On Mon, Oct 28, 2002 at 11:55:24AM -0800, Larry Wall wrote: Well, I don't believe in none since it's really easy to say !any() Does that have any implications for unless? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Perl6 Operator List, Take 3
On Mon, 28 Oct 2002, Paul Johnson wrote: : On Mon, Oct 28, 2002 at 11:55:24AM -0800, Larry Wall wrote: : : Well, I don't believe in none since it's really easy to say !any() : : Does that have any implications for unless? No. unless reads well in English. How do your read $a ! $b ! $c? (When I said I don't believe in none, I was referring to the infix operator. I think none($a,$b,$c) is okay.) Larry
Re: Perl6 Operator List, Take 3
On Monday, October 28, 2002, at 01:09 PM, Larry Wall wrote: No. unless reads well in English. How do your read $a ! $b ! $c? nor? Maybe it's $a nor $b? MikeL
Re: Perl6 Operator List, Take 3
On Mon, Oct 28, 2002 at 01:19:05PM -0800, Michael Lazzaro wrote: On Monday, October 28, 2002, at 01:09 PM, Larry Wall wrote: No. unless reads well in English. How do your read $a ! $b ! $c? nor? Maybe it's $a nor $b? oh no! You've said nor, so now I have have to ask about nand ... and the next thing you know perl takes over the world of circuit design. :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Perl6 Operator List, TAKE 4
On Mon, 2002-10-28 at 16:25, Michael Lazzaro wrote: explicit radix specifications for integers: 0123- decimal 2:0110- binary [also b:0110?] 8:123 - octal [also o:123?] 16:123- hex[also h:123?] 256:192.168.1.0 - base 256 (...etc...) I've got to admit that I've not paid alot of attention to this thread...but does that mean 0x1234 and 01234 (octal) go away or is this an omission? Brian Wheeler [EMAIL PROTECTED] other uncategorized: my our - [declar] mapgrep sqrt log sin cos tan (etc...) - math lc lcfirst uc ucfirst intord oct hex bin MikeL
Re: Perl6 Operator List, Take 3
If you guys start trying to reserve punctuation for XNOR, the next perl cruise is going to be through the Bermuda Triangle... =Austin --- Jonathan Scott Duff [EMAIL PROTECTED] wrote: On Mon, Oct 28, 2002 at 01:19:05PM -0800, Michael Lazzaro wrote: On Monday, October 28, 2002, at 01:09 PM, Larry Wall wrote: No. unless reads well in English. How do your read $a ! $b ! $c? nor? Maybe it's $a nor $b? oh no! You've said nor, so now I have have to ask about nand ... and the next thing you know perl takes over the world of circuit design. :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED] __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/
Re: Perl6 Operator List, TAKE 4
At 4:39 PM -0500 10/28/02, brian wheeler wrote: On Mon, 2002-10-28 at 16:25, Michael Lazzaro wrote: explicit radix specifications for integers: 0123- decimal 2:0110- binary [also b:0110?] 8:123 - octal [also o:123?] 16:123- hex[also h:123?] 256:192.168.1.0 - base 256 (...etc...) I've got to admit that I've not paid alot of attention to this thread...but does that mean 0x1234 and 01234 (octal) go away or is this an omission? While we're at it, maybe we can add in 0rMCM to allow roman numerals too... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl6 Operator List, TAKE 4
On 2002-10-28 at 16:39:10, brian wheeler wrote: [The below is actually from Larry, not Michael] explicit radix specifications for integers: 0123- decimal 2:0110- binary [also b:0110?] 8:123 - octal [also o:123?] 16:123- hex[also h:123?] 256:192.168.1.0 - base 256 (...etc...) The post that started this thread was a complaint about leading 0 meaning octal - which is counterintuitive to everyone the first time they come across it in C or Perl or Java or wherever. So yes, as indicated by the first line above, if this proposal were to be adopted (and again, it's just Larry thinking out loud), 0123 would be 123 decimal, not 123 octal = 83 decimal. However I don't see any reason not to allow 0x as a synonym for 16: (or 16# or whatever the radix syntax would be). -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Perl6 Operator List, TAKE 4
At 4:44 PM -0500 10/28/02, Mark J. Reed wrote: On 2002-10-28 at 16:39:10, brian wheeler wrote: [The below is actually from Larry, not Michael] explicit radix specifications for integers: 0123- decimal 2:0110- binary [also b:0110?] 8:123 - octal [also o:123?] 16:123- hex[also h:123?] 256:192.168.1.0 - base 256 (...etc...) The post that started this thread was a complaint about leading 0 meaning octal - which is counterintuitive to everyone the first time they come across it in C or Perl or Java or wherever. That's not entirely true. Granted the set of the people for whom a leading 0 instinctively means octal is not that big (and getting smaller due to retirement and death from old age :) but it was meaningful at one time. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl6 Operator List, TAKE 4
On Mon, 2002-10-28 at 16:44, Mark J. Reed wrote: On 2002-10-28 at 16:39:10, brian wheeler wrote: [The below is actually from Larry, not Michael] explicit radix specifications for integers: 0123- decimal 2:0110- binary [also b:0110?] 8:123 - octal [also o:123?] 16:123- hex[also h:123?] 256:192.168.1.0 - base 256 (...etc...) The post that started this thread was a complaint about leading 0 meaning octal - which is counterintuitive to everyone the first time they come across it in C or Perl or Java or wherever. So yes, as indicated by the first line above, if this proposal were to be adopted (and again, it's just Larry thinking out loud), 0123 would be 123 decimal, not 123 octal = 83 decimal. That's fair..especially since the only place most people use octal is mkdir and chmod. However I don't see any reason not to allow 0x as a synonym for 16: (or 16# or whatever the radix syntax would be). That's probably a good idea to make it a synonym since hex notation is used much more often than octal. Thanks for the clarification! Brian -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Perl6 Operator List, TAKE 4
On 2002-10-28 at 16:54:26, Dan Sugalski wrote: The post that started this thread was a complaint about leading 0 meaning octal - which is counterintuitive to everyone the first time they come across it in C or Perl or Java or wherever. That's not entirely true. Granted the set of the people for whom a leading 0 instinctively means octal is not that big (and getting smaller due to retirement and death from old age :) but it was meaningful at one time. No, read what I said again. I guarantee that the *first* time each of these supposed old codgers came across the leading 0 used for octal - in whatever context in whatever decade that might have been - it was counterintuitive, since it runs against what we're taught in mathematics from grade school on. :) -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Perl6 Operator List, TAKE 4
On Monday, October 28, 2002, at 01:57 PM, Austin Hastings wrote: If we're going to kill the alternate radix literals, better to do something like hex:123 or hex 123. I'd hate to try to comprehend $a = -x:123; more than a week from now. That x:123 part was my placeholder -- my bad, I forgot that was there when I was copying it. Yes, I think more likely scenarios would be 0b0110 or bin:0110 0c0123 or oct:0123 0x0123 or hex:0123 And almost certainly the former, not the latter. I'll put 0b, 0c, 0x for now (assuming we don't want 0o0123, which looks too, um, loopy.) Dan Sugalski wrote: While we're at it, maybe we can add in 0rMCM to allow roman numerals too... OK, see, the sad thing is that I really have no idea whether you're joking or not. That's how wiggy this thread has gotten. MikeL
Re: Perl6 Operator List, TAKE 4
At 2:21 PM -0800 10/28/02, Michael Lazzaro wrote: Dan Sugalski wrote: While we're at it, maybe we can add in 0rMCM to allow roman numerals too... OK, see, the sad thing is that I really have no idea whether you're joking or not. That's how wiggy this thread has gotten. I am joking--it's definitely a bad sign that you can't tell. :-P (Of course, I'm hardly one to talk, what with Parrot and all...) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl6 Operator List, TAKE 4
On 28 Oct 2002 at 16:42, Dan Sugalski wrote: At 4:39 PM -0500 10/28/02, brian wheeler wrote: On Mon, 2002-10-28 at 16:25, Michael Lazzaro wrote: explicit radix specifications for integers: 0123- decimal 2:0110- binary [also b:0110?] 8:123 - octal [also o:123?] 16:123- hex[also h:123?] 256:192.168.1.0 - base 256 (...etc...) I've got to admit that I've not paid alot of attention to this thread...but does that mean 0x1234 and 01234 (octal) go away or is this an omission? While we're at it, maybe we can add in 0rMCM to allow roman numerals too... -- What about specifying endiannes also, or would that be too low-level to even consider? Currently I don't have any examples for where it might even be used... -- Markus Laire 'malaire' [EMAIL PROTECTED]
Re: Perl6 Operator List, TAKE 4
What about specifying endiannes also, or would that be too low-level to even consider? Currently I don't have any examples for where it might even be used... Literals are the wrong place to put that; they represent values, not storage. Endianness should generally not be visible at the language level; were you need to specify it, it will usually be an attribute/property of the data source you're reading from or the sink you're writing to. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Perl6 Operator List, TAKE 4
I think that endian issues are abstracted from literals. The place it's going to be an issue is the specifiers for pack/unpack or whatever replaces them. But the presence of the operator (and speaking of low-frequency operators, what about bitwise rotation? Will that be the (( and )) operators?) means that signed/unsigned conversions need to be thought out. Is 0xDEADBEEF 3 going to be positive or negative? =Austin --- Markus Laire [EMAIL PROTECTED] wrote: On 28 Oct 2002 at 16:42, Dan Sugalski wrote: At 4:39 PM -0500 10/28/02, brian wheeler wrote: On Mon, 2002-10-28 at 16:25, Michael Lazzaro wrote: explicit radix specifications for integers: 0123- decimal 2:0110- binary [also b:0110?] 8:123 - octal [also o:123?] 16:123- hex[also h:123?] 256:192.168.1.0 - base 256 (...etc...) I've got to admit that I've not paid alot of attention to this thread...but does that mean 0x1234 and 01234 (octal) go away or is this an omission? While we're at it, maybe we can add in 0rMCM to allow roman numerals too... -- What about specifying endiannes also, or would that be too low-level to even consider? Currently I don't have any examples for where it might even be used... -- Markus Laire 'malaire' [EMAIL PROTECTED] __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/
Re: Perl6 Operator List, Take 3
On Mon, Oct 28, 2002 at 03:30:54PM -0600, Jonathan Scott Duff wrote: On Mon, Oct 28, 2002 at 01:19:05PM -0800, Michael Lazzaro wrote: On Monday, October 28, 2002, at 01:09 PM, Larry Wall wrote: No. unless reads well in English. How do your read $a ! $b ! $c? nor? Maybe it's $a nor $b? oh no! You've said nor, so now I have have to ask about nand ... and the next thing you know perl takes over the world of circuit design. :-) Then dont forget full tristate logic too :) Graham.
Re: Perl6 Operator List, TAKE 4
At 12:37 AM +0200 10/29/02, Markus Laire wrote: On 28 Oct 2002 at 16:42, Dan Sugalski wrote: At 4:39 PM -0500 10/28/02, brian wheeler wrote: On Mon, 2002-10-28 at 16:25, Michael Lazzaro wrote: explicit radix specifications for integers: 0123- decimal 2:0110- binary [also b:0110?] 8:123 - octal [also o:123?] 16:123- hex[also h:123?] 256:192.168.1.0 - base 256 (...etc...) I've got to admit that I've not paid alot of attention to this thread...but does that mean 0x1234 and 01234 (octal) go away or is this an omission? While we're at it, maybe we can add in 0rMCM to allow roman numerals too... -- What about specifying endiannes also, or would that be too low-level to even consider? Currently I don't have any examples for where it might even be used... Nope, not a problem. Roman Numerals are big-endian by definition. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl6 Operator List, TAKE 4
On Mon, 28 Oct 2002, Austin Hastings wrote: : But the presence of the operator Er, *what* operator? : (and speaking of low-frequency operators, what about bitwise rotation? : Will that be the (( and )) operators?) I think those will be rejected by anyone who uses either vi or emacs. Seriously, let's not make the $( and $) mistake again. : means that signed/unsigned conversions need to be thought out. : : Is 0xDEADBEEF 3 going to be positive or negative? Depends on whether you're a vegetarian. Personally I consider it to be a positive. Perl 5 seems to concur. Larry
Re: Perl6 Operator List, Take 3
[EMAIL PROTECTED] (Larry Wall) writes: : On Mon, Oct 28, 2002 at 11:55:24AM -0800, Larry Wall wrote: : Well, I don't believe in none since it's really easy to say !any() : : Does that have any implications for unless? No. unless reads well in English. How do your read $a ! $b ! $c? You said above that you've prefer to say (presumably) not any, using !any, rather than none, which makes me suspect you're using ! as not, so I'd read that a not b not c, which doesn't make amazing amounts of sense. -- Wouldn't it be wonderful if real life supported control-Z?
Re: Perl6 Operator List, TAKE 4
Didn't I see an operator list a while back that featured sign-extending shift? If not, I apologize. But on the other hand, we could make a ~ operator that was a case-preserving indent :-) =Austin --- Larry Wall [EMAIL PROTECTED] wrote: On Mon, 28 Oct 2002, Austin Hastings wrote: : But the presence of the operator Er, *what* operator? : (and speaking of low-frequency operators, what about bitwise rotation? : Will that be the (( and )) operators?) I think those will be rejected by anyone who uses either vi or emacs. Seriously, let's not make the $( and $) mistake again. : means that signed/unsigned conversions need to be thought out. : : Is 0xDEADBEEF 3 going to be positive or negative? Depends on whether you're a vegetarian. Personally I consider it to be a positive. Perl 5 seems to concur. Larry __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/
Re: Perl6 Operator List, TAKE 4
explicit radix specifications for integers: 0123- decimal 2:0110- binary [also b:0110?] 8:123 - octal [also o:123?] 16:123- hex[also h:123?] 256:192.168.1.0 - base 256 (...etc...) Could this be used to do explicit conversion between bases, and/or strings, rather than using pack/unpack/sprintf, etc. ? my $macaddr = '00022D3F7659'; my $hex = 16:$macaddr; How about $a = 'DEADBEEF'; $hexres = 16:$a + 16:FEED; print ~16:$hexres; does that give me DEAEBDDC ? R. -- Richard Nuttall
Re: Perl6 Operator List, Take 3
Scott Duff asked:
How do we get at the eigenstates of a superposition?
We obviously need another operator! ducks
Actually, I think we need a universal method on scalars that
gives the eigenstates of that value. It might be C$val.eigenstates
or maybe just C$val.states. The method would work on non-superimposed
values as well, in which cases it would just return a list containing
the value itself.
The punctuation for one and none could go away if could just
count the eigenstates.
Yes, but this:
if ($x | $y | $z == 7).states == 1 {...}
aren't nearly as nice as this:
if $x ^ $y ^ $z == 7 {...}
which means everyone will probably write:
if none($x,$y,$z) == 7 {...}
which is probably the right solution anyway ;-)
Damian
Re: Perl6 Operator List, Take 3
On Tue, Oct 29, 2002 at 03:58:57PM +1100, Damian Conway wrote: Actually, I think we need a universal method on scalars that gives the eigenstates of that value. It might be C$val.eigenstates or maybe just C$val.states. The method would work on non-superimposed values as well, in which cases it would just return a list containing the value itself. Sure, but I'd leave the name eigenstates just so the casual programmer knows they're dealing with something from another universe if they happen to run across it :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
XOR vs. Hyper (was Re: Perl6 Operator List)
FWIW, if people are really eager to keep ^ for xor (I don't think anything's clicking great as a replacement), we could of course switch hyper to ~. That would give us, in part: ? ! + - _ # unary prefixes + - * / % ** x xx# binary +=-= *= /= %= **=x=xx= ~+~- ~* ~/ ~% ~**~x~xx# hyper ~+= ~-=~*=~/=~%=~**= ~x= ~xx= and or xor err# logical ops || ^^// # logical ops b b| b^ # binary (placeholders, for now) |^# binary or super (dunno, for now) all any one none # superpositional (+ sum,prod,cat,reduce) That would put us back to square one with string cat, but it _would_ give people back their C-like xor, which would help the familiarity issue a bit. OR, we could use ~ for string and ~~ for hyper, which I think would be OK except for the presence of an ~~~ operator for hypercat (it does sort of look like a cat going really fast, though, doesn't it?) We could also try for some bracketing constructs around hypers, or a doubled punct, or something. Thought of course about +, it looks very hyper-like, but probably still too many issues with the old-style file $stuff + - * / % ** x xx# binary +=-= *= /= %= **=x=xx= + -*/%** x xx # hyper += -= *= /= %= **= x= xx= Dunno, just feels like there should be a solution here, somewhere... a ~~+ b # not awful a + b # sigh, this is pretty nice looking a h+ b a + b a ^+^ b a `+ b a .+. b a =+= b a ~+~ b a \+\ b a [+] b a h[+] b a [+] b a + b MikeL
Re: Perl6 Operator List
Michael Lazzaro [EMAIL PROTECTED] writes: John Siracusa wrote: Larry's just thinking out loud, right? Yes, and so is everyone else. Most posts here, including Larry's, are stream-of-conciousness. Heck, in one of the last ones I swear there were, what, 6 or 7 possible ways to say the same binary op things. 90% of everything proposed is shot down, though sometimes it generates a lot of noise before dying. Even many of the players here move in-and-out of conversation, from lurker to poster to lurker, depending on topic free time. And some of us have to summarize the bloody thing. Which is *so* not fun. I'm always tempted to write The Operator Thread goes on and on, into scary territory 90% of which will turn out to be comepletely irrelevant, but your summarizer hasn't got a clue which 90% that will be. You're on your own... -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
Re: XOR vs. Hyper (was Re: Perl6 Operator List)
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Sat, 26 Oct 2002 23:01:31 -0700
From: Michael Lazzaro [EMAIL PROTECTED]
X-Accept-Language: en,pdf
Cc: Damian Conway [EMAIL PROTECTED],
[EMAIL PROTECTED] [EMAIL PROTECTED]
X-SMTPD: qpsmtpd/0.12-dev, http://develooper.com/code/qpsmtpd/
FWIW, if people are really eager to keep ^ for xor (I don't think
anything's clicking great as a replacement), we could of course switch
hyper to ~. That would give us, in part:
What about smart match, then? Would that go back to =~ ?
To be personally honest, my favorite (still) is:
^Hyper
\\ Xor
unary ! Not (screw parallelism: it was never there before)
~Cat
_ nada ahora
binary ! niente ora
~~ Smart match
I have no preferences for the bitops, as I don't find them remotely
useful in my work.
Modifying your table:
? ! + - _ # unary prefixes
+ - * / % ** x xx# binary
+=-= *= /= %= **=x=xx=
^+^- ^* ^/ ^% ^**^x^xx# hyper
^+= ^-=^*=^/=^%=^**= ^x= ^xx=
and or xor err# logical ops
|| \\// # logical ops
b b| b\ # No biterr??! :)
|\# No superr either...
all any one none # none? Seriously :)? Fun.
I dunno, that's just me. The only problem with \\ is will people
remember which way is which? It'd be a shame to see
$fh = open('/etc/passwd') \\ die Can't open /etc/passwd: $!
And have it always die. But honestly, that's not too much of a
problem. A mnemonic might be that \\ has negative slope, and \\
kindof negates... kindof. Well, forget that.
As for unary \, who cares? ! is fine for negation. C didn't make the
connection, so why must we?
Or we could make ! the reference op 8-P
Luke
Re: Perl6 Operator List
[EMAIL PROTECTED] (Larry Wall) writes:
: I hope you're not buying any of this crap
: about Perl 6 being more regular or removing the inconsistencies of
: Perl 5. It simply isn't true.
Hey, sounds like it'd make a great column. Go for it. I'll expect
a little more than an argument by assertion, however.
You have a fair point; I'm sorry, I shouldn't scaremonger like that without
a better argument to back me up. I just see code like
~~ sub (@x) { map { _ = _ } @attrs x Inf ^, @x }
and get the screaming heaves.
I shall have to go away and try to find the alleged regularities
before I can refute them - the one that comes to mind immediately is
that braces always delimit closures. (Except when they force a
statement end by the newline rule.)
However hard it may be to believe, I'm not just saying this to be snarky; I
am excited by Perl 6 and want to see good things come out of it. I just want
to make sure that the various creative processes are kept in check. :)
--
Building translators is good clean fun.
-- T. Cheatham
Re: Perl6 Operator List
Larry Wall wrote:
On 26 Oct 2002, Smylers wrote:
: Larry Wall wrote:
:
: print(length $a), \n;
: print (length $a), \n;
:
: Those look to me like they should do the same thing as each other.
Sorry, they don't look that way to me.
Having slept on it, I'm not as scared about whitespace being significant
as I was yesterday. (Also I think there may be a precedent for this in
BBC Basic of all things[*0].)
: What would be the harm in not having any special rule here ... ?
The harm would be that we'd basically be reinventing Lisp syntax with
precedence in place of some of the parens.
I have memories that before I went to bed last night I saw a good
example from Damian demonstrating the harm, but I can't find it this
morning.[*1] It went something along the lines of:
outer(foo(1), bar(2)); # A
being treated as though it were
outer foo(1, bar 2); # B
Personally I've got no problem with the way of getting the Perl 5
meaning of A being:
outer (foo 1), (bar 2); #C
It still feels a shame that there are two places the opening paren can
go (before and after the function name) and there are two meanings that
need to be distinguished (a single-arg function and a multi-arg function
with precedence around the first param) yet both bracket positions give
one meaning and there isn't a positioning that gives the second.
However I see that blatantly the rule is needed. Just because B and C
are possible doesn't mean that people won't try to write A, and it is
completely ludicrous for A to have the meaning of B rather than of C.
Also the rule means that sometimes you might pass fewer args to a
function than you'd intended. This often results in a constant in void
context, which can be warned against. Not having the rule just results
in precedence being different to that intended, which I don't think
could be picked up with a warning!
($obj.foo.bar.baz[3]{finagle}.each.subobj.print length $a), \n;
That's not so good. Unless you make method syntax different from
functions. Which is also not so good.
Method syntax already is different from functions, in that methods
require parens. If functions always required parens this ambiguity
wouldn't exist. (Note I am definitely _not_ suggesting that they
should!)
I do think that . may be the wrong character to eat whitespace
though.
$hash .[$key]
$hash _[$key]
You've convinced me. This sounds to be the best of anything I've seen:
1 It always does the right thing if you use whitespace in the way that
people nearly always do already, making things like this work:
foo (1 + 2), 3;
2 C fans can continue to have this working as they expect:
outer(foo(1), bar(2));
3 Lisp fans can put parens round the outside of function names and get
the behaviour they want (so long as they put a space the function
names).
4 There is a way of changing the behaviour should none of the above be
good enough for you.
Reminds me of the old problem of what to use if we adopted the rule I
keep hankering for that says a final } on a line ends the current
statement.
I still reckon I could live with the consistency of always needing a
semicolon at the end of statements, including loops and sub definitions.
But again I can see why this would frustrate many people, and
continually getting compilation errors because of missing semicolons
would get tedious.
A _ could be made to suppress whitespace interpretation there too,
only on the other end of the bracket:
$x = do { foo(); bar(); baz() }_
+ 2;
So if there's going to be a brace and line-break rule having a way of
overriding would be good. Having the same character used for overriding
all whitespace rules is also good.
Underscore is also the character used to suppress the meaning of
line-breaks in Visual Basic, I think, where there must be a space before
the trailing underscore. I note that any VB programmer trying that
here:
$x = do { foo(); bar(); baz() } _
+ 2;
would end up concatenating the character rather than adding the number 2
on to that expression. I'm wondering if that is too subtle? (I'm
hoping not, because I do like the idea.)
Using _ rather than . would prevent it from being interpreted as a
method call.
I think it's worth having that distinction.
*0 Most function calls required brackets, but they could be omitted
when calling built-in functions which took a single argument. However
if you did include them I'm fairly sure a space wasn't allowed.
*1 I'm hoping the reason for this is that Damian mailed me personally
and I deleted the message, assuming (wrongly) that it'd also be on the
list and I'd find it on the NNTP server later. Cos the alternative is
that I was dreaming about Damian sending me e-mails, and that's _really_
scary.
Smylers
Re: Perl6 Operator List
Simon Cozens wrote: However hard it may be to believe, I'm not just saying this to be snarky; I am excited by Perl 6 and want to see good things come out of it. I just want to make sure that the various creative processes are kept in check. :) Simon, please keep doing this! I think it's better to have too many scares and for those superfluous scares to be allayed, than to have insufficient scares and for something scary to get into the language without being questioned. Smylers
Re: Radix (was Re: Perl6 Operator List)
On 2002-10-26 at 18:10:39, Michael Lazzaro wrote: Larry wrote: If one were going to generalize that, one would be tempted to go the Ada route of specifying the radix explicitly: Ada and others . . . ksh uses the # for this (in place of your colon below), and I seem to recall that syntax being borrowed from an older language, but I don't recall which one. (Although ksh does also have the annoying leading-zero-means-octal behavior when there is no explicit radix). 0123# decimal 2:0110 # binary 8:123 # octal 16:123 # hex 256:192.168.1.0 # base 256 -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
RE: Perl6 Operator List, Take 2
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 this does:
:
: for /home/temp/, $f
: - str $x , int $n {
: $x ~ [one, two, ... , hundreed][$n]
: }
:
: Damian
except that it will not tolerate list in block signature
for /home/temp/, f
- str $x , int y {
...
}
am I right ?
Now it will be
given [/home/temp/, f]
- [ str $x , int y ]{
...
}
?
arcadi
Re: Perl6 Operator List
Simon Cozens wrote:
I just see code like
~~ sub (x) { map { _ = _ } attrs x Inf ^, x }
and get the screaming heaves.
I agree, it's like the punchline to a perl-haters joke. We're supposed
to explain _that_ to people? :-/ NORMAL people? 8-/ And not get
punched in the face?
Maybe there's a line between 'concise' and 'legible', and maybe we
missed the turn a few blocks back, there?
MikeL
Learning curve (was Re: Perl6 Operator List)
Chris Dutton wrote:
So many operators...
Well, this seems a good as time as any to jump in with what's been
sticking in my brain for a while now. Last June, Simon C. wrote a
little philosophical thing, Half measures all around, which generated
the appropriate amount of good discussion. I want to try and make a
case that's sortof tangential to that, but not, at the same time.
Here's my own argument for using like/unlike, and none, and a bunch
of other english-sounding things we haven't even talked about yet.
My general background is in tutoring/mentoring/educating/evangelizing
new programmers, where new either means new to programming, or new
to Perl5, or both. That's my little niche -- taking newbies, and
shoving them up the curve until they know the ins and outs. Pretty
successful at it too, I think. I mention this only because it seems to
be different from the experience of much of perl6-lang ... most of the
people here seem to be more of the expert level, people who you call
because they know Everything Perl, Always. :-) I'm typically more
focused on the beginning-level people.
Premise: So far, we've already gotten Perl6 to be much more powerful
than Perl5, and cleaned up a few of the more troublesome perl5
inconsistencies, but I don't think we've put much of a dent in the
readability complaints that non-perlers often voice (and we all know
I'm being generous in my phrasing, there.) I think we need to care
about these concerns a _lot_ more than we have in the past, simply
because of the cynical but obvious linkages:
1) I want to use Perl6, because I am confident that I can program
things faster in Perl6 than in any other mainstream language.
2) I only want good Perl6 programmers, so I don't give a, um, 'darn'
how much of the random population uses Perl6 in general, BUT...
3) The general population won't use it unless they can easily
understand it through self-study, and/or have been exposed
to it in an educational setting.
4) Joe Manager of Company X won't use it unless he can find
lots of programmers in the general population that know it.
5) If none of the Joe Managers in the other companies use it,
suddenly it puts a lot of pressure on me to explain why *we're*
using it, instead of, say, Java or C#. It's better
doesn't really fly, because the company's non-technical
staff judges better based primarily on the number of
magazine articles that mention the language.
6) Suddenly, my staff using Perl6 becomes a political issue, not a
technology one. I fight the battles, eventually quitting
the industry in disgust and moving to the California desert
where I put up no trespassing signs, dig a series of
inexplicable washing-machine sized holes, and wait for
the impending collapse of human civilization.
OK, that's why we care what the world thinks. Back on topic: so far
we've got conciseness, and a feature set that's essentially the
best-practices compilation of modern, successful programming concepts.
Pretty darn nice.
But understandable, we don't have yet.
Understandability in the large, certainly, is a matter of being able to
express common and/or complicated concepts in a concise enough way to
make the big picture of the program visible. So even though Perl6 is
full of nasty constructs such as '^.|=' and similar, I would argue that
(1) things quite that bad will be reasonably sparse in real programs,
and (2) they comprise so much functionality in such a little package
that the overall flow of what's happening in an algorithm is much more
understandable. Hence we have all hyperoperators, for example -- just
too much utility there *not* to do it.
But our version of understandable still means a steep, steep learning
curve. We need to soften that a bit more for the common cases. My own
solution would be, in part, that we offer english-word aliases like
like, etc., even if they're only meant as training-wheel versions of
the more linenoisy things, wherever we can. So people can be trained on
the words, and graduate to the professional constructs as they become
more comfortable.
My bigger solution would be to reserve a lot more english-sounding
barewords, in all forms, towards the goal of making well-understood
concepts more obvious to newcomers. That's why I've been pushing for
architecturally unnecessary things like using on for events/callbacks/assertions:
my $v on get { ... }
on set { ... };
or using constructs like 'as' and 'from' to do very smart, but very
in-your-face-obvious casting/transformations between types/classes,
instead of relying on more ambiguous constructs:
class MyClass {
from OtherClass { ... } # 'alternate' constructors
from int{ ... }
as int { ... } # 'typecasting' multimethods
as str { ... }
as OtherClass { ... }
}
my MyClass $obj = MyClass.new;
print $obj; # as string
print $obj as int;# as int
or even to just have the
Re: Perl6 Operator List, Take 2
[EMAIL PROTECTED] (Michael Lazzaro) writes:
| ! - superpositional
all any one (none?)
I don't understand this, on several levels. The lowest level on which
I don't understand it is that testing whether an array is full of threes:
@array 3
makes sense, but how do you test if all of its elements are more than six?
@array { $^a 6 } # ?
If you can't do the latter with the same operator as the former, why have
the operator at all?
Suddenly, @array.all?({ |$a| $a 6 }) seems a lot more appealing. :)
--
10. The Earth quakes and the heavens rattle; the beasts of nature flock
together and the nations of men flock apart; volcanoes usher up heat
while elsewhere water becomes ice and melts; and then on other days it
just rains. - Prin. Dis.
Re: Learning curve (was Re: Perl6 Operator List)
[EMAIL PROTECTED] (Michael Lazzaro) writes: But our version of understandable still means a steep, steep learning curve. It's worse than that; for practitioners of many languages, the learning curve has a 180 degree turn. Quick: what are the bitwise operators in Java, JavaScript, C, C++, C#, Perl 5, PHP, Ruby, and Perl 6? Which of these languages do we want to draw programmers from? Someone will now argue that bitwise operators aren't used very often anyway. Great, so we make a change that bites (NPI) people when they least expect it; that makes it all OK. -- BASH is great, it dumps core and has clear documentation. -Ari Suntioinen
Re: Learning curve (was Re: Perl6 Operator List)
On Sat, 26 Oct 2002, Michael Lazzaro wrote: So lets have _lots_ of operators, and _lots_ of two-to-four-letter barewords, so long as they each do something Big, or something Universal. And let's locale-ize them, so that non-english-speakers can use 'umu' to mean 'bool', etc. Hey, why the heck not? Why not? Here is my opinion about localized programming languages. As a non-native English speaker, I like it very much that I *don't* have the possibility to write: afficher pour tableau;# note I used functions that map mon uaelbat = retourner tableau; # to single words in French ;-) And I suspect my non-native French speaker readers like it very much too. I suppose it's very doable to have a FrenchPerl6 editor/parser/whatever that makes most of this transparent, but the thing I like the most about programming languages it that their are foreign languages. And since most of them are based on English, they are just twice as foreign to me. So when I program, I can concentrate on what the syntax of the programming langage accepts, rather than on the sentences I could write if I were using a subset of French. And imagine the pain for all those programmer that do not speak very well their own mother tongue... Should I use effacer, efacer, éfasser when I want to remove a file? With programming languages as there are today, I just have to learn a new word (unlink), and this won't mess my already messy understanding of my own language (pity the one who will read the comments and documentation, though). I admit that knowing a little English can be helpful to guess a function name here and there, though. ;-) Also, remember Microsoft moved back specifically on that topic with the Excel and Word macro-language some years ago. Naturally, this has nothing to do with naming your variables as you like (even Unicode and stuff); variables are another matter entirely. Don't misunderstand me, I love the fact that Perl works like a natural language. It's just that I also understand the fact that it's its own natural (English-looking) language, and not a subset of English. -- BooK PS: I have troubles explaining this view in French as well; please forgive me if I didn't make much sense in English either. -- Philippe BooK Bruhat When you run from your problem, you make it that much harder for good fortune to catch you, as well. (Moral from Groo The Wanderer #14 (Epic))
Re: Perl6 Operator List, Take 2
On Fri, Oct 25, 2002 at 04:10:31PM -0700, Michael Lazzaro wrote: Here's try #2. Things that are not true operators or have other caveats are marked, where known. LMKA. methods and listops, uncategorized: my our map grep sqrtlogsin cos tan lc lcfirstuc ucfirst int ordoct hex (bin?) Why do sqrtlogsin cos tan int ordoct hex (bin?) count as methods, when perl5 has them as numeric functions? And based on perlfunc.pod, I think the uniops abs, log and exp are missing, and the listop atan2. (And is perl6 going to have other more unusual transcendental maths functions such as acos, asin, cosh, sinh, cosec, erf as builtin keywords?) Nicholas Clark -- INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Perl6 Operator List
On Sat, Oct 26, 2002 at 01:59:46AM +0200, Paul Johnson wrote: On Fri, Oct 25, 2002 at 06:28:28PM -0400, Miko O'Sullivan wrote: From: Larry Wall [EMAIL PROTECTED] : ? - force to bool context : ! - force to bool context, negate : + - force to numeric context : - - force to numeric context, negate : ~ - force to string context We're obviously missing the force to string context, negate operator. :-) Mr. Wall, may I be excused? My brain is full. Oh, I have to stick it out with everyone else? OK, um Just so I understand... why do we need force to blah context operators at all? Are we planning on doing a lot of context forcing? Isn't a lot of The negate operators we have already: perl -e '$x = 0; print !$x' perl -e '$x = 10.000; print -$x' Here is something that maybe you'd forgotten: $ perl -lwe '$x = Good; print -$x' -Good $ perl -lwe '$x = -Good; print -$x' +Good $ perl -lwe '$x = -Good; print -$x' +Good $ perl -lwe '$x = +Good; print -$x' -Good Unary plus is actually irrelevant: $ perl -lwe '$x = +Good; print -$x' -Good Nicholas Clark -- Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Perl6 Operator List
On Sat, Oct 26, 2002 at 10:33:04AM +1000, Damian Conway wrote: Brent Dax wrote: Which would create a superposition of all strings besides the given one, right? (Oh crap, I think I gave Damian an idea... :^) ) H. Maybe Cnone is starting to grow on me. Bwah-ha-ha-ha-hah! ;-) I'm worried. *I* thought Damian said that he was on (well earned) sabattical for 3 months, from the end of YAPC::Europe. That was (roughly) 1 month ago. So has he been taking his 3 months simultaneously in parallel universes thanks to some utterly diabolical invention? :-) I fear we don't want to know. Nicholas Clark -- Befunge better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Perl6 Operator List, Take 2
Simon Cozens wrote:
I don't understand this, on several levels. The lowest level on which
I don't understand it is that testing whether an array is full of threes:
array 3
Err...that's not what that does. What you wrote creates a scalar value that
superimposes the scalar values C \array and C 3 .
To test if an array is full of 3's you'd write:
all(array) == 3
makes sense, but how do you test if all of its elements are more than six?
array { $^a 6 } # ?
No. What you wrote is the superposition of C \array and (effectively)
C sub($a){$a6} .
To test if an array is full of greater-than-6's you'd write:
all(array) 6
If you can't do the latter with the same operator as the former, why have
the operator at all?
The operator is for composing superpositions from separate elements. Such as:
$x $y $z == 3 # all three variables equal 3
$x $y $z 6 # all three variables greater than 6
$x $y | $z 6 # either $x and $y greater than 6, or $z greater than 6
Suddenly, array.all?({ |$a| $a 6 }) seems a lot more appealing. :)
More appealing than:
all(array) 6
???
No wonder you put a smiley there. ;-)
Damian
RE: Perl6 Operator List
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 triples ( $x,$y,$z ){ {$x,$y,$z} };
: a ~~ pairs ~~ triples ;
:
: ?
:
: so that ~~ will wrap for loop around pairs and tripples ,
: similar to -n perl flag ;
This doesn't make sense to me. If you're trying to pass the parsed topic list
to them, they should be returning a boolean value. If you're trying to return
a set of values to be compared against a, Perl's not going to also pass a
to your functions.
so maybe it will be usefull to have smart argument binding
operator . it will not be used a lot so it can have long name.
maybe
~ .
map triples, map pairs, a
map is doing piping right-to-left ;
but operations happens in reverse order to
the order in which we read
it .
for doit in 'normal' order but
for a {
pairs ;
triples ;
}
is totally different and
for for a, pairs , triples
looks strange . and we have to adjust for count to number of steps
..
so maybe
a ~ pairs ~ triples ;
arcadi
Radix (was Re: Perl6 Operator List)
Larry wrote: If one were going to generalize that, one would be tempted to go the Ada route of specifying the radix explicitly: 0123# decimal 2:0110 # binary 8:123 # octal 16:123 # hex 256:192.168.1.0 # base 256 Heck that'd be fine with me... then I can easily do stuff in base 36, which I do a lot of. :-/ Still might want a letter shortcut for b/o/h, though. Just as long as 0123 doesn't magically mean octal I'm happy. Stupid, STUPID OCTAL. :-) MikeL
RE: Perl6 Operator List
_ 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
Re: Perl6 Operator List
On 10/26/02 7:24 PM, Simon Cozens wrote: To the innocent bystanders, I hope you're not buying any of this crap about Perl 6 being more regular or removing the inconsistencies of Perl 5. It simply isn't true. I was buying that right up until about a week or two ago when Larry emerged from his cocoon and started pouring scary line noise into this list :-} I've been trying to comfort myself by thinking that these are just the odd corners of the language, and that this stuff will likely only be relevant to people creating their own operators (or overriding existing ones). Larry's just thinking out loud, right? Surely he'll eventually settle down and come up with a sensible solution...right? Right?! Reading the threads from the past few days, I can't help but think of the great loss of '.' as the string concatenation operator debates from the past. Some people were in favor of keeping it and requiring whitespace where necessary to eliminate ambiguity, but the overwhelming consensus seemed to be: No, Perl 6 has to be much more regular than that! Fast forward to a little bit and we get _ as the replacement operator, which (surprise) requires whitespace where necessary to eliminate ambiguity. Fast forward to today and we've got, well, this thread. Seems like the ride is getting bumpy... -John
RE: Perl6 Operator List
but what about placeholders ? arcadi .
Re: Perl6 Operator List
On 10/26/02 8:18 PM, Larry Wall wrote: On 27 Oct 2002, Simon Cozens wrote: : To the innocent bystanders, I'm afraid you're preaching to the null set here. :-) I don't know whether to be flattered that you think I'm not just a bystander, or insulted that you think I'm not innocent ;) -John
Re: Perl6 Operator List, Take 2
Damian Conway wrote: ~~ !~ - smartmatch and/or perl5 '=~' (?) like unlike- (tentative names) Do we *really* need the alphabetic synonyms here? Me no like! I agree with Damian. Clike wouldn't've been a bad name for the Perl 5 C=~ operator; it's at least similar to SQL's CLIKE. However the smart matching is going to do many things in Perl 6, representing tests such as 'is contained in' or 'contains'. I don't think that there's an English word which is flexible enough to represent all the kinds of matching this will do. As such I think it's less confusing to have a special symbol that we all remember as doing 'magic matching' than it would be to have an English word which sometimes has its ordinary English meaning and sometimes has the meaning of a different English word or phrase. Smylers
Re: Perl6 Operator List
Date: Sat, 26 Oct 2002 09:16:41 -0700 (PDT) From: Larry Wall [EMAIL PROTECTED] We're also missing the actual C operators that are guaranteed to return 0 or 1: $x ? $y # C's $x $y $x ?| $y # C's $x || $y $x ?! $y # C's, er, !!$x ^ !!$y And we need those... why? Wouldn't: ?($x $y) ... work? Yes, but we certainly can't have !=. Another argument for not using ! for xor. I guess _ is available as a kind of | laying down. Can't have x. We could use o as short for one or other. $either = 1 o 2; $set o= 1; $comp = o $mask; if $x oo $y $c = $a ~o $b That's very distinctive. I think I could get to like it. We also still have binary ? and \, for whatever reason I mentioned that. Luke
Re: Learning curve (was Re: Perl6 Operator List)
On Sat, Oct 26, 2002 at 09:23:19PM -, Smylers wrote: Michael Lazzaro wrote: Here's my own argument for using like/unlike, and none, and a bunch of other english-sounding things we haven't even talked about yet. ... I don't think we've put much of a dent in the readability complaints ... I think we need to care about these concerns a _lot_ ... I agree that this is an important concern which should be addressed. My own solution would be, in part, that we offer english-word aliases like like, etc., even if they're only meant as training-wheel versions of the more linenoisy things, wherever we can. So people can be trained on the words, and graduate to the professional constructs as they become more comfortable. However I believe that having English aliases would make matters worse. I agree, in general. I was planning on writing something about this. Now I don't have to :-) The only thing I would add, is that this is an experiment that has already been tried. Perl 5 has English.pm. Is is used? Not much. Who uses it? Mostly people writing their first programs. Why is this? Well, I suspect that people read though perlvar and notice the references to English.pm and think that if is comes with the core they should probably be using it. After a while they realise that most people don't use it so they still have to learn the punctuation, and anyway they still have to search perlvar every time they need to know what they should check after calling system(), so what's the point? How many people can even remember the English for $_? Or how to spell The string following whatever was matched by the last successful pattern match? Anyway, you can draw your own conclusions from the experiment. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Perl6 Operator List
You know, \ and friends as xor is appealing to me. There's no problem with \\ or \=, so that works. It's got nothing to do with references, but unary | has nothing to do with anything. Plus, it's parallel (er, perpendicular) to // as err, being logical and all. Just to clarify: \ superpositional one \\ logical xor \= superpositional one-assignment Also, a question about superpositions: Is $x = 1 | 2 | 3 equivalent to $x = 1 | 2 $x |= 3 or $x = (1 | 2) | 3 or is there a difference at all? So the latter is either 3 or the superposition 1 | 2. Does $x == 1 still return true? I guess the root of my question is... do superpositions search deep or shallow? Luke
Re: Learning curve (was Re: Perl6 Operator List)
Paul Johnson wrote: On Sat, Oct 26, 2002 at 09:23:19PM -, Smylers wrote: I believe that having English aliases would make matters worse. I agree, in general. I was planning on writing something about this. Now I don't have to :-) Pleased to be of help! The only thing I would add, is that this is an experiment that has already been tried. Perl 5 has English.pm. Is is used? Not much. Who uses it? Mostly people writing their first programs. Good point. How many people can even remember the English for $_? Or how to spell The string following whatever was matched by the last successful pattern match? There is one situation where I use it. That's for C$UID and friends. I have never bothered to learn which brackets are which in those four variables, and I need them so infrequently that I think the English names make the code considerably more readable. But this is a particular situation where the Perl names are referring directly to pre-existing real-world concepts that already have specific names. Keeping those names makes sense (when compared with seemingly arbitrary punctuation[*0]). It doesn't follow that it makes sense to try to fit names on to concepts that don't have them. C$_ is just 'the current thing I'm dealing with right now', and C~~ could be 'the appropriate kind of match' without having to find single-word English labels. *0 Yes, I'm aware of the mnemonics in perlvar, but I can't recall them fast enough when browsing through code. Smylers
RE: Perl6 Operator List
: 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 unix | pipe .
in the Apo4 the entry says
a ~~ sub ( x ) { ... } b(a)
will it hande that :
a ~~ map { _ = _ }
~~ map { {_,_,_} }
where the first *unsupplyed* argument to map
is expected to be *list* ?
also , is here the following DWIMmery in place
sub pairs ( $x,$y ){ $x = $y } ;
sub triples ( $x,$y,$z ){ {$x,$y,$z} };
a ~~ pairs ~~ triples ;
?
so that ~~ will wrap for loop around pairs and tripples ,
similar to -n perl flag ;
Re: Perl6 Operator List
On Sat, 26 Oct 2002, Larry Wall wrote:
: $union{a} # A | ant
Of course, the interesting question at this point is what
$union{a} = axiomatic;
does if there's more than one hash in the superposition.
Larry
Re: Perl6 Operator List
On Sat, 26 Oct 2002, Damian Conway wrote: : Larry mused: : : : Now I'm wondering whether these should be split into: : : ++|+! - bitwise operations on int : += +|= +!= : : ~~|~! - bitwise operations on str : ~= ~|= ~!= : : I think this is UME (Unnecessary Multiplication of Entities), especially : given: : : +$x .| +$y : ~$x .| ~$y Well, yes, but what does +$x .| ~$y do? I guess in a multimethod world it's too ambiguous to dispatch... We're also missing the actual C operators that are guaranteed to return 0 or 1: $x ? $y# C's $x $y $x ?| $y# C's $x || $y $x ?! $y# C's, er, !!$x ^ !!$y : I think a good case can be made for *not* defining the corresponding : super assignment operators: =, |=, and umm...I guess it would have : to be !=, er... : : I suspect disjunctive superpositions will get a great deal : of use as sets, and so the ability to add an element to an : existing set: : : $set |= $new_element; : : might be appreciated. But it's no big thing. Yes, but we certainly can't have !=. Another argument for not using ! for xor. I guess _ is available as a kind of | laying down. Can't have x. We could use o as short for one or other. $either = 1 o 2; $set o= 1; $comp = o $mask; if $x oo $y $c = $a ~o $b That's very distinctive. I think I could get to like it. : I'd still love to the double angles for a qw synonym. : : I was hoping we'd be able to generalize from the heredoc introducer to : the file slurp operator. But I can certainly see the attraction of: : : use enum d'oh ray me far solar tea; : : ;-) Actually, I meant the French double-angle quotes. Larry
Re: Learning curve (was Re: Perl6 Operator List)
On 26 Oct 2002, Simon Cozens wrote: : [EMAIL PROTECTED] (Michael Lazzaro) writes: : But our version of understandable still means a steep, steep learning : curve. : : It's worse than that; for practitioners of many languages, the learning : curve has a 180 degree turn. : : Quick: what are the bitwise operators in Java, JavaScript, C, C++, C#, : Perl 5, PHP, Ruby, and Perl 6? Which of these languages do we want to : draw programmers from? : : Someone will now argue that bitwise operators aren't used very often anyway. : Great, so we make a change that bites (NPI) people when they least expect : it; that makes it all OK. No, it doesn't make it all OK, but that's why somebody's getting paid to make the hard decisions. It's my job to balance out the short-term pain with the long-term gain. I appreciate that we have a responsibility to current programmers. I also appreciate that we have a responsibility to programmers who haven't even been born yet. Above all, I have an appreciation that what I'm trying to do here is, in fact, completely impossible. That won't stop me from trying. Larry
RE: Perl6 Operator List, Take 2
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 inspect it
or even change .
* do we have have an axcess to the signature of the
subroutine if we have been passed only its reference .
that is , for exemple , can
process( @x , step )
guess how many arguments step expects ?
* how one can write function analogous to for loop that will be able to
handle multiple streams ?
* how one can call subroutine in place
sub (str $x , int $n ) {
$x ~ [one, two, ... , hundreed][$n]
} . (/home/temp/, $f ) ;
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.
thanks ,
arcadi
