Perl6 Operator List, Take 3
If \ meant xor, and some of the other discussed changes:
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
~ - force to string context
. - method call on current topic
- unary xor [no cooresponding operator]
++- 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
&&||\\// - boolean operations
&&= ||= \\= //=
and orxor err
.&.|.\<<>> - bitwise or charwise operations
.&= .|= .\= <<= >>= - (depending on operants)
- [or maybe +& vs ~&, etc.]
?&?|?\ - [maybe] bitwise operations on bools (as
in C)
?&= ?|= ?\= - (result is always 1 or 0)
& | \ ! - superpositional operations
&=|=\= - intersection, union, disjunction
all any one none
sum prod cat reduce
~~ !~ - smartmatch, perl5 =~,!~
=> - 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
(+ qr ?)
(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
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
Re: Learning curve
Michael Lazzaro wrote: > Heck, I'd even argue that "$a mat $b" works, too. > What does "mat" do? It "mats". If "grep" is a word, "mat" can be a > word. :-) Or "lik". Or "sma". Or just z, as in "matchez" or a twisted "s" $foo mat $bar $foo mz $bar $foo lik $bar $foo z $bar $foo zz $bar $foo vs $bar I know, it's stretching. :-/ But if there's *any* operations we can just use one or two letters for, we can get back some of the needed punctuation chars. With named ops, people don't mind the required whitespace so much. MikeL
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: 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: labeled if blocks
"Steve Canfield" <[EMAIL PROTECTED]> writes:
> Will Perl6 have labeled if blocks? Like this:
>
> BLAH:
> if ($foo) {
> ...
> last BLAH if $bar;
> ...
> }
why not use -> to create a sub which you can return from?
if $foo -> {
...
return if $bar;
...
}
this of course means you can't directly return from the sub (or whatever) in
which the if (or given or while or for) is nested...
slightly related:
what happens to the return value of the subs passed to for, if, while
and given statements? (what does '$foo = if $bar { ... } else { ... }'
do?)
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
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: 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
[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: 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('
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?
