Re: embedding languages in Perl 6
On Wed, 20 Apr 2005, [ISO-8859-2] BÁRTHÁZI András wrote: I'm just wondering, if the following would be possible with Perl 6 or not? XML $a=elemselemContent #1/elemelemContent #2/elem/elems; [snip] The ideas coming from Comega, the next version of CSharp(?). Here's an intro about it: Some time ago I asked a somewhat related question that you can find under the subject Markup language-like features in Perl6?. It didn't raise much feedback, though. And I should have expanded on the subject, but never found the time to do so. Michele -- I agree with Tore; it's sort of a Zen question. If you have to ask, it means you won't understand the answer. If you know enough to understand the answer, you won't need the question. - Joe Smith in clpmisc, Re: Perl neq Python
-X's auto-(un)quoting?
Are the -X functions still going to be there? I definitely hope so! However, to come to the actual question, it has happened to me to have to do, in perl5 that is: perl -lne 's/^//;s/$//;print if -e' or (less often) perl -lne '$o=$_;s/^//;s/$//;print $o if -e' Ok: no much harm done (to my fingertips). But then, talking about huffmanization, could a standard adverb be provided for -X's to the effect of specifying that the passed filename is quoted, say in double (or if sensible in single) quotes: for I find that to be a common filelist format. Ideally, what I'd like to do is perl -lne 'print if -e :q' Michele -- Mary had a little lamb;/Its fleece was green as limes. And every even number greater than two/Is the sum of two primes. - Robert Israel in sci.math, Re: all math problems reduce to linguistics
[pugs]weird thing with say ++$
It has been published at perl6.language, but have no reply. In perl v5.8.6 built for MSWin32-x86-multi-thread: my $i = 1; print $i++, ++$i; # 1 3 my $i = 1; print ++$i, $i++; # 3 2 in pugs: my $i = 1; say $i++, ++$i; # 1 3 my $i = 1; say ++$i, $i++; # 2 2 which is right?(I think perl5 is) or it's different between Perl5 and Perl6? thanks. /Fayland Lam/ -- http://www.fayland.org
Re: Unify cwd() [was: Re: $*CWD instead of chdir() and cwd()]
Chip Salzenberg [EMAIL PROTECTED] writes: According to Michael G Schwern: In the same way that we have open() not fopen, fdopen, freopen... we can choose the safest and most sensible technique for determining the cwd and use that. And there is more than one open. Perl does have fopen/fdopen/freopen, but they're accessed through other techniques besides the name of the operator. For example, Perl spells Cfh = fdopen(5, r) as Copen $fh, =5). The unique technique is there, just pushed out of the operator name and into its parameters. And then there's sysopen(). This is exactly the point (I think) Schwern is trying to make. There is 'open', that will do most of the time. If a novice user asks how to open a file, you can say Well, just 'open $fh, $file'. If you want more than vanilla file access, there are all the other forms of open and open parameters. From the perspective of 'current directory' there should also be a simple and elegant way that will do in most cases. Advanced tricks can be made possible using separate modules and such. Maybe the basic problem is that 'current directory' is a system dependent file system location that is not a fixed string, although it usually can be represented as a string. Similar to a simple 'open', I think the most common use of 'cwd' (or whatever) is to return a file system location that can be returned to later, much in the sense of 'tell' and 'seek'. I think this can be implemented in a quite fail safe way on most platforms. -- Johan
Re: [perl #35053] [PATCH] classes/float.pmc: void function can't return a value
Andy Dougherty [EMAIL PROTECTED] wrote: In classes/float.pmc, the MMD_DEFAULT branch of i_subtract tries to return a value, even though the function is defined as 'void'. Thanks, applied. leo
Re: [pugs]weird thing with say ++$
On Thu, Apr 21, 2005 at 04:32:41PM +0800, fayland wrote: It has been published at perl6.language, but have no reply. In perl v5.8.6 built for MSWin32-x86-multi-thread: my $i = 1; print $i++, ++$i; # 1 3 my $i = 1; print ++$i, $i++; # 3 2 in pugs: my $i = 1; say $i++, ++$i; # 1 3 my $i = 1; say ++$i, $i++; # 2 2 which is right?(I think perl5 is) or it's different between Perl5 and Perl6? I think I understand the implementation details leading to each behaviour, but rather than saying which was right, I think I'd be quite happy to see Perl6 copy (the ideas behind) C's rules regarding sequence points and undefined behaviour. I'm not so sure about implementation defined and unspecified behaviour. When I see code such as this, I usually encourage people to program Perl as if it had sequence points and undefined behaviour. This often results in explaining what they are, but maybe that's not such a great problem. See http://www.eskimo.com/~scs/C-faq/faq.html, especially sections 3.8 and 11.33 for details. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
default values for attributive parameters
Are default values supported for attributive parameters in an argument list?
I wish to convert these 2 subroutines to perl6:
sub foo {
my $self = shift;
$self-{foo} = defined $_[0] ? shift : undef;
}
sub bar {
my $self = shift;
$self-{bar} = defined $_[0] ? shift : $DEFAULT;
}
Is this correct?
method foo (?$.foo = undef) {};
method bar (?$.bar = $DEFAULT) {};
Thanks,
Carl
Re: default values for attributive parameters
Carl Franks skribis 2005-04-21 11:29 (+0100):
I wish to convert these 2 subroutines to perl6:
sub foo {
my $self = shift;
$self-{foo} = defined $_[0] ? shift : undef;
}
sub bar {
my $self = shift;
$self-{bar} = defined $_[0] ? shift : $DEFAULT;
}
Is this correct?
Those are weird methods. They're essentially write-only accessor methods
for their respective internal attributes (in perl 5 called properties).
method foo (?$.foo = undef) {};
method bar (?$.bar = $DEFAULT) {};
The fun thing is that
has $.foo;
has $.bar;
already gives you, for free and imlicitly, two lvalue accessor methods
that can be used for both reading and writing the value. You appear to
want a default that is used at set-time, which I find weird. More common
I think would be to provide a default that is used at the time of object
construction.
has $.foo;
has $.bar = $DEFAULT;
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Unify cwd() [was: Re: $*CWD instead of chdir() and cwd()]
Johan Vromans skribis 2005-04-21 8:22 (+0200): This is exactly the point (I think) Schwern is trying to make. There is 'open', that will do most of the time. If a novice user asks how to open a file, you can say Well, just 'open $fh, $file'. If you want more than vanilla file access, there are all the other forms of open and open parameters. Just for the record, that's spelled $fh = open $file in Perl 6. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: [pugs]weird thing with say ++$
Paul Johnson [EMAIL PROTECTED] writes: I think I understand the implementation details leading to each behaviour, but rather than saying which was right, I think I'd be quite happy to see Perl6 copy (the ideas behind) C's rules regarding sequence points and undefined behaviour. I'm not so sure about implementation defined and unspecified behaviour. Isn't this the old prefix-++ problem: @a = (++$i,++$i,++$i); print @a;# prints 3 3 3 -- Johan
Re: Test.pm t/force_todo refactoring idea
On Wed, Apr 20, 2005 at 11:30:09PM -0400, Stevan Little wrote: It would also allow for code like this: force_todo(1, 5, 10 .. 15, 25); Which (IMHO) is nicer than having to do this in the t/force_todo file: t/my_test.t 1 5 10 11 12 13 14 15 25 I also think that having the forced-TODOs listed in the test file itself will make it easier to remember to un-force-TODO. However this is a very large change, and so I wanted to run it by the group before I even started. Please let me know your thoughts. I really like that idea. It puts the TODO list closer to the tests, similar to the benefit of having documentation close to the code it describes. Go Stevan! -kolibrie
Re: [pugs]weird thing with say ++$
On Thu, Apr 21, 2005 at 11:45:27AM +0200, Paul Johnson wrote: On Thu, Apr 21, 2005 at 04:32:41PM +0800, fayland wrote: It has been published at perl6.language, but have no reply. In perl v5.8.6 built for MSWin32-x86-multi-thread: my $i = 1; print $i++, ++$i; # 1 3 my $i = 1; print ++$i, $i++; # 3 2 in pugs: my $i = 1; say $i++, ++$i; # 1 3 my $i = 1; say ++$i, $i++; # 2 2 which is right?(I think perl5 is) or it's different between Perl5 and Perl6? I think I understand the implementation details leading to each behaviour, but rather than saying which was right, I think I'd be quite happy to see Perl6 copy (the ideas behind) C's rules regarding sequence points and undefined behaviour. I'm not so sure about implementation defined and unspecified behaviour. It certainly makes more sense to me that the answer would be 2 2. But however it ends up, so long as we know what the answer will be, we can utilize it effectively in our programs. -kolibrie
Re: [pugs]weird thing with say ++$
On Thu, Apr 21, 2005 at 11:45:27AM +0200, Paul Johnson wrote: It certainly makes more sense to me that the answer would be 2 2. But however it ends up, so long as we know what the answer will be, we can utilize it effectively in our programs. The trick with this construct usually in C is that the C standard doesn't specify the order of evaluation of function arguments, so you can never be sure if you'll get the same result if you compile it other than on your development system (different compilers may evaluate them in a different order). The Pugs example given in the original post seems to me to be fairly sane, as it shows left-to-right evaluation. The Perl 5 example, as far as I can tell, shows left-to-right for the first case and right-to-left for the second case, which is just odd... please correct me if I'm wrong, but that seems the only way those answers could have been arrived at. So really, what needs to be said is how Perl 6 is supposed to evaluate the arguments to function calls, then we can know if the current behaviour in Pugs is correct.
Re: Blocks, continuations and eval()
On Tue, Apr 12, 2005 at 04:17:56AM -0700, Larry Wall wrote: We'll make continuations available in Perl for people who ask for them specially, but we're not going to leave them sitting out in the open where some poor benighted pilgrim might trip over them unawares. Sorry for replying so late, but I missed your reply somehow. I just want to ask a little clarification on this; exactly what kind of hiding are you considering for continuations? That is, do you just mean that there will not be a 'call/cc' primitive by default in the global namespace? I'm fine with that, as that's just one method of capturing the calling continuation. Larry -- wolverian signature.asc Description: Digital signature
Re: Test.pm =?utf-8?b?dC9mb3JjZV90b2Rv?= refactoring idea
Hi, Stevan Little stevan at iinteractive.com writes: - Should we remove all the todo_* functions and just use the t/force_todo file? the idea was that t/force_todo lists the tests which are only TODOed because of release preparation, and the todo_* functions mark tests which are real TODO tests. If we take this way, then we should certainly rename t/force_todo to t/todo_tests (or sth. similar). - Should we do away with the t/force_todo file and introduce a force_todo() function? The idea is to move from the more centralized t/force_todo file to a more decentralized force_todo() function which would accept a list of test numbers which would be forced-TODO on a per-file basis. The idea was that t/force_todo can be deleted/cleared after a release, so all tests which were only force_todoed were instantly unTODOed. But if we remove all todo_* functions and go the todo_tests way, then we really should use a sub (todo_tests(...), for example), as you propose. force_todo(1, 5, 10 .. 15, 25); That'd be cool :) Of course, we could make Test.pm parse sth. like the following, too. t/my_test.t 1 5 10..15 25 --Ingo -- Linux, the choice of a GNU | Life would be so much easier if we could generation on a dual AMD | just look at the source code. Athlon!| -- Dave Olson
Re: [pugs]weird thing with say ++$
On Thu, Apr 21, 2005 at 02:28:52PM +0100, Matthew Walton wrote: On Thu, Apr 21, 2005 at 11:45:27AM +0200, Paul Johnson wrote: It certainly makes more sense to me that the answer would be 2 2. But however it ends up, so long as we know what the answer will be, we can utilize it effectively in our programs. The trick with this construct usually in C is that the C standard doesn't specify the order of evaluation of function arguments, so you can never be sure if you'll get the same result if you compile it other than on your development system (different compilers may evaluate them in a different order). The Pugs example given in the original post seems to me to be fairly sane, as it shows left-to-right evaluation. The Perl 5 example, as far as I can tell, shows left-to-right for the first case and right-to-left for the second case, which is just odd... please correct me if I'm wrong, but that seems the only way those answers could have been arrived at. So really, what needs to be said is how Perl 6 is supposed to evaluate the arguments to function calls, then we can know if the current behaviour in Pugs is correct. That trick in the C language is not an accident, but deliberate. Leaving the result undefined allows compiler writers to choose the definition that fits best for that compiler's internal structure and/or the target hardware architechture. Thus, when people write code that doesn't happen to care about the abiguity in the spec, it is processed (run/compiled) in the best way the compiler writer can provide. In C, at least, you can't always tell whether a particular statement is ambiguous (e.g. i = *p1++ + *p2++ - do p1 and p2 always point to different memory locations?) and the cost of treating it in an ambiguity-safe manner might be significant, since C tends to get used for low level critical operations. The approach is: make the programmer handle the rare tough cases himself and let the compiler do the common job really well. That is similar to easy things should be easy, hard things should be possible but C puts more emphasis on run time speed than programmer utility in how it applies its philosophy. --
Re: Test.pm t/force_todo refactoring idea
Ingo, On Apr 21, 2005, at 10:03 AM, Ingo Blechschmidt wrote: - Should we do away with the t/force_todo file and introduce a force_todo() function? The idea is to move from the more centralized t/force_todo file to a more decentralized force_todo() function which would accept a list of test numbers which would be forced-TODO on a per-file basis. The idea was that t/force_todo can be deleted/cleared after a release, so all tests which were only force_todoed were instantly unTODOed. Unfortunately that is not how it is being used though. It sticks around, and in some cases maybe even being used as a informal TODO list. force_todo(1, 5, 10 .. 15, 25); That'd be cool :) Of course, we could make Test.pm parse sth. like the following, too. t/my_test.t 1 5 10..15 25 We could but again, we would be imposing more of a penalty on test files which dont need it. Although after some discussion with nothingmuch on IRC, I think I have come to good compromise. We remove all the todo_ functions, and we add a named param todo to all our test functions. This would allow test level TODO-ing. Then we add the force_todo() function, to allow for file level TODO-ing. And we introduce some kind of global variable/env variable to do test suite wide TODO-ing. This should give us enough granularity of control as well as make it simple to just flip a switch for release. Any thoughts? - Stevan
Re: Test.pm t/force_todo refactoring idea
Hi, Stevan Little wrote: The idea was that t/force_todo can be deleted/cleared after a release, so all tests which were only force_todoed were instantly unTODOed. Unfortunately that is not how it is being used though. It sticks around, and in some cases maybe even being used as a informal TODO list. true. Although after some discussion with nothingmuch on IRC, I think I have come to good compromise. We remove all the todo_ functions, and we add a named param todo to all our test functions. This would allow test level TODO-ing. Then we add the force_todo() function, to allow for file level TODO-ing. And we introduce some kind of global variable/env variable to do test suite wide TODO-ing. This should give us enough granularity of control as well as make it simple to just flip a switch for release. That sounds great! :) --Ingo -- Linux, the choice of a GNU | The next statement is not true. generation on a dual AMD | The previous statement is true. Athlon!|
Re: Blocks, continuations and eval()
On Thu, Apr 21, 2005 at 04:30:07PM +0300, wolverian wrote: : On Tue, Apr 12, 2005 at 04:17:56AM -0700, Larry Wall wrote: : We'll make continuations available in Perl for people who ask for : them specially, but we're not going to leave them sitting out in the : open where some poor benighted pilgrim might trip over them unawares. : : Sorry for replying so late, but I missed your reply somehow. I just want : to ask a little clarification on this; exactly what kind of hiding are : you considering for continuations? That is, do you just mean that there : will not be a 'call/cc' primitive by default in the global namespace? : I'm fine with that, as that's just one method of capturing the calling : continuation. I suspect it's just something like use Continuations; at the top to enable the low-level interface. There would be no restriction on using continuation semantics provided by other modules, because then the use of that other module implies whatever form of continuation it provides. My concern is primarily the reader of the code, who needs some kind of warning that one can get sliced while juggling sharp knives. If we were willing to be a little more Ada-like, we'd make it a shouted warning: use CONTINUATIONS; Hmm, maybe that's not such a bad policy. I wonder what other dangerous modules we might have. Ada had UNCHECKED_TYPE_CONVERSION, for instance. Larry
Re: -X's auto-(un)quoting?
On Thu, Apr 21, 2005 at 10:18:17AM +0200, Michele Dondi wrote:
: Are the -X functions still going to be there? I definitely hope so!
Certainly. They're useful, and one of the things people love about Perl.
In fact, we're enhancing them to be stackable, so you can say
if -r -w -x $filename {...}
to and the conditions. Or maybe there's a better solution to that
now that we have junctions, on the order of
if $filename ~~ -r -w -x {...}
Then we also get our or for free. We'd just say that ~~ binds
the default of -X just as it does m// or s///.
The only fly in the ointment is that this is awfully ambiguous because
-X is a unary operator looking for an argument, and you're not giving
it one. But it might think the next thing is a sub ref starting with ''.
Ouch. Not sure where to go with that, other than require space or parens
when ambiguous.
: However, to come to the actual question, it has happened to me to have to
: do, in perl5 that is:
:
: perl -lne 's/^//;s/$//;print if -e'
:
: or (less often)
:
: perl -lne '$o=$_;s/^//;s/$//;print $o if -e'
:
:
: Ok: no much harm done (to my fingertips). But then, talking about
: huffmanization, could a standard adverb be provided for -X's to the effect
: of specifying that the passed filename is quoted, say in double (or if
: sensible in single) quotes: for I find that to be a common filelist
: format. Ideally, what I'd like to do is
:
: perl -lne 'print if -e :q'
It seems to me that -e «$_» would handle most of these cases, as long as
whitespace always comes in quoted so that you always end up with one word.
That seems more general than a special option to -X ops.
Larry
Re: Blocks, continuations and eval()
On Thu, 21 Apr 2005 08:36:28 -0700, [EMAIL PROTECTED] (Larry Wall) wrote: Hmm, maybe that's not such a bad policy. I wonder what other dangerous modules we might have. Ada had UNCHECKED_TYPE_CONVERSION, for instance. How about use RE_EVAL; # or should that be REALLY_EVIL? Larry
Re: Unify cwd() [was: Re: $*CWD instead of chdir() and cwd()]
On Thu, Apr 21, 2005 at 08:22:29AM +0200, Johan Vromans wrote: : From the perspective of 'current directory' there should also be a : simple and elegant way that will do in most cases. Advanced tricks can : be made possible using separate modules and such. Yes, easy things should be easy, and hard things possible. : Maybe the basic problem is that 'current directory' is a system : dependent file system location that is not a fixed string, although it : usually can be represented as a string. Similar to a simple 'open', I : think the most common use of 'cwd' (or whatever) is to return a file : system location that can be returned to later, much in the sense of : 'tell' and 'seek'. I think this can be implemented in a quite fail : safe way on most platforms. I kinda like the proposed @CWD interface, insofar as it abstracts out the most system-dependent part of the filename, the delimiter. Since Perl 6 is throwing away $ in favor of a per-array property, that property could simply be / for Unixish filenames. Then we can write things like: temp push @CWD, subdir err die Can't chdir: $!; I still think @CWD should try to track the actual directory you're in though if some operation fails, which implies that the push above is returning a reasonable result code, and whatever interface we give for absolute navigation also has to return a reasonable result code, which means it's not mere assignment. I think we can allow @CWD = @SOMEDIR; but that part of the interface probably needs to throw an exception if it fails, since assignment must return @CWD. Or maybe there's some way to hack it, but that seems kind of hackish. One interesting thought. Since $ is turning into a property, and since some directory schemes require varying delimiters, maybe the $-like property needs to be a list of delimiters, which you repeat the last one of when you run out. So Windows might use : /, while VMS might use [ ] / or whatever it was, I forget. But this would generalize to any array that needs varying delimiters in its representation. Larry
Re: -X's auto-(un)quoting?
Larry Wall skribis 2005-04-21 8:54 (-0700):
if $filename ~~ -r -w -x {...}
Just curious - would the following dwym?
if (prefix:-r prefix:-w prefix:-x)($filename) { ... }
It seems to me that -e «$_» would handle most of these cases, as long as
whitespace always comes in quoted so that you always end up with one word.
That seems more general than a special option to -X ops.
Wouldn't it be a good option to combine the filetest operators into one
operator? It'd even be historically correct to call that test:
test(:r :w, $fn);
I still like -r -w $fn much better than the binding and the ~~ things.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Test.pm t/force_todo refactoring idea
On Thu, Apr 21, 2005 at 11:17:11AM -0400, Stevan Little wrote: Although after some discussion with nothingmuch on IRC, I think I have come to good compromise. We remove all the todo_ functions, and we add a named param todo to all our test functions. This would allow test level TODO-ing. Then we add the force_todo() function, to allow for file level TODO-ing. And we introduce some kind of global variable/env variable to do test suite wide TODO-ing. I don't quite understand the global/env variable idea. Can you explain that in more detail? This should give us enough granularity of control as well as make it simple to just flip a switch for release. Any thoughts? I really like the solution you've presented: clean and functional. -kolibrie
Help required urgently !!!!!!
use matchpairs not working. Currently having perl 5.0 in my system. Please suggest. Manoj
Re: Test.pm t/force_todo refactoring idea
On Apr 21, 2005, at 12:00 PM, Nathan Gray wrote: On Thu, Apr 21, 2005 at 11:17:11AM -0400, Stevan Little wrote: Although after some discussion with nothingmuch on IRC, I think I have come to good compromise. We remove all the todo_ functions, and we add a named param todo to all our test functions. This would allow test level TODO-ing. Then we add the force_todo() function, to allow for file level TODO-ing. And we introduce some kind of global variable/env variable to do test suite wide TODO-ing. I don't quite understand the global/env variable idea. Can you explain that in more detail? It could be something as simple as this: %*ENVTODO_ALL_FOR_RELEASE = 1; It is really just a hack to allow for quick TODO-ing of all failing tests in the suite. I am not sure how well it will work out to be honest. This should give us enough granularity of control as well as make it simple to just flip a switch for release. Any thoughts? I really like the solution you've presented: clean and functional. Thanks, I have to give credit to nothingmuch, the todo named param was his idea :) -kolibrie
Re: alarm() and later()
Larry Wall [EMAIL PROTECTED] wrote:
Assuming we
rehuffmanize kill to sendsignal or some such, we have:
signal is a verb as well as a noun.
sub alarm ($secs) {
{ signal $*PID, Signal::ALARM }.cue(:delay($secs));
}
It even reads pretty nicely: signal 4242.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
Re: alarm() and later()
On Thu, Apr 21, 2005 at 01:51:36PM -0700, Brent 'Dax' Royal-Gordon wrote:
: Larry Wall [EMAIL PROTECTED] wrote:
: Assuming we
: rehuffmanize kill to sendsignal or some such, we have:
:
: signal is a verb as well as a noun.
:
: sub alarm ($secs) {
:{ signal $*PID, Signal::ALARM }.cue(:delay($secs));
:}
:
: It even reads pretty nicely: signal 4242.
The cultural problem is that C's ancient signal() sets a signal
handler rather than sending a signal. I figured as long as we were
trying to discourage the use of signals we might as well make it
something even longer, but clearer.
Larry
Re: -X's auto-(un)quoting?
On Thu, Apr 21, 2005 at 06:40:54PM +0200, Juerd wrote:
: Larry Wall skribis 2005-04-21 8:54 (-0700):
: if $filename ~~ -r -w -x {...}
:
: Just curious - would the following dwym?
:
: if (prefix:-r prefix:-w prefix:-x)($filename) { ... }
It might do what you mean. Personally, I would never mean that if I
could help it. :-)
: It seems to me that -e «$_» would handle most of these cases, as long as
: whitespace always comes in quoted so that you always end up with one word.
: That seems more general than a special option to -X ops.
:
: Wouldn't it be a good option to combine the filetest operators into one
: operator? It'd even be historically correct to call that test:
:
: test(:r :w, $fn);
Hmm. I think this works syntactically:
$file ~~ all(:r:w)
: I still like -r -w $fn much better than the binding and the ~~ things.
There's one minor problem with -r -w $file, which is that it evaluates
right-to-left, which is going to surprise some people who think they
want to say
-e -r $file
when they really mean
-r -e $file
But that doesn't really matter much unless you're so much into speed
that you think about falsifying the test without doing a stat().
Now the interesting thing about the ~~ approach is that it naturally
lends itself to
given $file {
when :x {...}
when :r:w {...}
when :r(0) {...}
when :u | :g{...}
default:
}
I suppose it's a little bit rude to grab all the pairs for testing
against all the strings, so maybe we have to say
given $file.test {...}
$file.test ~~ :r:w
or maybe
given $file.stat {...}
$file.stat ~~ :r:w
which leaves room for lstat if we need it, though I can't say I'm fond
of the Unix naming scheme here. If we borrow from IO::All maybe it's just:
given io($file) {...}
io($file) ~~ :r:w
BTW, I'm assuming the $file is either $filename or $filehandle there.
Larry
Re: [perl #34999] [TODO] remove more old stuff
Now that we're using SVN, Leopold Toetsch wrote: Some outdated files: lib/Parrot/PackFile/* lib/Parrot/PackFile.pm lib/Parrot/PackFile2.* what is: lib/Parrot/String.pm old packfile code? lib/Parrot/Types.pm same? lib/Parrot/Key.pm same? All the above files appear to be remnants of disassemble.pl, which was deleted in the repository 20 months ago. grep'ing the repository turned up no additional references (`grep -r 'Parrot::Packfile' parrot/ | perl -ne 'print if !/.svn/'`). These should be able to be removed. Do we still need: lib/Parrot/PMC.pm Yes. This is an autogenerated file used both for the PMC compiler and for testing purposes. lib/Parrot/Makefile.PL This is the Makefile for lib/Parrot/Pakfile2.pm (and lib/Parrot/Pakfile2.xs), which is not referenced anywhere. I think all 3 of these files can be removed. and what about the chartypes directory, seems to be created in lib/Parrot/Distribution.pm This appears to be a remnant of the long distant past (pre ICU). There's only one file that mentions it outside of lib/Parrot/Distribution.pm, and that's the ChangeLog, which lists several files in the chartypes/ directory from the days of simon. Already discussed: classes/pmc2c.pl old PMC compiler Already removed. classes/pmcarray.pmc wrapper for PerlArray I'm not sure what was discussed here. -- matt diephouse http://matt.diephouse.com
Re: [perl #34999] [TODO] remove more old stuff
Matt Diephouse wrote: Leopold Toetsch wrote: classes/pmcarray.pmc wrapper for PerlArray I'm not sure what was discussed here. I believe this is a remnant from before it was decided that we'd use Resizable and Fixed for container types; Anything that's using PMCArray should be switched to ResizablePMCArray (or FixedPMCArray if that's all it needs) (or, if that fails due to an unimplemented feature, to PerlArray, with a TODO to add the appropriate functionality to ResizablePMCArray) Regards.
MMD acting up...
I've encountered some multimethod dispatch funnyness tonight. The included code which one would expect to produce a value of 1 ends up printing a value of 3. Changing a and b to be regular Integer types seems to work. Can anybody shed any more light on this? -c .sub _main @MAIN .local pmc class .local pmc a .local pmc b subclass class, Integer, LispInteger a = new LispInteger b = new LispInteger a = 1 b = 1 print a print * print b print = a = a * b print a print \n end .end
Re: New language: Parrot Common Lisp
Cory Spencer [EMAIL PROTECTED] wrote: For examples of what it can currently do, look in the lisp/ subdirectory in the files loaded at run time (bootstrap.l system.l and primitives.l). Anyone who would like to have a peek at what I've got so far is invited to download the 0.1.0 release from here: http://www.sprocket.org/pcl/pcl-0.1.0.tar.gz Bug reports, patches and comments are most certainly welcome. :) Excellent. Lisp is a lot of fun, although I'm admittedly very rusty. And generally mixed up about the differences between Lisp and Scheme (especially the keywords). One question: - (defun (square x) (* x x)) ** DEFUN: (((SQUARE . (X . NIL)) . ((* . (X . (X . NIL))) . NIL)) . (1 . NIL)) T - (square 2) *** ERROR: SQUARE is not a function name Is that because (a) that's not implemented yet or (b) I'm doing something wrong? I haven't found the time to delve into the source yet. Also, while playing I around I found this happening: - (* 2 3) 9 - (* 4 3) 9 Looks like a bug. Maybe I'll find time to brush off my Lisp and start writing some tests in the process. :-) -- matt diephouse http://matt.diephouse.com
