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 (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, 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 (REMAINING ISSUES)
-- On Wed, 30 Oct 2002 16:37:09 Michael Lazzaro wrote: 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 keeps a bracketed syntax, but solves ambiguity issues. Maybe this is a bit radical (but hey, I'm not ashamed) but why not do what Larry proposed way back in Apoc. 1, namely, grabbing from iterators. Angel Faus already made a proposal for grabbing them for a qw() variant. I'd prefer stealing them for hyperop meself. I love hyperops (vector ops, if you prefer), can't easily type +hyperop;, and ^[hyperop] leaves a bad taste in my mouth. Maybe we could give fuel to Cozen's fire by totally dropping consistency, and generalize hypers to some quote like variant allowing you to define your own delimiters. Hey! then maybe hyper is spelled map . . . -Erik -- On Wed, 30 Oct 2002 16:37:09 Michael Lazzaro wrote: 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 keeps a bracketed syntax, but solves ambiguity issues. 2) Possible inclusion of unary prefix ^, meaning complement. (Assuming doesn't conflict with (1)) 3) Possible inclusion of like/unlike or similar as synonyms for ~~ !~. Which we don't have to decide now. All other op issues, by my count, revolve around the meanings of specific hyperop constructs. There is one, overriding question with the hyperops, which is the precise relation between an op, an assignment op, and their (three!) hyperop equivs: A op B A op= B A ^[op] B A ^[op=] B A ^[op]= B If we can formalize the precise relationship between the three hypers in the presence of scalar and list (and hash?) values for A and B, I believe we can answer nearly all the hyperop questions definitively. For example: a ^[op] b # array v array $a ^[op] b # scalar v array a ^[op] $b # array v scalar $a ^[op] $b # scalar v scalar a ^[op=] b # array v array $a ^[op=] b # scalar v array a ^[op=] $b # array v scalar $a ^[op=] $b # scalar v scalar a ^[op]= b # array v array $a ^[op]= b # scalar v array a ^[op]= $b # array v scalar $a ^[op]= $b # scalar v scalar Some of these are nonsensical, some of them aren't. So which are which, and can someone demonstrate that the rule holds true for ALL hyperoperators, as opposed to just MOST? ;-) MikeL Get 25MB of email storage with Lycos Mail Plus! Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Re: Perl6 Operator List, Take 3
On Mon, 28 Oct 2002 13:09:37 -0800 (PST), Larry Wall [EMAIL PROTECTED] wrote: How do your read $a ! $b ! $c? Neither $a nor $b nor $c. What? Aren't you able to see this invisible neither operator just at the front? ;-) /L/e/k/t/u
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
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
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
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, 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: Radix (was Re: Perl6 Operator List)
On Sun, 27 Oct 2002, Mark J. Reed wrote: : 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. Well, that's Ada, actually. I substituted the colon because I didn't want to overload our comment character. Though numbers could do that, just as m## already does. I presume that m## is one of those things you avoid in IDEs though. Something to be said for disallowing m## while we're disallowing m:: and m(). Something to be said against it too... Larry
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
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 4
$accumulator += +X10;
Looks like hex arithmetic.
=Austin
--- Michael Lazzaro [EMAIL PROTECTED] wrote:
Okay, take 4, with 'X' meaning xor, so you can see it in context. I
warn ya, I'm gonna keep doing this until there's a Final version,
for
some value of Final. ;-) 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?
(I'm just leaving some of the questionable ops in for now, it's
easier
to take them out later than re-add them for the various iterations.)
unary (prefix) operators:
\ - reference to
* - list flattening
? - force to bool context
! - force to bool context, negate
not - force to bool context, negate
+ - force to numeric context
- - force to numeric context, negate
+X- force to numeric context, complement
~ - force to string context
~X- force to string context, complement
. - method call on current topic
++- preincrement
--- predecrement
unary (postfix) operators:
++- postincrement
--- postdecrement
... - [maybe] same as ..Inf
other postfix operators:
()- (when operator is expected)
[]- array access
{}- hash access
magical whitespace modifier
_ - remove whitespace/newline
hyperoperators:
^ - as prefix to any unary/binary operator, vectorizes the
operator
binary operators:
+-*/%**xxx~
+= -= *= /= %= **= x= xx= ~=
= = == != =
lt gt le ge eq ne cmp
||XX// - boolean operations
= ||= XX= //=
and orxor err
..|.X- bitwise operations
.= .|= .X= = = - [maybe charwise too]
~~|~X~~- [maybe] charwise operations
~= ~|= ~X= ~= ~=
??|?X - [maybe] C-like bool operations
?= ?|= ?X= - (result is always just 1 or 0)
| X - superpositional operations
=|=X= - intersection, union, disjunction
! - [maybe]
all any one none
sum prod cat reduce
~~ !~ - smartmatch, perl5 =~, !~
like unlike- [maybe]
= - pair creator
,- list creator
;- greater comma, list-of-lists creator
:- adverbial
.- method call
.. - range
... - [maybe] range, exclusive of endpoint
=- assignment
:= - binding
::= - binding, but more so
trinary operator:
?? ::- if/else
parens, misc, and quotelike operators
()
[]- [when term is expected]
{}- [when term is expected]
m// - shorthand, matches
s/// - shorthand, substitute
tr/// - shorthand, transliterate
'...' ... `...` /.../
q qq qx rx qw [qm?]
(+ qr ?)
...- readline
(heredocs) - [exact format unknown]
named unary (prefix) operators, terms, and other assorteds,
identified
when possible:
-X- [op] filetest operators
temp - [op]
let - [op]
ref - [op]
defined - [op]
undef - [op]
undef - [term]
exists- [op]
delete- [op]
but - [op] val properties
${ } - [deref] dereference scalarref
@{ } - [deref]
%{ } - [deref]
{ } - [deref]
... - [term] yada**3
Inf - [term]
Nan - [term]
is- [declar] var properties
-- [declar] like 'sub'
hash - [declar] force hash context
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...)
other uncategorized:
my our - [declar]
mapgrep
sqrt log sin cos tan (etc...) - math
lc lcfirst uc ucfirst
intord oct hex bin
MikeL
__
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
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
0x14 is questionably defined. 0X14 currently is an expression whose value is 14. 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. (Is it a negative hexadecimal number, or a boolean representing file permissions, or something far more sinister?) =Austin --- Mark J. Reed [EMAIL PROTECTED] 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. 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 __ Yahoo! - We Remember 9-11: A tribute to the more than 3,000 lives lost http://dir.remember.yahoo.com/tribute
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 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
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, 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
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 Then we could allow a ^.~|= b; # hyper bitwise string or-equals Eek! Now, where did I put those dried frog pills??? 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. 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; ;-) : (heredocs) - (exact format unknown) I have a paper (coming) on that. Damian
Re: Perl6 Operator List, Take 2
[EMAIL PROTECTED] (Damian Conway) writes:
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
Ah, I see. So (x y) is equivalent to all(x,y) ?
Suddenly, @array.all?({ |$a| $a 6 }) seems a lot more appealing. :)
More appealing than:
all(@array) 6
Yes. But then, if I want Ruby, I know perfectly well where to find it.
--
The Blit is a nice terminal, but it runs emacs.
Re: Perl6 Operator List
On Sat, Oct 26, 2002 at 11:24:23AM +0100, Nicholas Clark wrote: 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 I hadn't actually forgotton - I even re-read Symbolic Unary Operators in perlop, but I didn't want to wander too far off into strange Perl 5 territory. Miko actually wrote at the end of his mesage: ] -Miko ] uh oh, I just forced myself into numeric context and negated myself $ perl -lwe 'my $x = -Miko; print -$x' +Miko $ perl -lwe 'my $x = +Miko; print -$x' -Miko $ perl -Mstrict -lwe 'my $x = -Miko; print -$x' +Miko $ perl -Mstrict -lwe 'my $x = +Miko; print -$x' Bareword Miko not allowed while strict subs in use at -e line 1. Execution of -e aborted due to compilation errors. I know why that is, at least technically, but didn't fancy trying to explain why it should be like that from a language design point of view. Although I'm sure someone here could do that ;-) -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
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
Re: Perl6 Operator List
Larry Wall wrote: : Now I'm wondering whether these should be split into: : : ++|+! - bitwise operations on int : += +|= +!= : : ~~|~! - bitwise operations on str : ~= ~|= ~!= Well, wait, these might have some promise, I think. Using the '.' for them is still a little non-intuitive, even though it is very bit-like. (We're going to be using the dot everywhere else to mean 'method', I don't know if it's obvious that the dot will, in this one context, mean something completely different?) And bitwise-string and bitwise-int are pretty different, and those (above) look pretty much like what they are... 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; In a fever dream, I was once hoping that we could introduce 'o' or maybe 'c' to mean 'octal', to solve one of the most annoying things computing has inflicted upon me: 123 # 123, decimal 0123# 123, octal. WHAT??? WHY??? '0123' # FINE, so what's this, and why??? and changing that to: 0123# decimal 0b0110 # binary 0o123 # octal 0x123 # hex I know, I know, that's completely not-the-culture. Just always bugs me. Stupid tradition. :-P MikeL
RE: Perl6 Operator List, Take 2
On Sat, 26 Oct 2002, fearcadi wrote:
: * are stream separators ; | in the for loop - operators
: in the usual sence ( like , ) or they are pure grammar ?
If ;, probably operator, though behaving a bit differently on
the left of - than on the right, since the right is essentially
a signature. Ordinarily a ; in a signature would be taken to
mean optional arguments, but for would hide that meaning.
If we used and | they'd have to be pure grammar, since they're
not really doing superpositions.
: * 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 .
I have been resisting the notion that the signature can be generalized
into a regex. I'd rather have it separate, so that parsing is a
separate concern from the list of input arguments. In my tome last
night I was actually putting regex-ese into the name rather than the
signature, like this:
sub term:qaquotestr (str $quotestr) { ... }
which would presumably define a qa// term. But maybe that's putting
too much load onto the term: notation. Maybe it should be
sub term:qa (str $quotestr) is parsed /qaquotestr/ { ... }
Or maybe it should be something else entirely. In any event, all
the information should be stored somewhere where it can be inspected,
almost certainly in ordinary properties. In fact,
my int sub foo (int $x) { ... }
is really syntactic sugar for something like:
my foo is retsig (int) is sig (int $x) is body { ... }
which may in turn be syntactic sugar for:
my foo ::= new Code(retsig = (int),
sig = (int $x),
body = { ... });
: * 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 ?
I don't see why not, if a sub ref is pointing at its descriptor as
it does in Perl 5.
: * how one can write function analogous to for loop that will be able to
: handle multiple streams ?
That depends on whether ; is an operator or pure grammar. :-)
In either case, the body of the function is going to get in the
separate streams as an array of lists. The signature will also have
to come in as a sequence-separated list, so that the routine can match
up the streams. I expect that for might have an immediate component
(read macro) that analyzes the number of streams at compile time
so as to call an efficient looping algorithm for the common cases.
: * 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.
But that argument can certainly be a list, and it seems like it would
not be too terribly difficult to make it do the signature binding
just the same as if they were function arguments.
In fact, I'm thinking about a Haskellish way to take any argument
that's a list reference and map it against a sub-signature.
Something like:
sub foo ([$head, *tail], *other) { ... }
foo( [1,2,3], 4,5,6 );
with the result that the parameters are bound like this:
$head := 1
tail := 2,3
other := 4,5,6
Or maybe the declaration of a sub-signature just uses parens like the
outer ones:
sub foo (($head, *tail), *otherargs) { ... }
That's less distinctive but more consistent. On the other hand,
there are perhaps reasons to distinguish a sub-signature that
parses multiple args from a sub-signature that parses a single
list arg.
In that frame of mind, your latter case might just work right out of the
box. The given supplies a scalar context to its left argument, so
the (/home/tmp/, $f) is taken to mean [/home/tmp/,$f]. And that
is a valid list to feed to the sub-signature on the right. At worst,
you might have to use [] on the right instead of (). If so, it'd probably
be better to use it on both sides:
given [ /home/temp/, $f ]
- [ str $x , int $n ] { ... }
Note that the topic in the given is an array ref in this case, not the
the first element of the list.
Larry
RE: Perl6 Operator List
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 breed } ;
my Pet @list = qw {
fido dog collie
fluffy cat siamese
} ~~ sub (@x) { map -($x,$y,$z){
{ @attrs ^= ($x,$y,$z) } @x
}
or
my Pet @list = for qw {
fido dog collie
fluffy cat siamese
} - ($x,$y,$z){
{ @attrs ^= ($x,$y,$z) }
}
if for works likek map .
arcadi
Re: Perl6 Operator List
On Sat, 26 Oct 2002, Michael Lazzaro wrote: : Date: Sat, 26 Oct 2002 10:57:01 -0700 : From: Michael Lazzaro [EMAIL PROTECTED] : To: Larry Wall [EMAIL PROTECTED] : Cc: Damian Conway [EMAIL PROTECTED], : [EMAIL PROTECTED] [EMAIL PROTECTED] : Subject: Re: Perl6 Operator List : : Larry Wall wrote: : : Now I'm wondering whether these should be split into: : : : : ++|+! - bitwise operations on int : : += +|= +!= : : : : ~~|~! - bitwise operations on str : : ~= ~|= ~!= : : Well, wait, these might have some promise, I think. Using the '.' for : them is still a little non-intuitive, even though it is very bit-like. : (We're going to be using the dot everywhere else to mean 'method', I : don't know if it's obvious that the dot will, in this one context, mean : something completely different?) And bitwise-string and bitwise-int are : pretty different, and those (above) look pretty much like what they are... And you get the C || and for free ??|?! - bitwise operations on booleans ?= ?|= ?!= Yes, it's redundant to say bitwise and boolean together. :-) But distinguishing int ops from str ops fixes the really nasty rule in Perl 5 that says If this value (these values) has (have) ever been used in a string context... Or was it a numeric context? I can't remember. And hey, if I can't remember... : 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; : : In a fever dream, I was once hoping that we could introduce 'o' or maybe : 'c' to mean 'octal', to solve one of the most annoying things computing : has inflicted upon me: : : 123 # 123, decimal : 0123# 123, octal. WHAT??? WHY??? : '0123' # FINE, so what's this, and why??? : : and changing that to: : : 0123# decimal : 0b0110 # binary : 0o123 # octal : 0x123 # hex : : I know, I know, that's completely not-the-culture. Just always bugs me. : Stupid tradition. :-P 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 or some such. Larry
RE: Perl6 Operator List
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 @attrs= ;
my Pet @list = map {
{ qw{name type breed } ^= ($^x, $^y, $^z) }
} qw{
fido dog collie
fluffy cat siamese
};
or
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 ;
arcadi
Re: Perl6 Operator List
On Sat, 26 Oct 2002, Damian Conway wrote:
: 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.
Or maybe it is a big thing. People keep asking why they can't say
$a[1][2] = 2;
$a[1]{a} = A; # type error?
Well, maybe they can now:
$union = [1,2,4,8];
$union |= {a = A, b = B, c = C};
$union[2] # 4
$union{a} # A
It's not just a union, of course. You can go on to say:
$union |= {a = ant, b = bug, c = catepilllar};
$union{a} # A | ant
That's all assuming that [] and {} (and (), for that matter) actually
select only appropriate refs from the superposition of refs.
Larry
RE: Perl6 Operator List
On Sat, 26 Oct 2002, fearcadi wrote:
: 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 @attrs= ;
: my Pet @list = map {
: { qw{name type breed } ^= ($^x, $^y, $^z) }
: } qw{
: fido dog collie
: fluffy cat siamese
: };
:
: or
:
: 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 ;
Well, you can do that, but I can guarantee people are going to want
syntactic sugar.
Larry
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: Learning curve (was Re: Perl6 Operator List)
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. They would make the language bigger. That's more to learn over all. There is already lots to learn in Perl, and I think having unnecessary duplication would make that even more work. Beginners would not need to learn the symbolic versions for writing their own code, but they'd need to be able to read the symbolic versions for reading other people's. And given how many people first encounter Perl by downloading somebody else's script from the web or by being thrown into maintenance of something written by a former employee, being able to read others' code is important. It's also slightly patronising. We don't think you're good enough to play with the punctuation characters yet, but here's some alphanumerics to use instead. Would people submitting code in public forums get labelled as newbies because they've chosen to use the lettered versions? Would gurus who know the punctuation forms use the English versions so as to make their code more readable for beginners? Would this actually help beginners or merely make the situation worse when they finally do encounter the punctuation forms? Having exact synonyms also violates the principle that similar things should look similar. On encountering something 'new' in a program I would expect it to do something different. If I see C+ and already know that C+ means numify in Perl and that C is bitwise and in C (etc) then I might be able to guess that C+ is numeric bitwise and. But if I thought that I already knew that the symbol for that operation was Cnumbitand then I'd be less likely to guess the meaning of C+ cos I'd be searching among the space of things I didn't already know how to do. Finally, what happens to C and Cand and friends? If they become synonyms we lose a convenient distinction. If they remain as they are we have a language where many ops have synonymous symbolic and English forms for 'ease of learning' but a few instead have precedence differences. If we come up with an English synonym for C and a symbolic synonym for Cand I don't think that'd really help. This is only objecting to having English operators as synonyms for symbolic ones. None of the above would apply if where English forms were used they were to be the _only_ forms, with no symbolic equivalents. 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. I think that makes sense where there are appropriate words to use. However many of the concepts we're dealing with don't have obvious everyday-English equivalents. Numbitand certainly isn't an English word. Even for concepts such as map and hash I don't think the English word is a great help to many beginners: they know maps as things you look at to get lost when driving, and merely have to remember that Perl uses map mean 'like a loop but giving a list of values'. I wouldn't like to speculate on what they know as hash, but again it's a jargon word with a specific meaning in Perl largely unassociated with anything in real life. We're talking about having lots of operators in Perl 6. There are potentially twenty-four different or operations[*0]. I don't think there are twenty-four different English words which can usefully denote those meanings in a memorable way. At least combining symbols means that patterns can be learnt. That makes me sound against having English operators at all. I'm not. I agree that well-chosen English words will be more readable for beginners and that that is a good thing, even if it means some gurus having to type four letters instead of two symbols[*2]. But I can see it being hard to solve in some places. *0 Logical high precedence, logical low precedence, superpositional, numeric bitwise, string bitwise (that's five), all with exclusive-or variants (ten), plus the or-defined variants at two levels of precedence (twelve) all of which can be hyped[*1] over a list (twenty-four) *1 I'm not sure that hyped is the correct verb here for applied over a list with the hyper operator, but it sounded better than hypered. *2 Which when you take Shift into account, and the fact that punctuation symbols seem to move around on
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: Perl6 Operator List
Larry Wall wrote: I think we also need to fix this: print (length $a), \n; The problem with Perl 5's rule, If it looks like a function, it *is* a function, is that the above doesn't actually look like a function to most people. Yup, definitely. This is one of the things that is most awkward about teaching Perl 5 beginners. It isn't nice to have to explain the intricacies of this right at the beginning of the course, but not doing so leads to people getting caught by it and not realizing why. I'm thinking we need a rule that says you can't put a space before a dereferencing (...), I'm concerned that making this sensitive to whitespace doesn't simplify things. print(length $a), \n; print (length $a), \n; Those look to me like they should do the same thing as each other. Distinguishing them sounds scary, much scarier than having C$a _ 1 being different from C$a_1. How much is the 'if it looks like a function it is a function' rule needed at all? What would be the harm in not having any special rule here, so both of the above pass the line-break to Cprint? Somebody needing to ensure that Cprint only got one argument could do: (print length $a), \n; That is, parens always go round the outside of the thing they are grouping even when the thing is a function call. That would be counter-intuitive to anybody coming from a background in a language where parens have to be used in all function calls, but: 1 It has the benefit of there being one simple rule to learn, with no caveats about functions (or whitespace). Even when somebody gets it wrong, it's a case of showing how the general rule should be applied in this particular case rather than introducing an exception; that should be easier to learn. 2 There's no need to have any sort of disambiguating character (like the current C+ or the suggested C. (with opposite meanings)). 3 If somebody wants to put parens after all her/his function names they often won't do any harm. I don't think the default situation for somebody who doesn't know the rules is made worse. There are some situations made 'worse', and some, like the above, made 'better'. Smylers
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, Take 2
Simon Cozens wrote: Ah, I see. So (x y) is equivalent to all(x,y) ? Yes. Cany, Call, and Cone are the n-ary prefix versions of binary infix C|, C, C! respectively. One might imagine others of this ilk too, perhaps: BinaryN-ary +sum *prod ~cat genericreduce Damian
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
