Re: question about twigil ?
In article [EMAIL PROTECTED], herbert breunung [EMAIL PROTECTED] wrote: currently just used for compile time constants like $?LINE allright so far so good. but why not use that for all constants like my $?constant = 5; The $? is telling us where the value came from, not that it's a constant. Since it's a compile time value, it also happens to be something that we can't change.
Re: Perl 6 fundraising and related topics.
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: That's what made me come to the conclusion that it's really The Parrot Foundation. It's not The Parrot Foundation. It's that NLNet gave a very large targeted grant for Parrot. It's a single big donation that's driving that. I'm working on a detailed history of all TPF grants, but I want to get everything just right before I published it. You'll see that your comment is not really true.
Re: Perl 6 fundraising and related topics.
In article !!AAAYAJmSy7DjO29Fg/NooSGjnaXCgAAAEEc+mhI1TL9CiDgj [EMAIL PROTECTED], Conrad Schneiker [EMAIL PROTECTED] wrote: So over the next few months, I'm planning to learn about fundraising, and see what I can accomplish on behalf of Perl 6 development. To that end, I'm soliciting: It's not really a money problem. It's finding someone to give the money to. I've been trying to force money on some people to work on Perl 6, but they don't wants it, for whatever reason. Part of that is that TPF officers aren't supposed to get grant money. And, before you think about raising money, check how much money TPF actually has. There is still half of the NLNet's $70k to be distributed. for instance. It's not a fundraising problem. Find a person who would take money before you spend too much time finding the money. Targeted fundraising is more effective anyway :)
when(), smart matching, and
This is actually a bug from Perl 5, but Perl 5's given is supposed to
act like Perl 6's given. The long post is in use.perl:
http://use.perl.org/~brian_d_foy/journal/35682
I was playing with a when condition that used a logical operator to see
if the topic was both an element of an array and a key of a hash:
given( $foo ) {
when( @array %hash ) { ... }
}
I thought that should acting like two smart matches:
given( $foo ) {
when( (@array ~~ $_) (%hash ~~ $_) ) { ... }
}
In Perl 5.10.0, it's acting like one smart match, which I'm pretty sure
is a bug:
given( $foo ) {
when( ( scalar @array and scalar %hash ) ~~ $_) ) { ... }
}
Perl 5's perlsyn talks about smart matching with logical operators, but
I don't see that in S04 (or anywhere else). Knowing what is supposed to
happen in Perl 6 would help me fix the Perl 5.10 version.
So what would Perl 6 do (WWP6D) ? :)
Re: when(), smart matching, and
In article [EMAIL PROTECTED], Larry Wall
[EMAIL PROTECTED] wrote:
:given( $foo ) {
: when( ( scalar @array and scalar %hash ) ~~ $_) ) { ... }
: }
which is exactly what I would expect from Perl 5, unless when is
really a very intelligent macro of some sort. As far as I know
Perl 5's when has no clue how to distribute a smartmatch.
Well, I don't think you'd expect that based on perlsyn, so it looks
like the docs need to change to match what it does. I think the idea in
P5 is seriously borken.
To write what you want there, you'd need something like:
when any(@array) any(%hash.keys) {...}
It's not that I want that, but I'm trying to figure out what happens
with the logical operators based on the P5 docs. I'm starting from the
syntax rules and finding out what I can do with them rather than
starting with a task and looking for a way to do it. My interest is how
I'm going to answer questions in front of a bunch of students who use
the rules in unexpected ways.
So, this isn't a Perl 6 issue, and I'll relay to the P5 folks that they
aren't even close, have no hope of being close, and that they'll have
to figure it out on their own. :)
Re: Pair notation for number radix
In article [EMAIL PROTECTED], Smylers [EMAIL PROTECTED] wrote: brian d foy writes: In article [EMAIL PROTECTED], Larry Wall [EMAIL PROTECTED] wrote: On Tue, Dec 04, 2007 at 08:28:48AM -0800, brian d foy wrote: : In article [EMAIL PROTECTED], Larry Wall : [EMAIL PROTECTED] wrote: : : : Later in the Literals section of S02, there's a chart of the : : corresponding forms for fat arrow, pair, and paren notation. It has : : : :a = 'foo' :afoo :a(foo) You're confusing various levels here when you say same thing. They're the same in some ways and different in others. The colon can _also_ be used for forming adverbs (similarly to how the slash can be used for both regexes and division, in different places), but that doesn't effect the equivalence of the above. The section where that table is talks about adverbs. This isn't just the same characters being used for different things. Some pairs also act like adverbs. See my earlier message on file test operators.
Re: Pair notation for number radix
In article [EMAIL PROTECTED], Larry Wall [EMAIL PROTECTED] wrote: On Tue, Dec 04, 2007 at 08:28:48AM -0800, brian d foy wrote: : In article [EMAIL PROTECTED], Larry Wall : [EMAIL PROTECTED] wrote: : : : Later in the Literals section of S02, there's a chart of the : : corresponding forms for fat arrow, pair, and paren notation. It has : : : :a = 'foo' :afoo :a(foo) You're confusing various levels here when you say same thing. They're the same in some ways and different in others. Well, I think the documentation is confusing it. If these notations are not the same thing, should there be a table that shows the correspondence of these forms? If the pair notation shouldn't be used for adverbs, perhaps the documentation shouldn't note a generalized adverbial form of Pair notation. I guess I'll just leave it at that, though, and not bring it up again.
Re: perl 6 and web open source projects
[[ This message was both posted and mailed: see the To, Cc, and Newsgroups headers for details. ]] In article [EMAIL PROTECTED], cdumont [EMAIL PROTECTED] wrote: oh, it might not be relevant in many ways but : http://iamseb.com/seb/2007/12/perl-on-rails-why-the-bbc-fails-at-the-internet/ http://www.bbc.co.uk/blogs/radiolabs/2007/11/perl_on_rails.shtml There's one thing I would like perl6 to shine in, is web and open source. As Trey pointed out, this sort of discussion belongs somewhere else. Note that no language really shines on the web: it's something that someone makes with the language (e.g. Catalyst, Rails, Seaside, Django) that shines on the web :)
Re: Pair notation for number radix
In article [EMAIL PROTECTED], Larry Wall
[EMAIL PROTECTED] wrote:
: Later in the Literals section of S02, there's a chart of the
: corresponding forms for fat arrow, pair, and paren notation. It has
:
:a = 'foo' :afoo :a(foo)
:
: That looks like it might mean that these are corresponding forms:
:
:8 = 377:8377:8(377)
The first is just a pair of 8 and 377, and has no special numeric
significance. The adverbial syntax is special in that, for ordinary
pairs, what follows the colon must be an identifier, so :8377
would ordinarily be illegal.
Did I miss this in the spec somewhere? I've basically assked the same
question in regards to file tests. I wouldn't be asking the question if
the spec didn't keep talking about pairs and adverbs being the same
thing. If the Pair and adverbs aren't different syntax for the same
thing, how should that affect that chart in S02?
The :8(377) above is a bit wrong, by the way, and works only because
decimal 377 happens to stringify to something that looks like an
octal number. You couldn't, for instance, say :16(deadbeef) unless
deadbeef() was a 0-ary (or listop with no args) function returning
a hex string.
Could you have :16('deadbeef')? Should the :8(377) still work (so, does
'wrong' mean it won't do what I'm thinking it will do, or that it does
mean that Perl 6 won't compile it, or some other sort of wrong)?
Re: Some questions about using NaN and Inf
In article [EMAIL PROTECTED], TSa [EMAIL PROTECTED] wrote: The only operator that can be used to investigate these values should be ~~ and the given/when statement that uses it. Why should that be true? What's wrong with treating it as an object like anything else? The trick is limiting the number of special cases and exceptions to the rule so beginners can form the right conceptual model of everything.
Re: Some questions about using NaN and Inf
In article [EMAIL PROTECTED], Moritz Lenz [EMAIL PROTECTED] wrote: brian d foy wrote: * If I can match $x to NaN (or its stand-in), what happens when $x is undef? undef is a property of the container variable (that it holds no value), whereas NaN is a property of the content (like 1/0). so undef ~~ NaN should be false IMHO. That's fine, but the question people are going to ask is if undef isn't a number, why doesn't iot match 'not a number'. If it doesn't match, we have to talk about internals to explain it, which is generlaly not a good idea for beginners :)
Re: Some questions about using NaN and Inf
In article [EMAIL PROTECTED], Darren Duncan [EMAIL PROTECTED] wrote: At 3:20 PM -0500 10/6/07, brian d foy wrote: For comparisons, how are we going to use Inf and NaN? Are those going to be special flyweight objects, so: $x = 1 / 0; $x == Inf;# is it the same value $x === Inf; # it is always the same object them. By contrast, the =:= operator always tests if 2 things are the same object or not, even for those of value types. Maybe the belongs in Comparison types in S02 too :) So, then, back to the question. People don't care how it's implemented (and it would be great if we didn't have to explain it). What's the idiom for the comparison going to be?
Some questions about using NaN and Inf
I'm thinking about how to explain Perl 6's numbers to the beginners just picking up Learning Perl 6. I had some questions about NaN and Inf (which I can't just try since neither Parrot or Pugs appear to know about these yet). * In S02's table of Immutable types, it mentions that Int allows Inf and NaN, but doesn't say anything about Num and Complex handling them. Is it that it's unexpected that Int would handle it, so you have to say this explicitly, or um, I don't have a good alternative :) Int Perl integer (allows Inf/NaN, arbitrary precision, etc.) Num Perl number Complex Perl complex number The complex and num native type handles NaN accroding to Native type, a couple of subsections back, and I'm confident that Num and Complex should have them too. It just looked odd to me that only one of Int, Complex, and Num said anything about it. * will NaN, -Inf, or +Inf be literal values (or something close) so I can use them in comparisons? e.g. $x ~~ NaN. I see uses of Inf in list creation ( 1 .. Inf ), but can I use that everywhere? * If I can match $x to NaN (or its stand-in), what happens when $x is undef? There's a note about this in S02 (Conjecture: num might ...). Native type say that an int type defaults to 0, which complicates things for beginners, but if everything starts off as a num, it doesn't matter until we talk about types. * If I declare a sub to return a number of some sort (either by using Cof or Cas, what happens when the value is NaN or Inf? I suppose that should be fine as a return value, but it also seems that if someone wants to impose some sort of constaint on the return value that they wouldn't want exceptional values.
Re: Some questions about using NaN and Inf
In article [EMAIL PROTECTED], brian d foy [EMAIL PROTECTED] wrote: I'm thinking about how to explain Perl 6's numbers to the beginners just picking up Learning Perl 6. I had some questions about NaN and Inf (which I can't just try since neither Parrot or Pugs appear to know about these yet). Oi, sent that before I was done writing it. I was looking way back into the past at Numeric literals, take 1 http://www.nntp.perl.org/group/perl.perl6.documentation/2002/11/msg205.h tml and wondering how much of that is should be in S02. For comparisons, how are we going to use Inf and NaN? Are those going to be special flyweight objects, so: $x = 1 / 0; $x == Inf;# is it the same value $x === Inf; # it is always the same object
Pair notation for number radix
This is basically the same question I had about file test operators earlier (http://www.nntp.perl.org/group/perl.perl6.language/2007/04/msg27415.htm l). I never got an answer on my syntax question and the discussion went off to talk about file tests instead of pair notation. From S02 The general radix form of a number involves prefixing with the radix in adverbial form. This seems to say that there are non-general radix forms, and that those might involve a different radix form that's not adverbial. Later in the Literals section of S02, there's a chart of the corresponding forms for fat arrow, pair, and paren notation. It has a = 'foo' :afoo :a(foo) That looks like it might mean that these are corresponding forms: 8 = 377:8377:8(377) Now, if I can do that, what happens to the pair form in a hash composer when I want the key of '8' and the value of :10377? Also, going a bit further, the table lists a = foo bar :afoo bar :a(foo bar) So can I do things like 255 = 10 1 0 6; # hey, that looks like an IP address :25510 1 0 6; # is that the same as :255[ 10,1,0,6 ] ? And, if that works, what might this do? q:w:25510 1 0 6
Re: Micro-articles on Perl 6 Operators
In article [EMAIL PROTECTED], Alberto Simões [EMAIL PROTECTED] wrote: Adriano Ferreira wrote: The plan is to write a series of blog entries discussing a Perl 6 operator at a time or a small group of closely related ones. I think the idea is cool. Also, I do not know how periodically that would be, but it might be a good idea to join some of them in turns and ask brian d foy to publish them in TPR as well. Yes, I'd publish them. :) However, I don't want to publish something that's already on Perl.com.
Re: Referring to source code within Perldoc: the new A code
In article [EMAIL PROTECTED], Smylers [EMAIL PROTECTED] wrote: Juerd Waalboer writes: Smylers skribis 2007-06-21 21:33 (+0100): I disagree. perldoc.perl.org was started by JJ, gained popularity, and then got awarded the official blessing of the onion. Over the years there have many several sites with Perl documenation. That's not a way of documenting things, it's just an interface to existing documentation. There's no reason why it has to be. There are no barriers to anybody unofficially adding extra semantic information to the documentation and making it available on a website. The biggest barrier is that any work one does outside of the documentation source is likely to be wasted when new versions of the module comes out. Consider the Phalanx project for instance: they got a lot of people working to improve a lot of modules, and almost none of that work actually made it into the modules. The next biggest barrier is the size of the job. Who's going to go through all that documentation on CPAN and tag everything? I wouldn't even want to do it on all of my modules. There isn't a technical problem, but there is a huge social and pragmatic problem. It would be very nice if the documentation had a natural way to do this without extra-documentation clues from third parties.
Re: Referring to source code within Perldoc: the new A code
In article [EMAIL PROTECTED], Damian Conway [EMAIL PROTECTED] wrote: Mark Overmeer wrote: [...yet another honest and heartfelt plea for Pod 6 to be something entirely different from what it is currently designed to be.] The solution is simple, you know, Mark. Why not just write up your own alternate S26, redesigning Pod 6 the way you think it should work, and then publish your proposal for consideration here? Couldn't most of this be figured out by making Pod6 extensible (or whatever the right term is). Pod6 would be more of the syntax and basic operation, but other people could have custom directives that their Pod6 translators and formatters could then use. That is, not all of this has to be in the spec if the spec has a way to make it possible later. :) And, as far as writing a new S26, does this mean that this really isn't open to discussion? That is, if we want something different than you want we have to have competing specs and there won't be any compromise?
Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
In article [EMAIL PROTECTED], Chaddaï Fouché [EMAIL PROTECTED] wrote: The Learning Perl 6 argument seems equally contrived to me since anyway you don't need POD to understand programming in Perl and I never actually learned POD until I wanted to do a real module and document my little console utilities in Perl. That's exactly my argument. You didn't need to learn that because you weren't specifically doing anything with Pod. It doesn't even come up because it's something you have to affirmatively do, and it's not something that accidentally happens. And if some do it, hell, I seriously doubt that their program would be in the scope of the beginning of Learning Perl 6 !! You didn't put -+- there in previous versions, did you ? I'm not sure what you mean mean by - + -. Our current Learning Perl class starts off with a little Pod manipulation because we know that everyone (should!) has the perldoc along with their Perl. My actual experience trumps your serious doubt :) The other problem is that if somehow a braindead guy (where would he get the idea from, I never saw such a style) put his = in first column expecting a assignment he won't get it... Seriously ? Are you really allowing for such weirdness in introductory material to a Language course ? How is that braindead? It's perfectly fine, allowable, and intended that a Perl 5 programmer can break statements over more than one line. It's not weird at all. I've taught a lot of beginner Perl classes, and people do all sorts of things. So in my opinion, it would be fine to let slip that you can also create some kind of comment/doc by putting a = in the first column in the first chapter, and let the subject of POD for a later chapter. The problem is that once you bring something up, people want to know why you brought it up, and then they start playing with that point to see what you meant. All of a sudden, you're explaining a lot of stuff that doesn't get people any closer to completing a simple program. As I've said previously, the rule for Pod looks simple, but the rules for other things, such as strings, are now more complicated. However, Larry mentioned that the Pod extractor may do what it likes, but Perl shouldn't have to live with it's decisions about what is executable code and what isn't, so it may still work out.
Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
In article [EMAIL PROTECTED], Damian Conway [EMAIL PROTECTED] wrote: [writing publicly to head off any notions there's a personality problem here] brian wrote: I know you think it's easier to teach and explain, but that's because you came up with it. I hope I'm not that shallow. I didn't mean to imply anything about your character there, but that naturally as thinking beings we all understand much better than anyone else our own thoughts and architectures. It's not that your shallow, it's that you've visited the deepest trenches in the murky oceans and now have to figure out how to explain the wonderful creatures you saw to people who don't want to get wet. You're going to understand it much more because you've actually seen those creatures. :) There are other things to consider, and to me it looks like this design decision isn't based on what's easier for the Perl 6 programmer but what's easier for the implementors. I assure you that that is categorically *not* the case (as I'll discuss at length in a subsequent message). I wasn't trying to assign any ethical baggage to that remark, and said in an earlier message that it's a matter of philosophy about what different people value most. I still think it's a true statement though, and that the difference is an honest disagreement about how the world should be.
Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
In article [EMAIL PROTECTED], brian d foy [EMAIL PROTECTED] wrote: There are other things to consider, and to me it looks like this design decision isn't based on what's easier for the Perl 6 programmer but what's easier for the implementors. My comment here was offensive to Damian (and possibly others), and I apologize for that. I should have explicitly noted my context for this thought: some poor programmer sitting alone with no knowledge of how Perl 6 got to be how it is (that is, the audience for Learning Perl 6). I didn't mean to apply this to Damian or anyone else specifically, and that we all know each other makes my comment reasonably seem like I'm pointing at specific people for this remark. From this, Damian and I had a minor misunderstanding, and after a couple of private emails we've cleared it up and are still friends. :) I apologize for the inconvenience,
Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
In article [EMAIL PROTECTED], Damian Conway [EMAIL PROTECTED] wrote: [ First, I should note that whatever we end up with, that's the party line and that's what I teach, but before we end up there, I know from my years of experience teaching that certain sorts of questions are going to come up. I'm looking at this from the perspective of the student sitting in a class, not from the implementors perspective. ] brian wrote: As you know, one of the biggest complaints about Perl is that you have to have a lot of special rules knowledge to figure some things out. Whether that is true doesn't really matter: people still complain about it. In this case, it will actually be true. I don't think that's the case. I'm speaking at the programmer level, not the implementor level. For the guy in the trenches, this is a special case. This is more complexity for the guy typing code, even if it's easier syntactically for the guy writing the parser. This impacts Learning Perl 6 rather early because it's a rule that people need to know at the same time that we tell them that whitespace is insignificant. I'm pretty sure Learning Perl 6 won't say that. Well, it won't say that if it's not true, but until pretty recently it's been mostly true. The rule you have to teach under the Separation model is: Any line that starts with an = is Pod...and not part of your program. And that's something that now comes up very early in teaching the assignment operator. Whereas the rule you have to teach under the Integration model is: We don't teach any rule under this model, and it's been fine for over a decade :) When we do teach the current Pod, the simple rule is that Pod starts: * when Perl is expecting a new statement * there is a =something at the beginning of the line Which is considerably simpler than the long rule list you used to say the same thing (which seems a bit of FUD, honestly). So, if this is the case, how will a new Perl 6 user debug a program failure when part of their program mysteriously disappears because they just happened to have =begin at the beginning of a line? The same way they debug it when part of their program mysteriously disappears because they just happened to have # at the beginning of a line: Except, of course, the Pod mysteriously vanishing will be considerably easier to debug, because ALL lines starting with =begin vanish, whereas only some lines beginning with # do. That's not really the case. The # only affects one line, and a pound in a literal string doesn't start a comment. People grok single line comments very well. The start of a Pod comment now affects it's line and the ones following it. Also, doesn't this then limit Pod to Perl 6 (which I thought was not the goal)? I doubt other languages will want to deal with this situation. As Smylers so ably pointed out, enabling Pod to be parsed independently of the underlying language syntax actually makes it vastly easier to use Pod with other languages. Well, easy to use Pod with other languages until they try to use the assignment operator at the beginning of the line, or a = in a literal string at the beginning of a line. I know you think it's easier to teach and explain, but that's because you came up with it. The notion that a special character in a certain column means something was tough to explain to other people in FORTRAN too. There are other things to consider, and to me it looks like this design decision isn't based on what's easier for the Perl 6 programmer but what's easier for the implementors. It's not that I don't understand both sides, I just disagree about where the complexity should be.
Re: = at Start of Line ([svn:perl6-synopsis] r14421 - doc/trunk/design/syn)
In article [EMAIL PROTECTED], Smylers [EMAIL PROTECTED] wrote: brian d foy writes: In article [EMAIL PROTECTED], Damian Conway [EMAIL PROTECTED] wrote: No. It's Pod. *Any* line that begins with '=begin' always starts a Pod block. Always. As you know, one of the biggest complaints about Perl is that you have to have a lot of special rules knowledge to figure some things out. Indeed. What's much nicer is to be able to state that a given rule always applies. Well, now explain literal strings :) This isn't about one rule, it's about an ecosystem. The rules for Pod5 always applied too, so I don't see what we've gained here as far as the simplicity of rules (but let's not go round-and-round on that since we've both already explained our positions). Like Damian has just done here. This is a point where a lot of people will disagree, I suppose, and it's a fundamental sort of disagreeement where neither side will really be convinced otherwise. I don't think this is stubbornness either, but reflects what people value most. That is, nobody is really wrong, because we'd have to define some way to measure that, and we're really disagreeing on the yard stick. Putting aside this particular situation, the argument comes down to where does the water balloon pooch out? We haven't lost any complexity, it's just in different places. Maybe some places need less complexity and some places could stand a little more. Now, in this particular situation, Pod is much easier to extract, but literal strings now have extra baggage to consider. That's not what we're debating though. The real debate is whether you think moving the complexity around like that is worth it. Personally, extracting Pod from Perl 5 hasn't been a problem for me (and I do a lot of Pod work and write lots of custom Pod translators), so I don't think this re-distribution is worth it. I don't have to answer many questions about extracting Pod, and I don't see many normal people (meaning, not us) asking for easier ways to do this. I don't see a motivation, for the perspective of normal people, for this. When we through around terms like natural language, normal people matter. :) You and Damian have explained the other side very well. I understand it, and it's very easy for me to understand and even deal with. We just disagree on the consequences. I tend to think that people like us are here to do the hard work so other people don't have to think about this sort of stuff, so I don't mind putting the complexity in the the parser if it takes it out of the common program elements such as strings.
Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
In article [EMAIL PROTECTED], Damian Conway [EMAIL PROTECTED] wrote: No. It's Pod. *Any* line that begins with '=begin' always starts a Pod block. Always. As you know, one of the biggest complaints about Perl is that you have to have a lot of special rules knowledge to figure some things out. Whether that is true doesn't really matter: people still complain about it. In this case, it will actually be true. That a Perl 6 compiler might actually decide that in the middle of a statement it isn't a statement anymore but is Pod will cause some grief, not only in the here doc example you show, but in things such as: my $x =begin(); This impacts Learning Perl 6 rather early because it's a rule that people need to know at the same time that we tell them that whitespace is insignificant. That's not really true anymore because a newline followed by an = followed by begin is this special case, **no matter how it shows up in the program**. Now there's this extra footnote to explain this situation, and at the level of basic syntax, we have to explain a lot more. I realize that the motivation for this was to be able to scan a file and extract the pod without parsing the Perl, but when the consequences affect very basic language things, like where you put your whitespace and operators, then you create more of a mess than you solve. So, if this is the case, how will a new Perl 6 user debug a program failure when part of their program mysteriously disappears because they just happened to have =begin at the beginning of a line? And, is the tradeoff in language complexity worth the extra trouble? Also, doesn't this then limit Pod to Perl 6 (which I thought was not the goal)? I doubt other languages will want to deal with this situation.
Default filehandles, or topicalizing filehandles, or something
I was thinking about default filehandles yesterday. select() doesn't seem to be around except as an Unfiled function in S16. Then, as I was looking at .say( Hello World ); and $ERR.say( Hello standard error ); I figured this might work, and does. Topicalizing a filehandle kinda acts almost like a default filehandle: $_ = $*ERR; .say( Hello standard error ); But, of course, that won't work for say() used as a function: say Hello standard error ; Then, I thought I might assign to $*OUT, which doesn't work in pugs (and I might have missed the part of the spec that says these are read-only): my $saved_standard = $*OUT; $*OUT = $*ERR; # this is an error say This goes to stderr; # not until previous line works say $saved_standard: This goes to stdout; # just fine Is there going to be a Perl 6 feature for this?
Current file name used by $*ARGS filehandle
Is there going to be a Perl 6 equivalent to $ARGV (the current filename for the ARGV filehandle)? This is something I wanted to use in an example in the Learning Perl 6 filehandles chapter: http://www.learningperl6.com/Chapters/11.filehandles.html
Re: Current file name used by $*ARGS filehandle
In article [EMAIL PROTECTED], Larry Wall [EMAIL PROTECTED] wrote: On Tue, May 01, 2007 at 10:04:50AM -0500, brian d foy wrote: : Is there going to be a Perl 6 equivalent to $ARGV (the current filename : for the ARGV filehandle)? Hmm, well, we did away with unsigiled filehandles, and renamed @ARGV to @*ARGS, so $*ARGS is presumably the magical filehandle, which means it can't really serve as the filename at the same time. So assuming that any filehandle knows the name of its file (if available), it'd probably be available via a method like $ARGS.name or some such. $ARGS.name seems reasonable enough, and the method could be very handle for other things that use filehandles too. However, until it shows up in a synopsis, I'll assume you're just thinking aloud rather than making a decision. :)
What should file test operators return?
At the moment the file test operators that I expect to return true or
false do, but the true is the filename. I expected a boolean, for no
other reason than Perl 6 has them so it might as well use them. The
section on Smart Matching in S03 says that the ~~ doesn't have to
return a boolean, but aside from things liek :s, :M, and :A, what good
would it be not to? I'm happy to update S16 with whatever the answer
is. :)
Here's my code example that motivates this question. For a Llama6
exercise with file test operators, I wanted to create a little table:
for @files - $file {
printf %-70s %s %s %s\n,
$file,
$file ~~ :r,
$file ~~ :w,
$file ~~ :x;
}
I get the filename for each part:
foo foo foo
Which I wanted to work like this perl5 (not that I care if it's
different, I just have to explain it to reader)
#!/usr/bin/perl5
foreach ( glob( * ) )
{
printf %30s %s %s %s\n, $_, -r, -w, -x
}
With the Pugs 6.2.13 (r15868), only the ~~ form seems to work, but is
that going to be any different than the other two forms?
pugs ( Talks ~~ :r ).say
Talks
Bool::True
pugs ( Talks ~~ :d ).say
Talks
Bool::True
pugs Talks.TEST(:s).say
*** No such method in class Str: TEST
at interactive line 1, column 1-21
pugs Talks.:s
Internal error while running expression:
***
Unexpected :s
expecting ., \187, , =, operator name, qualified
identifier, variable name, ..., --, ++, i, array subscript,
hash subscript or code subscriptat interactive line 1, column 9
pugs Talks.:d
Internal error while running expression:
***
Unexpected \:
expecting ., \187, , =, operator name, qualified
identifier, variable name, ..., --, ++, i, array subscript,
hash subscript or code subscriptat interactive line 1, column 9
Re: Does =$*ARGS work?
In article [EMAIL PROTECTED], David Vergin [EMAIL PROTECTED] wrote: on 4/11/2007 10:29 AM brian d foy said the following: The $*ARGS variable shows up in this file, which looks like it's still maintained: http://svn.pugscode.org/pugs/docs/AES/S28draft.pod That's a typo (mine). It should be @*ARGS and refers to simple access to the command line arguments. (Fixed.) Shouldn't $*ARGS still show up as the P6 counterpart to ARGV? S*ARGS as the filehandle shows up in S04.
Re: What should file test operators return?
In article [EMAIL PROTECTED], Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: On Apr 12, 2007, at 14:52 , brian d foy wrote: At the moment the file test operators that I expect to return true or false do, but the true is the filename. I expected a boolean, for no other reason than Perl 6 has them so it might as well use them. This is documented somewhere already. Pugs does not implement the spec as documented, though. That's part of the problem: finding that somewhere, then makign the other somewhere's agree with it.
Re: What should file test operators return?
In article [EMAIL PROTECTED], Moritz Lenz [EMAIL PROTECTED] wrote: brian d foy wrote: At the moment the file test operators that I expect to return true or false do, but the true is the filename. that helps chaining of file test: $fn ~~ :t ~~ :x or something. That's fine, but the example in S16 shows that as a junction: $fh ~~ :t :x I don't mind the answer being whatever it is as long as it's really the answer that I can tell newbies and point to in the docs. :)
Re: What should file test operators return?
In article [EMAIL PROTECTED], Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: File tests are supposed to return something which: - behaves as a Bool - stringifies as a filename - numifies as a file size or as a time, if appropriate - propagates a stat object (obviating perl5's magic _) Current Pugs only does the first three, sort of: the size and time operators return numeric, the others string, all behave appropriately if used as booleans. I'm not sure Pugs does that right. The file named 0 (zero) seems to behave inappropriately. In this example, foo and 0 are real files, and not there is not a file that exists: pugs foo ~~ :e foo pugs true foo ~~ :e Bool::True pugs not there ~~ :e Bool::False pugs true not there ~~ :e Bool::False pugs 0 ~~ :e 0 pugs true 0 ~~ :e Bool::False Again, I don't really mind whatever the answer is as long as I can document it. :)
Re: What should file test operators return?
In article [EMAIL PROTECTED], Moritz Lenz [EMAIL PROTECTED] wrote: Hi, brian d foy wrote: At the moment the file test operators that I expect to return true or false do, but the true is the filename. that helps chaining of file test: $fn ~~ :t ~~ :x or something. I thought that returning a stat buffer was supposed to handle the case of chained file test operators. S16 will also need a fix-up for this text, I think: Also note that, for the superuser on the local filesystems, the :r, :R, :w, and :W tests always return 1,
Re: What should file test operators return?
In article [EMAIL PROTECTED], Larry Wall
[EMAIL PROTECTED] wrote:
On Thu, Apr 12, 2007 at 01:52:50PM -0500, brian d foy wrote:
: Here's my code example that motivates this question. For a Llama6
: exercise with file test operators, I wanted to create a little table:
:
:for @files - $file {
: printf %-70s %s %s %s\n,
: $file,
I think I would now write that more like:
for @files - $file {
given stat $file {
printf %-70s %s %s %s\n, $file, .:r, .:w, .:x;
}
}
Hmmm, that's a good little bit of code, as was Damian's use of the
hyper-operator. The trick is to figure how how much I can use in Llama
6 without scaring off the reader. :)
I'm actually starting at the back of the book so I know what I have to
put in the front of the book to get that far. In previous Llamas the
file tests operators came before stat, but maybe this answer is a good
end-of-chapter sorta thing.
I'll also have to think about using given {} merely as a topicalizer
too, I guess, although showing it next to an explicit assignment to $_.
:)
File test operators as Pairs
So far (eep!), the documentation talks about file test operators as working with pairs, which will be a weird thing to explain, I guess. I'm wondering if this matters to the mere user at all, and if we should even talk about them in terms of pairs. I don't want a different set of terms in the docs and Llama6. Even if the current Pugs is different than what the final answer will be, as long as I know the final answer I'll be fine. :) For a directory that exists, using the adverbial form or the fat arrow form work for true or false things: pugs 'doc' ~~ :d doc pugs doc ~~ d = 1 doc pugs doc ~~ d = 0 Bool::False The fat arrow doesn't seem to work as I expected with :s though. I figured that the value of the pair would be the thing to match the answer of the test. I expect these all to be expressions of the same goal (even if they return different things right now): pugs doc ~~ :s # just to show you where I am 136 pugs ( doc ~~ :s ) == 136 Bool::True pugs ( doc ~~ :s ) ~~ 136 Bool::True pugs doc ~~ s = 136 # perhaps accidentally fine 136 So, if I wanted to see if the file had a size of 93 bytes, I'd use 93 as the value of the pair, but that doesn't work. It just returns true again: pugs doc ~~ s = 93 # I want this to fail (return Bool:I:False) 136 Similarly, if that last form should work, I might want to do something similar with the file age tests. I want a file 5 days old (let's ignore fractional days right now): doc ~~ M = 5; Which then makes me think I'd want to do something a bit wacky to see if the modtime is greater than 5: doc ~~ M = any( 5 ..* ); But, if file tests aren't really meant to be like this and the user shouldn't ever think like this, do I call it a pair? That's the question I'll have to answer to the newbie reading LLama6, even though I personally am fine with the term. :)
Re: What should file test operators return?
In article [EMAIL PROTECTED], Mark J. Reed [EMAIL PROTECTED] wrote: I think I need to reread the docs. What's the colon in the method calls for? (That is, why is it $stat_obj.:r instead of just $stat_obj.r ?) I can't answer the why question, but the stuff in S02 might help you. Look for generalized adverbial form: http://feather.perl6.nl/syn/S02.html The file test is really an adverbial pair (and see the message about pairs that I just posted). Larry just updated S03 with some clarification on file tests. Look at the section on Changes to Perl 5 Operators http://feather.perl6.nl/syn/S03.html
Re: File test operators as Pairs
In article [EMAIL PROTECTED], Luke Palmer [EMAIL PROTECTED] wrote: However, now we have stat($file).size. That's sorta fine with me. That makes it even easier to explain to newbies, although I'd need method names for the other tests. However, junctive tests are a mighty attractive feature and I'd hate to lose those, whatever the syntax.
Does =$*ARGS work?
Randal and I are starting work on Learning Perl 6, and now
that I've completed a lot of other things, I can actually start
paying attention to Perl 6. Here's the first of my stupid, where
have you been for the past 2 years you moron questions. :)
I'm working on the chapter on I/O (Chapter 5 in the current Llama),
specifically reading from the command lines files.
Under the section The for Statement in S04, it says that the diamond
operator
while( ) { ... }
becomes in Perl 6
for =$*ARGS { ... }
In the Pugs I have (6.2.13 (r15868) on Intel darwin), =$*ARGS only
reads the lines from the first file in @ARGS. I don't see this idiom
used anywhere else in the tests or examples, either.
The $*ARGS variable shows up in this file, which looks like it's still
maintained:
http://svn.pugscode.org/pugs/docs/AES/S28draft.pod
but that points to another variable list that it says is more
complete, although it does not list $*ARGS:
http://svn.pugscode.org/pugs/docs/Perl6/Overview/Variable.pod
Is this something that's not yet implemented or just broken? Am I
missing some documentation about parts that aren't implemented yet?
I wrote a test to put into t/builtin/io (once I remember my password),
but since I haven't committed anything to pugs before, I want to ensure
it's not me being stupid. :)
Also, along with that, is there any counterpart to Perl 5's $ARGV? I
wanted to record the files =$*ARGS went through, but I didn't see a way
to discover that.
Re: Does =$*ARGS work?
In article [EMAIL PROTECTED], Moritz Lenz
[EMAIL PROTECTED] wrote:
Hi,
brian d foy wrote:
Under the section The for Statement in S04, it says that the diamond
operator
while( ) { ... }
becomes in Perl 6
for =$*ARGS { ... }
Some time ago I read that too, and wondered why that's not [EMAIL PROTECTED]
That
seems more reasonable, because the command line arguments are stored in
@*ARGS.
well, $*ARGS is a magical filehandle, not a list of files. If you could
use an array there, I think you'd have to allow any array, and that
would be weird.
