Re: method calls on $self
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> to go with everyone else's preferences: LW> use self "." LW> use self "`" LW> use self "·" LW> use self ".." LW> use self "^." LW> use self "i." LW> use self "o." LW> use self "¤." LW> use self "me." LW> use self "self." LW> use self "this." LW> Did I leave anyone out? use self "that." use self "over_there." use self "where_am_i." use self "dis." use self "dat." use self "you." :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: File.seek() interface
On Thu, Jul 07, 2005 at 06:15:03PM -0700, Paul Hodges wrote: : : : --- Larry Wall <[EMAIL PROTECTED]> wrote: : > Arguably, we could probably admit : > : > $fh.pos = 10`bytes : > : > for the case of seeking from the begining. But I'd kind of like : > : > $fh.pos = 10 : > : > to be considered an error. : : It seems a logical extension also to say : : $fh.pos += 10`bytes : : as shorthand for : : $fh.pos = $fh.cur + 10`bytes .pos and .cur are the same thing. So just call them both .pos, I think. : Likewise for -= : : But then that begs the questions of *= (not too nuts), /= (same), : %= (great for fixed length records?) and the predictable other host of : operators. : : Am I reaching? No. The stupid people are the ones proposing to outlaw stupidity. :-) Larry
Re: method calls on $self
The basic problem is that I always hated looking at C++ and not knowing whether I was looking at a function or a method, so I'm not going to make standard Perl work like that. On the other hand, there's always use self ""; to go with everyone else's preferences: use self "." use self "`" use self "·" use self ".." use self "^." use self "i." use self "o." use self "¤." use self "me." use self "self." use self "this." Did I leave anyone out? Larry
Re: method calls on $self
On 7/8/05, Robin Redeker <[EMAIL PROTECTED]> wrote: > Hi, > > i just wanted to ask what was about the method calling syntax on > $self, and why does > >method () > > not work for calling a method on $self? (like in C++) IIRC, Larry wants to be able to distinguish method calls from sub calls, so that when you see 'foo()' inside a method, you know that it's NOT using $?SELF. If you want to call a method, either use an explicit self, or use './method'. (As a side note, putting space between the sub/method name and the call parentheses is now disallowed. If you must have the space, you need to use '.()'.) Stuart
Re: File.seek() interface
On Thu, Jul 07, 2005 at 05:58:53PM -0700, Larry Wall wrote:
> $fh.pos = $fh.pos + 10`lines
I'm sorry if this has been discussed, but is the ` going to be in
Perl 6? I like it. :) How does it work, though?
sub *infix:<`> (Num $amount, Unit $class) { $class.new($amount) }
Or so?
Now I'm tempted to make it a generic infix .new.
(args)`Class;
It's almost as confusing as SML!
--
wolverian
pgpjlZIJ8VhS2.pgp
Description: PGP signature
Re: File.seek() interface
--- Larry Wall <[EMAIL PROTECTED]> wrote: > Arguably, we could probably admit > > $fh.pos = 10`bytes > > for the case of seeking from the begining. But I'd kind of like > > $fh.pos = 10 > > to be considered an error. It seems a logical extension also to say $fh.pos += 10`bytes as shorthand for $fh.pos = $fh.cur + 10`bytes Likewise for -= But then that begs the questions of *= (not too nuts), /= (same), %= (great for fixed length records?) and the predictable other host of operators. Am I reaching? Paul Sell on Yahoo! Auctions no fees. Bid on great items. http://auctions.yahoo.com/
Re: File.seek() interface
On Thu, Jul 07, 2005 at 02:15:19PM -0600, Paul Seamons wrote: : > We should approach this from the perspective that $fh is an iterator, so : > the general problem is "how do we navigate a random-access iterator?". : : Well - I kind of thought that $fh was a filehandle that knew how to behave : like an iterator if asked to do so. Yes, basically. And they fall into that class of iterators that may or may not know how to back up, so it may be quite possible to seek forward 10 items but not backward 10 items, if "item" is, for example, a line defined by an asymmetric match rule. : There are too many applications that : need to jump around using seek. We need to have a POSIXly correct layer, but that's no reason not to have other layers on top of that with more useful semantics. I view files as just funny-looking strings, in the abstract. So the same issues arise that we've talked about concerning strings in Unicode, and that's even before we get into counting lines or paragraphs. Like a string, a file may naturally allow itself to be viewed as bytes (POSIX), codepoints, graphemes, and/or characters in the current language. It can allow multiple views into the same abstract string, but as with strings, it may limit the minimum and maximum abstraction level you're allowed to deal with the file. And depending on the file/string representation, one of the abstraction levels is likely to be very efficient to seek around in, and others have to be emulated by visiting all the intermediate items. Some file structures are great at indexing into lines but lousy at indexing into anything smaller than that. A file position in such a file is not even going to be an integer, but a line number plus an offset into the line. I realize we most of us come from the POSIXly-correct worldview that all files are really just sequence of bytes that can always be indexed by integer. This view doesn't make a lot of sense any more in the world of Unicode. We see various versions of Unix/Linux being caught with their pants down because there's no metadata to tell you the character encoding of the filenames, for instance. Perl 6 must not fall into that trap. In the discussion of seek(), this primarily means that you must keep reminding yourself that file positions (and string positions) are not necessarily numbers. Treat them as opaque recipes for navigating into a file, because you don't know what the most efficient underlying representation is. It might even be some kind of URI. At the same time, all relative navigation *must* specify the units. We can't simply assume bytes any more. And if you specify navigation in a smaller unit than the natural unit of the file/string in question, you have to either give it a round-up or round-down instruction, or be prepared to handle an exception of some sort. A UTF-8 handler has the nice property that it can tell if it has landed in the middle of a character, but it can't read your mind about what to do when that happens. : The options that need to be there are: :seek from the beginning :seek from the end :seek from the current location : : Now it could be simplified a bit to the following cases: : : $fh.seek(10); # from the beginning forward 10 : $fh.seek(-10); # from the end backwards 10 Apart from the units and allignment problem, does $fh.seek(-0) mean the beginning or the end of the file? : $fh.seek(10, :relative); # from the current location forward 10 : $fh.seek(-10, :relative); # from the current location backward 10 Again, 10 whats? Bytes? Codepoints? Lines? I think I'd actually like to divorce the notion of going to a particular position from the notion of relative navigation. So I'm in favor of $fh.seek taking *only* an opaque position, and $fh.beg and $fh.cur and $fh.end returning opaque positions. Then there are navigation commands that can take an opaque position and move relative to them a given number of units, and we force the units to be specified. Something like: $fh.pos = $fh.pos + 10`lines Arguably, we could probably admit $fh.pos = 10`bytes for the case of seeking from the begining. But I'd kind of like $fh.pos = 10 to be considered an error. Note also that we can treat string positions exactly the same way. All the rule-ishly returned positions are defined as opaque objects already. Larry
Re: method calls on $self
On Thu, Jul 07, 2005 at 04:08:17PM -0500, Jonathan Scott Duff wrote: > On Thu, Jul 07, 2005 at 10:32:37PM +0200, Robin Redeker wrote: > > Hi, > > > > i just wanted to ask what was about the method calling syntax on > > $self, and why does > > > >method () > > > > not work for calling a method on $self? (like in C++) > > Because perl can't distinguish between the method foo() and the > subroutine foo(). Or are you proposing that methods be added to the > search space for name resolution? Yes, why not? I don't see any conflicts for moving the methods into the search space for methods. Robin -- [EMAIL PROTECTED] / [EMAIL PROTECTED] Robin Redeker
Re: File.seek() interface
On 7/7/05, wolverian <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 07, 2005 at 08:18:40PM +0300, wolverian wrote:
> > I'm a pretty high level guy, so I don't know about the performance
> > implications of that. Maybe we want to keep seek() low level, anyway.
>
> Sorry about replying to myself, but I want to ask a further question on
> this.
>
> Would it be possible to make this work, efficiently:
>
> for =$fh[-10 ...] -> $line { ... }
>
> to iterate over the last ten lines?
No. Most notably because -10 ... gives (-10, -9, ... -1, 0, 1, 2, 3,
...). I also don't think that without a special interface filehandles
can behave as an array of lines. If they could, then you'd have:
for $fh[-10..-1] -> $line {...}
> Can we generalise that to be as performance-effective as seek()?
Perhaps. That's what tail(1) does. But it's a tricky problem. You
have to guess where the end should be, then do a binary search on the
number of lines after your position. Sounds like a job for a
specialized module to me.
If you don't care about speed, then I suppose you could even do:
for [ =$fh ].[-10..-1] -> $line {...}
Which won't be speed efficient, and may or may not be memory
efficient, depending on the implementation. I'd guess not.
Luke
Re: method calls on $self
On Thu, Jul 07, 2005 at 10:32:37PM +0200, Robin Redeker wrote: > Hi, > > i just wanted to ask what was about the method calling syntax on > $self, and why does > >method () > > not work for calling a method on $self? (like in C++) Because perl can't distinguish between the method foo() and the subroutine foo(). Or are you proposing that methods be added to the search space for name resolution? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
method calls on $self
Hi, i just wanted to ask what was about the method calling syntax on $self, and why does method () not work for calling a method on $self? (like in C++) cya, Robin -- [EMAIL PROTECTED] / [EMAIL PROTECTED] Robin Redeker
Re: File.seek() interface
On Thu, Jul 07, 2005 at 08:18:40PM +0300, wolverian wrote:
> I'm a pretty high level guy, so I don't know about the performance
> implications of that. Maybe we want to keep seek() low level, anyway.
Sorry about replying to myself, but I want to ask a further question on
this.
Would it be possible to make this work, efficiently:
for =$fh[-10 ...] -> $line { ... }
to iterate over the last ten lines?
Can we generalise that to be as performance-effective as seek()?
Okay, that was two questions.
--
wolverian
pgpycSBdP1sNK.pgp
Description: PGP signature
Re: File.seek() interface
> We should approach this from the perspective that $fh is an iterator, so > the general problem is "how do we navigate a random-access iterator?". Well - I kind of thought that $fh was a filehandle that knew how to behave like an iterator if asked to do so. There are too many applications that need to jump around using seek. The options that need to be there are: seek from the beginning seek from the end seek from the current location Now it could be simplified a bit to the following cases: $fh.seek(10); # from the beginning forward 10 $fh.seek(-10); # from the end backwards 10 $fh.seek(10, :relative); # from the current location forward 10 $fh.seek(-10, :relative); # from the current location backward 10 Paul
Re: File.seek() interface
Wolverian wrote: Or maybe we don't need such an adverb at all, and instead use $fh.seek($fh.end - 10); I'm a pretty high level guy, so I don't know about the performance implications of that. Maybe we want to keep seek() low level, anyway. Any thoughts/decisions? We should approach this from the perspective that $fh is an iterator, so the general problem is "how do we navigate a random-access iterator?". I have a feeling that the "correct" semantics are closer to: $fh = $fh.file.end - 10 though the short form ($fh = $fh.end - 10) is a reasonable shortcut.
File.seek() interface
Hello, gaal is porting the Perl 5 filehandle functions to a Perl 6 OO interface. The Perl 5 interface with global constants from Fcntl strikes me as severely lacking in elegance and OO. $fh.seek(-10, SEEK_END); Instead of globals, how about a :from adverb? $fh.seek(-10, :from); Or maybe we don't need such an adverb at all, and instead use $fh.seek($fh.end - 10); I'm a pretty high level guy, so I don't know about the performance implications of that. Maybe we want to keep seek() low level, anyway. Subject to change when it comes to the Perl 6 Unicode semantics, of course. :) Any thoughts/decisions? -- wolverian pgpjdFXn6ex1J.pgp Description: PGP signature
Re: Type variables vs type literals
HaloO Larry,
you wrote:
: Could you explain what exactly 'run-time lazy type aliasing' is?
: I mean what does it achieve and how does it compare to type
: instanciation and parametric contraint checking?
It achieves guaranteed *late* binding of types, whereas generics/roles
are biased towards early binding (class composition time, usually at
"compile time").
To me "binding" implies prior existance. That is the type instanciation
takes place elsewhere and flows into a scope as a temporarily bound
variable. How do you intent to achieve demand driven on-the-fly type
instanciations? This seems to me a necessity for Perl6 where not all
type information is available at compile time.
: Something like unary operator does?
Don't follow that.
Well, I regard operator does as binary. It's LHS is the receiver of the
role given as the RHS. This composing into comes in two modes for
compile time and runtime. E.g.
class LHS does RHS {...} # binary does at compile time
$x does RHS; # runtime role attachment
does RHS;# unary form?
: The only thing I did was to replace the :: sigil with a subtype
: declaration.
It's the lack of a "my" that bothers me.
: Does subtype always go into global scope? I thought
: that it requires a *name to go into global and our to go to the
: innermost module---or was that package?
For unqualified packages/modules/classes the default up till now has
been to put them into *. But I think I'm going to change that. See below.
That is very wise. But I would make a distinction in defaulting to
my or our: the keyword declared things like class, sub, etc default
to our, while the sigiled variables default to my. The latter would
prevent data leakage and auto-vivification surprises:
sub a { $x = 'a' }
sub b { $x = 'b' }
sub x
{
rand() < 0.5 ?? a :: b;
say $x; # should print undef unless $x defined before &a
}
: I mean even non-declared
: auto-vivified vars go into the immediately surrounding scope,
: or am I horribly mistaken?
They are "our" by default, not "my". Just as subs are "our" by
default. And indeed, that is probably what package/module/class
names are going to default to as well.
I think that forcing our on variables that shall go to the outer
scope where sharing is intended is a good idea. There could even be
a compiler mode that doesn't actually produce bytecode but re-writes
the source with nested our declaration moved to there "proper" place.
The purpose of my and our declarations is to give the compiler
and the runtime environment about the declared variable. Our stores
that information at the innermost level of collaboration while my
stores it at the innermost scope. For auto-vivified vars no storing
is needed because they bear no specific meaning.
I was confused because I
thought of file-scoped "class Foo;" declarations as defaulting directly
to *. That's inaccurate. It's just that the "current package" at the
start of a file happens to be *, and so it doesn't matter if you
say "class Foo" or "our class Foo", because they mean the same thing
at that point. If you say "class Bar" within the scope of any other
package/module/class, though, it should default to "our class Bar".
So it might as well default to "our" everywhere. The upshot is that
if you want to declare a module that declares a bunch of global classes
inside it, you have to use *. That seems like good documentation anyway.
Only the first class or module declaration in a file defaults to *.
I think it defaults to the scope it is embedded into. Conceptually
a module is instanciated into the surrounding scope by a use statement.
The implementation might of course be optimised in loading the generic
code of the module ones and create a proxy and/or specific instanciations
of generics into the importing scope.
Hmm. Does that mean that the top-level program starts running in *
instead of in Main. Or maybe the * rule only works on .pm files?
I would keep files out of the picture. The canonical form of a
Perl6 program is the "concatination" of all sources with the
"package Foo; ... eof" replaced with "package Foo {...}".
In this line of thinking * is the outer shell of the Perl6 bubble
you are in. Immediately outside that bubble one typically finds
Parrot or Pugs, but it could be other forms of programatical
embedding.
: my ::TypeRef; # type variable?
No, that's what I've been trying to say. I haven't wanted ::T to be a type
variable by itself. It's a type literal that simply doesn't have to
have been declared yet, but we know that if it had been declared, we
could also call it bare "T". I want some other syntax for declaring
type variables that involves explicitly "mying" or "ouring" the type.
[Or at least I did want it. I change my mind below.]
So currently the above would be a syntax error. We don't want
::TypeRef to behave differently in
my ::T;
my ::T $foo;
They should either both declare ::T, or both refer to an existing
type literally named "T
RE: DBI v2 - The Plan and How You Can Help
Sam Vilain wrote: > Maxim Sloyko wrote: > >> But this is not the point. The point was that usage of some file with >> passwords by *DEFAULT* is not the way to go, IMHO. It raises more >> problems than it solves. > > > Can you give an example of such a problem that wasn't already there? > > Just to be clear, the file would only need to contain passwords if the > DBD requires them. > > Sam. > May be it is just me, but having a bunch of config files is not very > good. Config files should be for program, not for separate modules of > that program. They are hard to manage, when there are many of them. > Besides, DBI is a high level abstraction and it is not a good idea to > tie it to some file. May be it is better to let DBD:: modules choose? > For example, you can pass some parameter to the driver in connect > string, which tells it, where passwords are stored. Something like this > is impleneted in DBD::Oracle, where you can just pass 'sid' parameter to > the driver, the rest configuration parameters (except passwords and > usernames) are read from oracle config file, from the section to which > that sid parameter points. No, it is not just you. I find this type of setup appalling. As an Oracle DBA, I do not want yet another place where I will need to manage passwords. This type of setup will most likely restrict and possibly prohibit the use of Oracle OID and Enterprise User Management. It is, IMHO, unacceptable to force this type of behavior into a database access module and onto the general user community. > I don't mind if you implement this ".dbi" feature though, I just want it > to be invisible :) i.e. don't check this file, if I explicitly supply > username and password (this is obvious, right?) and show some warnings > if don't. Say, make a connect parameter "use_dot_dbi", which is zero by > default. > -- > Maxim Sloyko -- Ron Reidy Lead DBA Array BioPharma, Inc. This electronic message transmission is a PRIVATE communication which contains information which may be confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. Please notify the sender of the delivery error by replying to this message, or notify us by telephone (877-633-2436, ext. 0), and then delete it from your system.
RE: DBI v2 - The Plan and How You Can Help
When I go to the donation page and attempt to make a donation, the drop-down box does not give DBI as a valid recipient. Is it possible several people may not have donated as they noticed the same results, or maybe they did and it all went into the Perl Development Fund instead? > -Original Message- > From: Tim Bunce [mailto:[EMAIL PROTECTED] > Sent: Friday, July 01, 2005 7:06 PM > To: perl6-language@perl.org; dbi-users@perl.org > Subject: DBI v2 - The Plan and How You Can Help > > > Once upon a time I said: > > > http://groups-beta.google.com/group/perl.dbi.users/msg/caf189d > 7b404a003?dmode=source&hl=en > > and wrote > > http://search.cpan.org/~timb/DBI/Roadmap.pod > > which yielded: > > > https://donate.perlfoundation.org/index.pl?node=Fund+Drive+Det > ails&selfund=102 > > (A little over $500 of that I effectively put in myself.) > > My *sincere* thanks to all those who donated to the fund, especially > individuals. I had hoped for more corporate response with less from > individuals and I'm touched by the personal generosity shown. > > I've not drawn any money from it yet and doubt that I will myself. > (I'm considering suggesting that the Perl Foundation make payments > from the fund to people making specific contributions to the DBI. > I'm thinking especially of work on a comprehensive test harness. > But I'll see how the developments below pan out before making > specific arrangements.) > > > So, that lead to: > > > http://groups-beta.google.com/group/perl.dbi.dev/browse_frm/th > read/ef14a9fc0a37441f/fb8fe20a86723da0#fb8fe20a86723da0 > > Which sums up fairly well where I'm at: DBI v1 will rumble on > for Perl 5 > and DBI v2 will be implemented for Perl 6. > > > --- digression --- > > At this point I'd like to make a slight digression to highlight the > amazing work going on in the Perl 6 community at the moment. > Especially Autrijus' Pugs project which has brought Perl 6 to life. > Literally. Take a look at: > > http://pugscode.org/talks/yapc/slide1.html > http://use.perl.org/~autrijus/journal > > and especially: > > http://use.perl.org/~autrijus/journal/24898 > > Yes, that really is Perl 6 code using the DBI being executed by Pugs. > > That's great, and I was truly delighted to see it because it takes the > pressure off the need to get a DBI working for Perl 6 - because it > already is working for Perl 6. At least for Pugs. (The Ponie project > is also likely to provide access to Perl 5 DBI from Perl 6 by enabling > future versions of Perl 5 to run on Parrot.) > > --- digression --- > > > I have recently come to an arrangement that will enable me to put some > worthwhile development time into DBI (still very much part-time, but > enough to give it focus and move forward). > > My initial goals are: > > 1. to work on a more detailed specification for the DBI v2 API that > takes advantage of appropriate features of Perl 6. > > 2. to work on a more detailed specification for the DBDI API > > http://groups-beta.google.com/group/perl.perl6.internals/msg/c > fcbd9ca7ee6ab4 > > 3. to work on tools to automate building Parrot NCI interfaces to > libraries (such as database client libraries, obviously :) > > > But I'm hoping you'll join in and help out. > > I've kept an eye on Perl 6 and Parrot developments but I'm no > expert in > either. What I'd like *you* to do is make proposals (ideally fairly > detailed proposals, but vague ideas are okay) for what a Perl > 6 DBI API > should look like. > > Keep in mind that the role of the DBI is to provide a consistent > interface to databases at a fairly low level. To provide a > *foundation* > upon which higher level interfaces (such as Class::DBI, > Tangram, Alzabo > etc. in Perl 5) can be built. > > So, if you have an interest in the DBI and Perl 6, put your thinking > cap on, kick back and dream a little dream of how the DBI could be. > How to make best use of the new features in Perl 6 to make > life easier. > > Then jot down the details and email them to me (or to > dbi-users@perl.org > if you want to kick them around in public for a while first). > > I'm about to fly off for two weeks vacation (in a few hours), > blissfully > absent of any hi-tech gear beyond a mobile phone. When I get back I'll > gather up your emails and try to distill them into a coherent whole. > > Have fun! > > Tim. >
Re: DBI v2 - The Plan and How You Can Help
Sam Vilain wrote: Maxim Sloyko wrote: But this is not the point. The point was that usage of some file with passwords by *DEFAULT* is not the way to go, IMHO. It raises more problems than it solves. Can you give an example of such a problem that wasn't already there? Just to be clear, the file would only need to contain passwords if the DBD requires them. Sam. May be it is just me, but having a bunch of config files is not very good. Config files should be for program, not for separate modules of that program. They are hard to manage, when there are many of them. Besides, DBI is a high level abstraction and it is not a good idea to tie it to some file. May be it is better to let DBD:: modules choose? For example, you can pass some parameter to the driver in connect string, which tells it, where passwords are stored. Something like this is impleneted in DBD::Oracle, where you can just pass 'sid' parameter to the driver, the rest configuration parameters (except passwords and usernames) are read from oracle config file, from the section to which that sid parameter points. I don't mind if you implement this ".dbi" feature though, I just want it to be invisible :) i.e. don't check this file, if I explicitly supply username and password (this is obvious, right?) and show some warnings if don't. Say, make a connect parameter "use_dot_dbi", which is zero by default. -- Maxim Sloyko
Hackathon notes
During the Pugs Hackathon at YAPC::NA 2005, I managed to get various
unspecced tests and features reviewed by Larry, and posted them in my
journal. The original notes is attached; I'd be very grateful if you or
other p6l people can find tuits to work them back into the relevant
Synopses. :-)
Thanks,
/Autrijus/
* deref is now 0-level; $x = 3; $y = \$x; $y++. # now an exception
* coercion is now done in mmd level in coerce: calls.
sqrt("element") now yields to 0. `my Int $x = "foo" as Str` casts.
* `is lazy` parameters in MMD now causes the argument to be delayed
even if other MMD candates mandate them as eager; it enters MMD
not with the type of its evaluated result, but with its inferred
type at compile time.
* &prefix:<=> is just .shift in item context; in slurpy context
it just the iterator into a generator. All arrays are concatenations
of generators (which may or may not be preflattened)
* &slurp() is the eager variant of list context &prefix:<=>;
you can, alternately, use the steamroller &prefix:<**>.
* my() declarations scopes lexically to the rest of the block; using `$MY::x`
or `$::("x")` in the block before the actual declaration is erroneous.
* Only Roles take type parameters. Hence, `Array` and `Hash` and `Scalar` are
roles; PerlArray/PerlHash/PerlScalar are classes that conforms to them. A
variable is bound to containers of the Perl* types by default, depending on
its sigil.
* Non-source-filter-ish macros work on the PIL(AST) level, not on parse tree
level. The AST should preserve enough information to derive the original
parse tree and source code back, for the compiler to use.
* `return` inside blocks always throw out exception specific to its
containing Routine; if the caller chain does not include that routine,
it's just a fatal exception.
* while foo() -> $_ {...} # binds $_
while foo() -> ?$_ {...} # does not bind $_
* sub foo (?$x, ?$Inf) {}
my $y = (x => 3); foo($y); # binds $x
my $z = (+Inf => 3); foo($z); # binds $Inf
* The "Hash", "Int", "Str" etc are just roles:
role Hash[?::returns=Any, ?::shape=Str] {
}
implementation classes are known as "PerlHash", "PerlInt" etc.
* For pair/named binding to work, the inferencer needs to know it is a
pair before putting it in the named binding position.
sub foo ($x) { ... }
sub bar returns Pair () { (x => 3) }
my $y = (x => 3);
foo({ x => 3 }.()); # This assigns (x=>3) to $x
foo(bar()); # This assigns 3 to $x
foo($y);# This assigns 3 to $x, too
* `Parametric` type is now gone. `Bare` is merged with `Block` -- it's
all of the `Block` type now.
* Roles are also classes! They can be instantiated just fine if they are
concrete enough. Basically they mean /composable classes/ or /mixin-able
classes/. Hence, `RoleName.new()` instantiates an object that will probably
fail on methods declared as stubs.
* Class-defined methods with the same short name as their roles must conform to
the same signature as the role methods; otherwise a fatal exception occurs.
* Abstract pure methods in Roles really just return an Exception object,
exactly the same way as if the `...` is evaluated normally.
method foo () { ... }
* Perl 6 is defined with separate compilation in mind; each compilation unit is
going to pretend they are compiled in a different process. They are allowed
to bind names (exports) in other namespaces, but they cannot read anything
from others.
* `&chomp` and `&wrap` are now nondestructive; chomp returns the chomped part,
which can be defined by the filehandle that obtains the default string at the
first place. To get destructive behaviour, use the `.=` form.
* Filehandles opens chomped by default; you need to add the `:unchomped` flag
to turn off chumping.
my $fh = open 'file'; # autochomp
my $fh = open 'file', :newlines;# non-autochomp
$fh.newline = '\r'; # now split on \r
$str = $fh.readline;
$str.newline; # \r
for chomp =$fh { ... }
If .newline is a rule, then its captured variables are made available to the
calling block as if it has done a matching.
* The chained associativity level is associative with the precendence level it
is in; hence, in the same level all chainfix operators glue together the same
way the chained comparisons glue together. The listfix associativity always
accept one trailing operator, so `1 Y 2 Y 3 Y` is legal.
* Rules have their grammatical category, `&rule:`, that can reside in
either
grammars, non-grammar packages, or the true global namespace where they get
names like `&*rule:`. Inside grammars they are called
`&Foo::rule:`.
* Grammar is a specialized form of Role (which is a special form of Class,
which is a special form of Package). When a grammar `does` another grammar,
it mixes in the grammar's rules as package globals.
* To invoke an unqua
