After read the "Synopsis 3" I'm thinking that Perl6 is begin too much complex!
I don't think it is. Mostly it just discusses changes. Synopsis 3, point by point:
# -> becomes ., like the rest of the world uses. # The string concatenation . becomes ~. Think of it as "stitching" the two ends of its arguments together.
Just changes; no added complexity. Actually, . is much easier to type than ->.
# Unary ~ now imposes a string context on its argument, and + imposes a numeric context (as opposed to being a no-op in Perl 5). Along the same lines, ? imposes a Boolean context. # Bitwise operators get a data type prefix: +, ~, or ?. For example, | becomes either +| or ~| or ?|, depending on whether the operands are to be treated as numbers, strings, or Boolean values. Left shift << becomes +< , and correspondingly with right shift. Unary ~ becomes either +^ or ~^ or ?^, since a bitwise NOT is like an exclusive-or against solid ones. Note that ?^ is functionally identical to !. ?| differs from || in that ?| always returns a standard Boolean value (either 1 or 0), whereas || returns the actual value of the first of its arguments that is true.
Here things change a little and things do get more complex, but they're not as bad as it looks from this explanation. Hopefully this table makes things a bit more clear:
Perl 6 may get 12 new operators from this change, but it is done in a logically structured way. You don't have to learn 17 operators here. Just learn 8 operators and learn how to combine them into new ones. Consider the word "schoolbus". Someone who knows only "school" and "bus" can easily guess the meaning of "schoolbus"./ P e r l 6 \ Perl 5 Number String Bool Impose context + ~ ? Bitwise OR | +| ~| ?| Logic OR: ||, or Bitwise AND & +& ~& ?& Logic AND: &&, and Bitwise XOR ^ +^ ~^ ?^ Logic XOR: ^^, xor Bitwise NOT ~ +^ ~^ ?^, ! Logic NOT: !, not Bitshift left << +< ~< Bitshift right >> +> ~>
How often have you used | & ^ ~ << >> in Perl 5? Did you need them while you were still learning the language? I don't think beginners need to learn these operators. They'll discover them as they need them.
x splits into two operators: x (which concatenates repetitions of a string to produce a single string), and xx (which creates a list of repetitions of a list or scalar).
This again is only a change.
In fact, the Perl 5 version is more complex here imho.Get a string, Get a list Perl 5 $foo x 5 ($foo) x 5 Perl 6 $foo x 5 $foo xx 5
# Trinary ? : becomes ?? ::. # qw{ ... } gets a synonym: « ... » . For those still living without the blessings of Unicode, that can also be written: << ... >>. # The scalar comma , now constructs a list reference of its operands. You have to use a [-1] subscript to get the last one.
Simple changes. I think «» will be easy to understand for beginners and the [-1] subscript has always been much easier than scalar comma.
Binary // is just like ||, except that it tests its left side for definedness instead of truth. There is a low-precedence form, too: err.
I don't think anyone will mind this new operator. Unless you love writing
the new operator will not make things more complex, but actually easier to write and understand: $foo //= $bar // $baz // $quux;.$foo = $bar if not defined $foo; $foo = $baz if not defined $foo; $foo = $quux if not defined $foo;
Binary => is no longer just a "fancy comma." it now constructs a Pair object that can, among other things, be used to pass named arguments to functions.
No added complexity here, except that we get a neat Pair object, which makes learning how hashes work less complex.
^^ is the high-precedence version of xor.
Perl 5 should already have had this.
Unary . calls its single argument (which must be a method, or an de-referencer for a hash or array) on $_.
Just simple defaulting-to-$_ behaviour as Perl newbies already have to get used to.
... is a unary postfix operator that constructs a semi-infinite (and lazily evaluated) list, starting at the value of its single argument.
This in my opinion is needless complexity, but it does make writing things easier. 5... will be the same as 5 .. Inf. This will probably be used most as 0..., in foreaches:
for zip(@foos, 0...) -> $foo, $i { # Here, $foo is an element of @foo # and $i is its index. }
# However, ... as a term is the "yada, yada, yada" operator, which is used as the body in function prototypes. It dies if it is ever executed.
It makes most of my code examples syntactically correct. I love it :)
$(...) imposes a scalar context on whatever it encloses. Similarly, @(...) and %(...) impose a list and hash context, respectively. These can be interpolated into strings.
I dislike the use of the @ for something that has to do with lists here and think * should be used instead. This does add to complexity.
The Unicode characters » (\xBB) and « (\xAB) and their ASCII digraphs >> and << are used to denote "hyperoperations" – "list" or "vector" or "SIMD" operations that are applied pairwise between corresponding elements of two lists (or arrays) and which return a list (or array) of the results.
It's either this or get people to understand map. Complexity, yes, but for a very good cause.
ormy @sums = @foo »+« @bar;
I know which one I prefer :)my @sums = map { $^a + $^b } zip(@foo, @bar);
|, &, and ^ are no longer bitwise operators (see Operator Renaming) but now serve a much higher cause: they are now the junction constructors.
This also adds to the complexity, but also makes many every day tasks much easier.
orif $foo eq 'bar' | 'baz' | 'quux' { ... } if $foo eq any « bar baz quux » { ... } # Other style
Again, I prefer the complexity as it makes my life easier.if $foo eq 'bar' or $foo eq 'baz' or $foo eq 'quux' { ... }
Perl 6 supports the natural extension to the comparison operators, allowing multiple operands.
Simple maths. No complexity here, imo.
A new form of assignment is present in Perl 6, called "binding," used in place of typeglob assignment. It is performed with the := operator. Instead of replacing the value in a container like normal assignment, it replaces the container itself.
In other words: we get aliases. Aliases aren't hard to grok.
Since typeglobs are being removed, unary * may now serve as a list-flattening operator. It is used to "flatten" an array into a list, usually to allow the array's contents to be used as the arguments of a subroutine call. Note that those arguments still must comply with the subroutine's signature, but the presence of * defers that test until runtime.
Experienced Perl hackers are used to the fact that arrays flatten automatically. For beginners and users of other languages, this is strange. How often do people ask us how one can pass or return multiple arrays with a sub?
The new operators ==> and <== are akin to UNIX pipes, but work with functions that accept and return lists.
I'm not sure I like these. They make things very complex and I don't think they're needed, as for left-to-right writing you can also choose to use array methods.
An appended : marks the invocant when using the indirect-object syntax for Perl 6 method calls.
Explicit indirect object syntax reduces complexity by much. That, and it reduces the number of discussions in this Monastery :)
Perl 6 has a zip function that interleaves the elements of two or more arrays.
Simple and elegant.
Minimal Whitespace DWIMmery
Less difference with interpolated hash/array element syntax, so less complexity. I must admit that I never understood why anyone would like whitespace between aggregate and index. That style is extremely hard to read, imho.
So, summarized: we get some new operators that make our daily tasks easier. These are welcomed by everyone, I think. We also get some new operators for things not many people use. These are welcomed by the people who do use them, because even though the operators will be different and uglier, they will give the coder more control. And there will be some new operators that aren't needed, but probably are nice to have. (Perhaps one day I will like <== and ==>. That day has yet to come, though.)
You refer to other languages that KISS. This keeping it simple makes those languages HARD to use for anything that is complex. Simple and easy are not the same thing. Very often, simple means hard. PHP and Java are good examples.
Where in language design a decision needs to be made between simple and easy, PHP went for simple. This resulted in many, MANY built-in functions to make things a little easier. Java also went for simple. Count the classes and methods. Perl 6 chooses ease over simplicity. It will have many operators, but not as many as PHP and Java have functions/methods.
If the language is simple, the code will be complex. If the language is complex, the code will be simple. I have to deal with the code, so I don't mind the language to be complex.
Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }
In reply to Re: Perl6 syntax being too much complex? How we will teach and read that?!
by Juerd
in thread Perl6 syntax being too much complex? How we will teach and read that?!
by gmpassos
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |