what's new continued
me again,
At the moment based on Apo1-4 no ex's walked yet.
- There is a questions inside feel free to answer ... [?? ... ??]
- Also links for other reference implementation will be good.
- Also feel free to correct my english :)
What's new ?
Let me first mention this is in no means full list of the new features in Perl6, this
is mostly a list pf those features I find most entertainig.
For a detailed description look at all these links :
http://dev.perl.org/perl6/apocalypse/
http://dev.perl.org/perl6/exegesis/
http://dev.perl.org/perl6/synopsis/
And to see what the Larry and crew had to take into account look here :
http://dev.perl.org/rfc/
So lets start
1.) Proprietes ==
reference implementation : Attribute::Types, Attribute::Handlers,
Attribute::Handlers::Prospective
http://www.cpan.org/authors/id/DCONWAY/Attribute-Types-0.10.readme
http://www.cpan.org/authors/id/DCONWAY/Attribute-Handlers-0.76.readme
http://www.cpan.org/authors/id/DCONWAY/Attribute-Handlers-Prospective-0.01.readme
Every subrotine or variable or method or object can have a notes (out of bound data)
attached to it and they are called properties. (Internally properties are hashes --
pHash).
The proprietes can be compile time and run time... (the common case is they to be
compile-time)
Samples :
my $x is constant = 5;#this says that $x is constant and its value is 5
my $x is foo = 0;
Now $x.foo is equal to 1, but $x is 0. In fact $x.foo is interpreted as method call
i.e. $x.foo().
If there is no method with name foo() then such method is pretended to exist and it
returns the value of property with that name.
$x.prop
will return hash-ref to properties hash i.e. pHash-ref.
So that :
print keys %{$x.prop}
will print foo (and probably if SCALAR's have some default props they will be
printed too)
U can also just use :
print keys $x.prop
since the hash ref returned by .prop will be automatically dereferenced by the hash
context of keys.
(In Perl6 we will have much more contexts than that we had under Perl5. Here are part
of them :
Void context
Scalar context
Boolean context
Integer context
Numeric context
String context
Object context
List context
Flattening list context (true list context).
Non-flattening list context (list of scalars/objects)
Lazy list context (list of closures)
Hash list context (list of pairs)
And we will have much more powerfull want operator so that we can check the context
in which the sub are executed.
)
U can specify more props at once and also skip is keyword like this :
my $i is constant note('I use this var for loop counter') maxValue(100) = 0;
instead of :
my $i is constant is note('I use this var for loop counter') is maxValue(100) = 0;
then :
print $i.prop{note}
should print I use this var for loop counter.
2.) Multiway comparison ==
Now we can say :
0 = $x = 10
to check if $x is between 0 and 10 inclusive i.e. 0 = $x $x = 10
3.) Hyper operators ==
Cool no more loop-in-loop-in-loop:). All operators can be hyper-ed simply prepend
them with ^ - upper-cap.
Samples :
a ^* b
multyplies both arrays and will return a list of ( $a[0]*$b[0], $a[1]*$b[1], ...
$a[n]*$b[n] )
OR
( a[0]*@b[0], a[1]*@b[1], ... a[n]*@b[n] ) if we use Perl6 notation/syntax.
a ^+ 1
will return a list of all elements of a increased by one. (a stays uncanged).
a ^ b
will produce a list of (a[0] b[0], a[1] b[1] ...)
a ^|| b
will produce a list of (a[0] || b[0], a[1] || b[1] ...)
Here is how in one sweep we can change some text in every element of array :
foo ^=~ s/foo/bar/
And how to increase the elements of array with 1 but this time applying the changes to
the a
a ^+= 1
we can even have hyper-assignment :
my ($a, $b) ^= new Foo;
The expression below will not distribute over $a and $b :
my ($a, $b) = new Foo;
Let's someone of the anti-perl camp tell me that this upper-cap noise makes the code
hard to read and I will smash him with a hammer in the head :) and leave him to type
from here to tommorow loop after loop after loop after loop :). Gees those perl
designers with LW in the head are mad-scientists .
4.) Binding ==
In addition to the standard assignment operator of perl5 = we will also have :=
i.e. bind operator.
snip - apo3
If you're familiar with Prolog, you can think of it as a sort of unification operator
(though without the implicit backtracking semantics). In human terms, it treats the
left side as a set of formal arguments exactly as if they were in the declaration of a
function, and binds a set of arguments on the right hand side as though they were
being passed to a function. This is what the new := operator does.
/snip
Another way of thinking of it is that:
$a := $b
makes $a another name for the variable
Some regex syntax foibles
Current p6 rx syntax aiui regarding embedded code:
/
#1 do (may include an explicit fail):
{ code }
#2 do with implicit 'or fail'
( code )
#3 interp lit:
$( { code } )
#4 interp as rx:
{ code }
/
This feels cryptic. Do we need abbreviated syntax for
all these cases? If we do, is there a better syntax for
this stuff?
--
ralph
Re: Perl 6 grammar progress?
AW == Ashley Winters [EMAIL PROTECTED] writes: AW Also, where does $() come in? Is statement scalarification ever AW useful outside a string? it is the same as scalar() in perl5. it provides scalar context if used outside a string. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Damian Conway Perl Classes -- July 1-3 -- http://stemsystems.com/class/ --- - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org
Re: Perl 6 grammar progress?
On Monday 01 July 2002 02:30 pm, Uri Guttman wrote: AW == Ashley Winters [EMAIL PROTECTED] writes: AW Also, where does $() come in? Is statement scalarification ever AW useful outside a string? it is the same as scalar() in perl5. it provides scalar context if used outside a string. If the parallel is so close, I assume these 'context' constructs also work? *(squish()) (@lazy) @x = *(@foo, @bar, @baz) = concatenate @x := (foo(), @bar, baz()) = very lazy @x = *(*@baz) = squash a 2d array down to 1d? Perhaps it's enough to list these coercive functions/operators? bit($arg) int($arg) num($arg) str($arg) obj($arg), $scalar, %hash, @array, foo, \$ref scalar($arg), $($arg), $arg list($arg), ($arg) flat(@arg), *(@arg), *@arg lazy(@arg), (@arg), @arg That could make sigil handling pretty easy. foo would mean $($($($foo))) and so forth. Perhaps that's too much? Ashley Winters
Re: Perl 6 grammar progress?
--
On Sun, 30 Jun 2002 21:09:40
Sean O'Rourke wrote:
On Sun, 30 Jun 2002, Ashley Winters wrote:
I don't know how the grammars are going, and I'm not fit to write one
myself,
Hey, neither am I, but that hasn't stopped me from taking a stab or two,
figuring that through pain comes fitness. The attempt has certainly given
me a much better understanding of Perl (both 5 and 6) than I had before as
a mere user. If there's anyone else out there with the time for and
interest in working on a Parse::RecDescent grammar, feel free to speak up.
but I wrote a list of variables I'll try to parse using any
grammars which go by. Are all of these legal? I suppose that's more of
a -language question.
Cc'd accordingly.
# need more tests for ${}, I'm not evil enough for it
${foo};
Neither am I, but we might as well throw in {foo}, %{foo}, {foo}, maybe
even $*{foo} (global symbolic reference?).
# Also, there are globals to consider
[...]
And the wonderous *@$*foo (flattened dereferenced global $foo?).
# off the subject, but lets make sure $foo.. is parsed correctly
$foo..1;
$foo..[1];
$.foo..{1};
Color me slow, but are these even legal? What does an anonymous list
constructor do on the LHS of a range operator? I suppose it could just be
one example of something that is always true, but could it possibly be
useful other than by the perversity of overloading ..? And would the
second require whitespace before the '{' to be parsed as a closure/block?
foo{1}; # I ass_u_me {} [] and () can be overloaded?
Blech! Even if it's legal, this seems like it should be a mandatory smack
upside the head. If we allow this, someone will overload {} to do hash
slices on %foo, and we'll be right back to Perl 5 ;).
foo(1);
foo();
Strange overloading again, or am I missing something? If we allow
subscripting and calling to be overloaded on variables with any kind of
sigil, what's the point of having sigils at all?
foo{1}; # foo is unary here
Is this a hash subscript on a no-argument function returning a hash, or a
block passed to foo(block), or a malformed hash constructor being passed
to foo(%hash)? I vote for the first, because I thought blocks' and
hashes' opening brackets always needed preceding whitespace (or at least
/(?!\w){/).
foo.(); # Is this { foo() }() or foo()? I would vote former
aka foo()()? Sick...
# As a final sanity check, lets chain these things
.proc[$*PID].ps.{RSS};
== {.proc()[$*PID].ps().{RSS}}, right?
proc.[$*PID].ps().{RSS};
== {proc().[$*PID].ps().{RSS}}? Or is that '[]' overloaded on a '.'
operator on 'proc'? In either case, we may have to do a sick amount of
look-ahead and guess-work to figure out whether the leading '' is a sigil
or a dereference. Which has higher precedence: prefix '' or infix '.'?
You might also want to add a couple of directly-chained subscriptings,
e.g.
foo[1]{2}(3)[4..6].
/s,
sufferer at the fickle hands of PerlQt.
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: Perl 6 grammar progress?
On Sunday 30 June 2002 09:09 pm, Sean O'Rourke wrote:
On Sun, 30 Jun 2002, Ashley Winters wrote:
I don't know how the grammars are going, and I'm not fit to write one
myself,
Hey, neither am I, but that hasn't stopped me from taking a stab or two,
figuring that through pain comes fitness. The attempt has certainly given
me a much better understanding of Perl (both 5 and 6) than I had before as
a mere user. If there's anyone else out there with the time for and
interest in working on a Parse::RecDescent grammar, feel free to speak up.
I don't want to do it in Parse::RecDescent, I want to do it in
Parse::FastDescent! Too bad it's not written yet... Damian?
Neither am I, but we might as well throw in {foo}, %{foo}, {foo}, maybe
even $*{foo} (global symbolic reference?).
$*{foo} was in there, at least. I'm still not quite diabolical to come up with
the really screw-your-parser-up kind of stuff. ${}} and such come to mind,
assuming that's legal.
Also, where does $() come in? Is statement scalarification ever useful outside
a string?
# Also, there are globals to consider
[...]
And the wonderous *@$*foo (flattened dereferenced global $foo?).
I didn't do any sigil stacking at all in there, just context characters. I
don't think there will be much sigil stacking, if any, beyond just stacking
$'s to dereference scalar refs.
# off the subject, but lets make sure $foo.. is parsed correctly
$foo..1;
$foo..[1];
$.foo..{1};
Color me slow, but are these even legal? What does an anonymous list
constructor do on the LHS of a range operator? I suppose it could just be
one example of something that is always true, but could it possibly be
useful other than by the perversity of overloading ..? And would the
second require whitespace before the '{' to be parsed as a closure/block?
Well, perhaps PDL will have a reason to overload .. that way. There's no
reason for the parser to choke on it by default - the compiler certainly
should, though.
As for .{}, that's an interesting thing to ponder. From the apocalypse, it
says a { found where an operator is expected without preceding whitespace
would be considered a subscript. Since '.' or '..' is the operator, the next
brace would *normally* start a hash constructor or sub. I would guess '.'
forces the next opening brace to start a subscript, but without the
whitespace rule.
$foo . { $x + 10 }# really means $foo{$x + 10};
Or maybe using binary . in this fashion is Bad?
foo{1}; # I ass_u_me {} [] and () can be overloaded?
Blech! Even if it's legal, this seems like it should be a mandatory smack
upside the head. If we allow this, someone will overload {} to do hash
slices on %foo, and we'll be right back to Perl 5 ;).
Well it's unambiguous, so I expect someone out there will try to be funky.
foo(1);
foo();
Strange overloading again, or am I missing something? If we allow
subscripting and calling to be overloaded on variables with any kind of
sigil, what's the point of having sigils at all?
There isn't much of a 'point' anymore except overlapping variable names. I
would guess the p52p6 translator could do something silly like this:
#!/usr/bin/perl5
x = (500..800);
$y = $x[rand($#x)];
#!/usr/bin/perl6
$x_array := x_array;
x_array = (500..800);
$y_scalar = $x_array[rand($x_array.length)];
The Highlander RFC (009) suggested making x %x and x all mean $x, and Larry
liked the idea in general, but he wanted to keep them separate because people
were used to it that way. Since $foo can be subscripted in all ways, I can
see how other people might want to subscript % as well. If someone were
particularly perverted, they could make subscripts on foo have reflective
consequences. *shrug*
foo{1}; # foo is unary here
Is this a hash subscript on a no-argument function returning a hash, or a
block passed to foo(block), or a malformed hash constructor being passed
to foo(%hash)? I vote for the first, because I thought blocks' and
hashes' opening brackets always needed preceding whitespace (or at least
/(?!\w){/).
I would guess:
foo{1} = ${ foo() }{1}
foo.{1} = ${ foo() }{1}
foo {1} = foo(sub {1});
foo {a = 1} = foo(hash(a = 1));
foo.(); # Is this { foo() }() or foo()? I would vote former
aka foo()()? Sick...
Hey, it has to mean something.
# As a final sanity check, lets chain these things
.proc[$*PID].ps.{RSS};
== {.proc()[$*PID].ps().{RSS}}, right?
Depends on if .member means {.member()}. I thought .member accesses the
actual data, and .member is the accessor function.
== .proc[$*PID].ps().{RSS}
or .proc().[$*PID].ps().{RSS} via accessor
proc.[$*PID].ps().{RSS};
== {proc().[$*PID].ps().{RSS}}? Or is that '[]' overloaded on a '.'
operator on 'proc'? In either case, we may have to do a sick amount of
look-ahead and guess-work to figure out whether the leading '' is a sigil
or a dereference. Which has higher precedence:
