r25853 - docs/Perl6/Spec/S32-setting-library
Author: wayland Date: 2009-03-16 09:23:53 +0100 (Mon, 16 Mar 2009) New Revision: 25853 Modified: docs/Perl6/Spec/S32-setting-library/IO.pod Log: Fix typo for TimToady++ (I like the new changes :) ) Modified: docs/Perl6/Spec/S32-setting-library/IO.pod === --- docs/Perl6/Spec/S32-setting-library/IO.pod 2009-03-16 08:03:54 UTC (rev 25852) +++ docs/Perl6/Spec/S32-setting-library/IO.pod 2009-03-16 08:23:53 UTC (rev 25853) @@ -936,7 +936,7 @@ If the file handle came from a piped open, C will additionally return C (aliased to C<$!>) if one of the other system calls involved fails, or if the program exits with non-zero status. The exception object will contain any -pertinent informatoin. Closing a pipe +pertinent information. Closing a pipe also waits for the process executing on the pipe to complete, in case you want to look at the output of the pipe afterwards, and implicitly puts the exit status value into the C object if necessary.
r25854 - docs/Perl6/Spec/S32-setting-library
Author: wayland
Date: 2009-03-16 09:35:04 +0100 (Mon, 16 Mar 2009)
New Revision: 25854
Modified:
docs/Perl6/Spec/S32-setting-library/IO.pod
Log:
Removed IO::File::Windows, as it's no longer necessary, AFAIK.
Modified: docs/Perl6/Spec/S32-setting-library/IO.pod
===
--- docs/Perl6/Spec/S32-setting-library/IO.pod 2009-03-16 08:23:53 UTC (rev
25853)
+++ docs/Perl6/Spec/S32-setting-library/IO.pod 2009-03-16 08:35:04 UTC (rev
25854)
@@ -1060,18 +1060,6 @@
=back
-=head2 IO::File::Windows
-
-role IO::File::Windows does IO::File {
-method open(Bool :$BinaryMode) {...}
-}
-
-=item open()
-
-Takes the C option to open the file in binary mode.
-
-[XXX bogus, now under Unicode *all* systems must distinguish text from binary.]
-
=head1 Unfiled
=over 4
Re: a junction or not
On Mar 15, 12:57 pm, datawea...@gmail.com (Jon Lang) wrote: > The problem that Richard just identified is that Junctions don't fully > manage to hide themselves when it comes to their method calls. [...] > I'm thinking that maybe Junction shouldn't be a type. Instead, it > should be a "meta-type", in (very rough) analogy to the concept of the > meta-operator. In particular, Junction bears a certain resemblance to > the hyper-operator. A couple of months ago I started a thread "rfc: The values of a junction" where I suggested that a solution tot he problem was to add a "grep" meta-operator that would enable an operator-based collapse of junctions. My suggested syntax from that thread was: my @values = 0..21 |==| $junc_value; Or my @values = Int |==| $junc_value; The idea was to match the range against the (possibly) junctional value, but return the set of matching values rather than just a True/ False comparison (Any binary operator that returns something boolean- like would be usable in the || meta chars. Given changes to meta- ops since then, perhaps my @values = 0..21 G== $junc_value would be more consistent. The advantage of using an operator over the existing "grep" method is that it could reasonable be expected to handle infinite ranges (and infinite junctions) analytically (in finite time). The advantage of using the operator over the "eigenstates" method is that it doesn't assume any knowledge pf the nature of the junction: "all", "any", "one", "none" -- the operator would do the right thing without any additional user-introspection.
Re: a junction or not
Sigh. The current design of Junctions is quite extensible *because* it is based on a real type. You can easily write operators that work only on Junctions, just as you can easily write operators that are transparent to Junctions or autothread on Junctions by declaring their arguments to take Object or Any, respectively. That being said, the reason Junctions are there in Perl 6 is primarily *linguistic* rather than mathematical; Perl 6 has a Set type because we've had this argument already. Anyone who extends Junctions to try to do some kind of set theory is on the road to Perdition, or at least the road to Brain Pretzels Without End, amen. In my opinion. :-) Larry
Roles driven by events
Having a problem with the following role in Perl 5:
package PIPs::ResultSource::Role::HasTags;
use Moose::Role;
requires 'do_setup';
after 'do_setup' => sub { ... };
So far this has worked really well, aside from that one class which didn't call
'do_setup'. Oops.
Requiring methods and requiring methods to be called are different things. It
might be a nice feature to have roles which tie into "events". If a particular
condition doesn't hold true by, say, INIT time, the role fails.
How would I implement something like that in Perl 6? Or am I just looking at
this wrong?
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: a junction or not
Larry Wall wrote: > Sigh. The current design of Junctions is quite extensible *because* > it is based on a real type. You can easily write operators that > work only on Junctions, just as you can easily write operators that > are transparent to Junctions or autothread on Junctions by declaring > their arguments to take Object or Any, respectively. Right; that was the solution to which I was referring. > That being said, the reason Junctions are there in Perl 6 is primarily > *linguistic* rather than mathematical; Perl 6 has a Set type because > we've had this argument already. Anyone who extends Junctions to > try to do some kind of set theory is on the road to Perdition, or at > least the road to Brain Pretzels Without End, amen. Agreed. My own concern has nothing to do with set theory; it's in making sure that there's an easy way to distinguish between method calls that are supposed to be fielded by the Junction itself (e.g., "give me perl for the Junction") and method calls that are supposed to be fielded by the Junction's eigenstates (e.g., "give me a Junction of perls for the eigenstates of this Junction") - bearing in mind that the Junction _does_ try to stay out of the way and pretend to be (a superposition of) its individual eigenstates as much as possible. _That's_ why I suggested pushing its methods into HOW: not to make it "not a type", but rather to ensure that its method calls will never clobber (or be clobbered by) the method calls of its eigenstates. This allows the programmer to continue to think of "1 | 2" as "an item, although I'm not sure which one" most of the time, and only as "a Junction" when it is convenient to do so (i.e., by making his intent explicit). The business of referring to it as a "meta-type" was perhaps an unfortunate digression from my main point; but I mentioned it to justify why I would feel comfortable with allowing Junction to put things in HOW: not only the practical reason that you wouldn't need to present _another_ HOW-like collection of methods to keep the Junction's stuff out of the way, but also because Junction _is_ a strange creature in that it's a collection of items that can usually be treated as a single (indeterminate) item - and this would highlight this fact to the programmer, perhaps making the task of understanding the Junction easier by providing an analogy to another language feature that has similar properties (i.e., meta-operators). Admittedly though, this latter reason takes a back seat to the practicalities. Bottom line, the goal is to keep Junction's methods from conflicting with its members' methods. -- Jonathan "Dataweaver" Lang
Re: Roles driven by events
Ovid wrote: > Requiring methods and requiring methods to be called are different things. > It might be a nice feature to have roles which tie into "events". If a > particular condition doesn't hold true by, say, INIT time, the role fails. > > How would I implement something like that in Perl 6? Or am I just looking at > this wrong? AFAICT, event-driven programming hasn't been incorporated into Perl 6 yet. S17 has mention of an event loop, and S12 speculates on a WHEN introspective method that would have something to do with events. -- Jonathan "Dataweaver" Lang
Re: Roles driven by events
Ovid wrote:
Having a problem with the following role in Perl 5:
package PIPs::ResultSource::Role::HasTags;
use Moose::Role;
requires 'do_setup';
after 'do_setup' => sub { ... };
So far this has worked really well, aside from that one class which didn't call
'do_setup'. Oops.
Requiring methods and requiring methods to be called are different things. It might be a
nice feature to have roles which tie into "events". If a particular condition
doesn't hold true by, say, INIT time, the role fails.
How would I implement something like that in Perl 6? Or am I just looking at
this wrong?
Well, if class composition time is OK and you want to decide whether the
role composes or not, then you can always write a where block in a
parametric role. Example from Rakudo (excuse the crap error message):
> role MaybeComposes[$x where { $*thingy == 42 }] { }
> class Foo does MaybeComposes['worreva'] { }
Use of uninitialized value
No applicable candidates found to dispatch to for '_block20'
> $*thingy = 42;
> class Bar does MaybeComposes['worreva'] { }
>
Just relies on normal dispatch-y stuff when picking the role. Means you
gotta pass a parameter of course... Note you can also provide a
fall-back role to compose by having one differently constrained. ;-)
I kinda wonder that since I believe roles are all implicitly are
parametrized on $?CLASS (didn't quite get to making that so yet in
Rakudo...or clear in S14 ;-)) if you would write:
role Foo[$?CLASS where { $*thingy == 42 }: ] { }
Note the :. You are just taking the invocant into $?CLASS as normal
(though it may get it anyway), but then adding a constraint on that.
Hmm...neater maybe. And if $?CLASS always gets the invocant anyway, like
self in methods, regardless of if you stick if somewhere else too, then
maybe even:
role Foo[$ where { $*thingy == 42 }: ] { }
Is permissible (but STD.pm doesn't like any of this role signature
invocant stuff at the moment).
Jonathan
Signature notes and questions
OK: as I see it, this is how signatures work:
There are three broad use-cases for signatures: function parameters
(S06), role parameters (S14), and variable declarators (S03).
Question: Do binding operators (S03) count as a fourth use?
There are two broad styles of signatures: those that want an invocant,
and those that don't. The former includes methods, submethods, and
roles; the latter includes subroutines, regexes, tokens, rules,
macros, and variable declarators. Signatures that want an invocant
will implicitly add one if none is explicitly specified; signatures
that don't want one will complain if you specify one.
Signature literal syntax: usually, this involves enclosing the
signature between ':(' and ')'. In variable and function declarators,
you may omit the leading colon; in a pointy-block signature, you must
omit both the colon and the parentheses. In a role declarator, you
must use square braces instead. (Questions: why is the pointy-block
exclusion of the enclosing delimiters mandatory? Why do role
declarators use different enclosing delimiters?)
Variable declarators have no use for longname parameters. Function
and role declarators do. (Question: are optional and/or slurpy
parameters excluded from the longname?)
Can attributive parameters be used in methods, or are they exclusive
to submethods?
---
Questions and issues pertaining to absent signatures:
All functions have a default signature of :(*%_, *...@_). Note that
methods and submethods will implicitly prepend :($?CLASS $self:) to
this. All roles are parameterized, and have a default signature of
:(Any $?CLASS:). Variable declarators have no default signatures.
(Question: is it still appropriate to use the '$?' twigil?)
Placeholder variables can be used within bare blocks (but not pointy
blocks) and methods that lack signatures. Can they be used in any
other function declarators? If not, why not? If so, are they
considered to be part of the longname of a named function?
(Doubtful.) They can't be used in variable declarators for several
reasons, not the least of which is that a variable declarator will
always have an explicit signature. But can they be used in roles?
Can you have a placeholder variable for a type parameter?
--
Jonathan "Dataweaver" Lang
Re: a junction or not
This is basically a non-problem. Junctions have one public method, .eigenstates, which is vanishingly unlikely to be used by accident by any mere mortal any time in the next 100 years, give or take a year. If someone does happen to be programming quantum mechanics in Perl 6, they're probably smart enough to work around the presence of a reserved--well, it's not even a reserved word-- a reserved method name. If it would make people happier, I suppose we could change it to something like .EIGENSTATES instead. Larry
Re: a junction or not
Larry Wall wrote: > This is basically a non-problem. Junctions have one public method, > .eigenstates, which is vanishingly unlikely to be used by accident by > any mere mortal any time in the next 100 years, give or take a year. > If someone does happen to be programming quantum mechanics in Perl 6, > they're probably smart enough to work around the presence of a > reserved--well, it's not even a reserved word-- a reserved method name. Actually, the problem isn't with '.eigenstates'; the problem is with '.perl'. If I'm viewing a Junction of items as a single indeterminate item, I'd expect $J.perl to return a Junction of the items' perl by default. Admittedly though, even that isn't much of an issue, seeing as how you _can_ get that result by saying something to the effect of "Junction of $J.eigenstates.«perl" - the only tricky part being how to decide which kind of junction to use (e.g., any, all, one, none) when putting the perl-ized eigenstates back together. (And how _would_ you do that?) This would represent another corner-case where the programmer would be tripped up by a simplistic understanding of what a Junction is; but being a corner-case, that's probably acceptable. -- Jonathan "Dataweaver" Lang
Re: a junction or not
Jon Lang wrote: Larry Wall wrote: This is basically a non-problem. Junctions have one public method, .eigenstates, which is vanishingly unlikely to be used by accident by any mere mortal any time in the next 100 years, give or take a year. If someone does happen to be programming quantum mechanics in Perl 6, they're probably smart enough to work around the presence of a reserved--well, it's not even a reserved word-- a reserved method name. Actually, the problem isn't with '.eigenstates'; the problem is with '.perl'. If I'm viewing a Junction of items as a single indeterminate item, I'd expect $J.perl to return a Junction of the items' perl by default. Admittedly though, even that isn't much of an issue, seeing as how you _can_ get that result by saying something to the effect of "Junction of $J.eigenstates.«perl" - the only tricky part being how to decide which kind of junction to use (e.g., any, all, one, none) when putting the perl-ized eigenstates back together. (And how _would_ you do that?) This would represent another corner-case where the programmer would be tripped up by a simplistic understanding of what a Junction is; but being a corner-case, that's probably acceptable. I would assume that invoking .perl on a Junction would result in Perl code consisting of the appropriate any/all/etc expression. -- Darren Duncan
Re: a junction or not
Darren Duncan wrote: > Jon Lang wrote: >> Larry Wall wrote: >>> This is basically a non-problem. Junctions have one public method, >>> .eigenstates, which is vanishingly unlikely to be used by accident by >>> any mere mortal any time in the next 100 years, give or take a year. >>> If someone does happen to be programming quantum mechanics in Perl 6, >>> they're probably smart enough to work around the presence of a >>> reserved--well, it's not even a reserved word-- a reserved method name. >> >> Actually, the problem isn't with '.eigenstates'; the problem is with >> '.perl'. If I'm viewing a Junction of items as a single indeterminate >> item, I'd expect $J.perl to return a Junction of the items' perl by >> default. Admittedly though, even that isn't much of an issue, seeing >> as how you _can_ get that result by saying something to the effect of >> "Junction of $J.eigenstates.«perl" - the only tricky part being how to >> decide which kind of junction to use (e.g., any, all, one, none) when >> putting the perl-ized eigenstates back together. (And how _would_ you >> do that?) This would represent another corner-case where the >> programmer would be tripped up by a simplistic understanding of what a >> Junction is; but being a corner-case, that's probably acceptable. > > I would assume that invoking .perl on a Junction would result in Perl code > consisting of the appropriate any/all/etc expression. -- Darren Duncan Tough to parse, though; and feels like a kludge. I expect better of Perl 6. -- Jonathan "Dataweaver" Lang
Re: a junction or not
On Mon, Mar 16, 2009 at 09:24:58PM -0700, Jon Lang wrote: : Darren Duncan wrote: : > Jon Lang wrote: : >> Larry Wall wrote: : >>> This is basically a non-problem. Junctions have one public method, : >>> .eigenstates, which is vanishingly unlikely to be used by accident by : >>> any mere mortal any time in the next 100 years, give or take a year. : >>> If someone does happen to be programming quantum mechanics in Perl 6, : >>> they're probably smart enough to work around the presence of a : >>> reserved--well, it's not even a reserved word-- a reserved method name. : >> : >> Actually, the problem isn't with '.eigenstates'; the problem is with : >> '.perl'. If I'm viewing a Junction of items as a single indeterminate : >> item, I'd expect $J.perl to return a Junction of the items' perl by : >> default. Admittedly though, even that isn't much of an issue, seeing : >> as how you _can_ get that result by saying something to the effect of : >> "Junction of $J.eigenstates.«perl" - the only tricky part being how to : >> decide which kind of junction to use (e.g., any, all, one, none) when : >> putting the perl-ized eigenstates back together. (And how _would_ you : >> do that?) This would represent another corner-case where the : >> programmer would be tripped up by a simplistic understanding of what a : >> Junction is; but being a corner-case, that's probably acceptable. : > : > I would assume that invoking .perl on a Junction would result in Perl code : > consisting of the appropriate any/all/etc expression. -- Darren Duncan : : Tough to parse, though; and feels like a kludge. I expect better of Perl 6. I think I've mentioned before that .perl autothreads. It's the final (low-level) stringification of a junction that slaps the appropriate quantifier around that, I suspect. So maybe $j.Str returns the eigenstring, while prefix:<~> autothreads. Or maybe there's a method named .eigenstring or some such for use by print and say and anyone else who absolutely must end up with something printable. Larry
Re: a junction or not
Larry Wall wrote: > I think I've mentioned before that .perl autothreads. It's the final > (low-level) stringification of a junction that slaps the appropriate > quantifier around that, I suspect. Please bear with me; I'm starting to get a little lost: are you telling me that $j.perl does what I'd expect of an indeterminate item, and that the trick is in getting a perlization of the Junction itself? If so, cool. > So maybe $j.Str returns the > eigenstring, while prefix:<~> autothreads. Or maybe there's a method > named .eigenstring or some such for use by print and say and anyone > else who absolutely must end up with something printable. Or maybe there's a method that returns a "frozen reference" that masquerades as the Junction, but doesn't trigger autothreading. Or would that be opening up an infinitely regressing can of worms? I don't know; I've got this gut feeling that something's off here, but I can't quite put my finger on what it is. Although, maybe I can. As written (I believe), .perl generates a String representation of whatever code is needed to build the object that called it. However, there may come a point somewhere down the road where you'll want .perl to instead return a parse-tree of that code, with the ability to stringify appropriately. If you've written a separate .eigenstring function to perform the same purpose with Junctions, or you've set it up so that prefix:<~> autothreads while Junction.Str returns the eigenstring, that will potentially be two functions that will need to be rewritten. More generally, a programmer who writes a function that operates on an Object (and thus autothreads when given a Junction) will be forced to decide between writing a second Junction-aware version if he wants to treat the Junction as a Junction instead of autothreaded Objects, or not bothering and thus not allowing the function to manipulate a Junction directly. In short, you have to reinvent the wheel every time the "to Junction or not to Junction" question arises. Providing a means to momentarily disable a Junction's autothreading properties would, in one fell swoop, solve every instance of this problem. At least, I think it would. If it wouldn't, it would at least solve a large swath of them. -- Jonathan "Dataweaver" Lang
Re: a junction or not
Jon Lang wrote:
Darren Duncan wrote:
Jon Lang wrote:
Larry Wall wrote:
This is basically a non-problem. Junctions have one public method,
.eigenstates, which is vanishingly unlikely to be used by accident by
any mere mortal any time in the next 100 years, give or take a year.
If someone does happen to be programming quantum mechanics in Perl 6,
they're probably smart enough to work around the presence of a
reserved--well, it's not even a reserved word-- a reserved method name.
Actually, the problem isn't with '.eigenstates'; the problem is with
'.perl'. If I'm viewing a Junction of items as a single indeterminate
item, I'd expect $J.perl to return a Junction of the items' perl by
default. Admittedly though, even that isn't much of an issue, seeing
as how you _can_ get that result by saying something to the effect of
"Junction of $J.eigenstates.«perl" - the only tricky part being how to
decide which kind of junction to use (e.g., any, all, one, none) when
putting the perl-ized eigenstates back together. (And how _would_ you
do that?) This would represent another corner-case where the
programmer would be tripped up by a simplistic understanding of what a
Junction is; but being a corner-case, that's probably acceptable.
I would assume that invoking .perl on a Junction would result in Perl code
consisting of the appropriate any/all/etc expression. -- Darren Duncan
Tough to parse, though; and feels like a kludge. I expect better of Perl 6.
What do you mean by "tough to parse" and "feels like a kludge"? Isn't the point
of .perl that it results in a string of Perl 6 code that is a Perl 6 value
expression? I wouldn't expect that a Perl 6 expression to result in a Junction
is any more difficult to parse than the source code returning an Array or some such.
For example, if you have:
my $choice = any(1..10);
Then "$choice.perl" should result in code like "any(1..10)". Or "$choice.perl"
would approximately be short for the expression:
'any('~($choice.eigenstates.map:{ $_.perl }.join(','))~')'
... except that the .perl of $choice would also be smart enough to pick
'any'/'all'/etc based on what its Junction value actually is.
Such as that seems perfectly elegant and uncomplicated to me.
If you had a problem with that, then I would expect you'd have a problem with
.perl in general for any value, particularly Array etc values.
-- Darren Duncan
