[perl #31920] Win32 nci test failure - tests 35-37 42-43
t/pmc/nci.t passes. Please close this ticket. t\pmc\nciok All tests successful. Files=1, Tests=56, 19 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
[perl #24396] FAIL parrot-0.0.13 MSWin32-x86-multi-thread
Can't reproduce this one. Please close the ticket. t/src/iook 1/20 skipped: fdopen does not handle illegal modes correct All tests successful, 1 subtest skipped. Files=1, Tests=20, 55 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
[perl #34059] [PATCH][MSWin32] Add NCI test symbols
t/pmc/nci.t passes. This ticket should be closed. t\pmc\nciok All tests successful. Files=1, Tests=56, 20 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) The ticket for the more generic solution is #31649: [TODO] Win32 - Automatically Export Symbols
[perl #16764] [PATCH] library building win32
[jgloudon - Sun Aug 25 17:15:36 2002]: This is a simple fix to the broken libparrot.a makefile target for Visual C++ win32 builds so that 'nmake test' works. This does not fix other non- UNIX targets and win32 builds with the borland compilers. The latter should be a matter of providing the approprate library building tool and options in the hints file. libparrot builds fine, Cnmake test works. This issue is resolved, one way or the other, and should be closed.
[perl #29738] [PATCH] PARROT_API Generic
Please mark this patch as rejected. It's not tasty enough for our patchmonster.
Returning varying numbers of results from a tail call
In situations where A calls B and B tail-calls C, and C produces some arbitrary number of return values, I would like to be able to generate code for B without having to care how many values A expects, how many C produces, or even whether these numbers are fixed at compile-time. I can sort of do this now via tail-call optimization, e.g.: .sub _B non_prototyped .param pmc function .local pmc argv argv = foldup 1 print [doing _B]\n $I33 = defined function if $I33 goto doit bad_func: printerr _B: Bad function.\n die doit: .pcc_begin prototyped .flatten_arg argv .pcc_call function .pcc_end .pcc_begin_return .pcc_end_return .end This works, but I have to jump through numerous hoops: 1. I must resort to this lame idiom that appears to accept and return no values. 2. The code must be compiled with -Oc, or that is in fact what it does. 3. I must live with the fact that I won't ever see B in a backtrace; I get tail-merging semantics whether I like it or not. 4. The return must be just before .end; it doesn't work if I invert the sense of the test and swap the bad_func and doit blocks. (Is this a bug in tail-call optimization?) The number of hoops is surprising, given that perl5 has this call and return all values semantics. (But perl6 seems to return everything in an array, so that was no help. Whatever.) The key problem is that this code works only if compiled with tail-merging (tail-call optimization) enabled, which strikes me as wrong; correct code should not have to depend on an optimization, certainly not a non-default one. So I would like to be able to tell IMCC explicitly that I am doing a tail call which should pass all returned values back to my caller. This should be regardless of whether tail-merging is enabled, but should definitely be tail-merged if so. I thought I might be able to do this via .pcc_call with an explicit continuation, but I don't see how to get to the continuation that returncc would use. Is this possible? Better still would be an explicit way to say call and return all values. Here's one possible syntax for the example above: doit: .pcc_begin prototyped .flatten_arg argv .pcc_tail_call function .pcc_end .end The .pcc_tail_call function would be an alternative to the pcc_call opt_label pcc_results sequence in the pcc_sub_call production. It seems to me that this could generate a normal call followed by returncc (without changing I0-4) if tail-call optimization is off. But then, I'm pretty wet behind the ears when it comes to hacking Parrot, so I couldn't produce a patch without help, or at least some direction. Not to mention the possibility that there may be something I've missed . . . TIA, -- Bob Rogers http://rgrjr.dyndns.org/
TAP docs
I'm updating the TAP docs in Test::Harness, so that I can update Test::Harness and get it into bleadperl so that (I hope) it makes it into Perl 5.8.7. Please have a look at my latest/greatest HTMLified version of Test::Harness::TAP.pod: http://www.petdance.com/random/tap.html Get those comments in ASAP, please. Thanks, xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: TAP docs
On Sat, Feb 19, 2005 at 10:34:06AM -0600, Andy Lester ([EMAIL PROTECTED]) wrote: Please have a look at my latest/greatest HTMLified version of Test::Harness::TAP.pod: http://www.petdance.com/random/tap.html Also note that it goes with the form: ok 1 Description # Directive # Diagnostic xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Tests for pugs
I have started the 03operator.t. And add it to the svn repository. Thanks, hcchien 2005/2/19 1:12 Autrijus Tang Hi fellow Pugs committers (and would-be committers). This is a friendly message from your self-elected project leader. :) I'm very glad of your help in hacking pugs, particularly in filling out unit tests under t/. As it will likely require some coordination, I think perl6-compiler is the correct list for us to coodinate. So, if you had not done so, please subscribe p6c by sending a mail to: [EMAIL PROTECTED] So, here is some ideas in the layout of t/. Alin has a wonderful idea of forward-porting Perl5's unit test suite, starting from base/ and op/, to our t/ directory: http://svn.openfoundry.org/pugs/t/ As the scope of work is large, and for reducing duplicated works, I encourage people who want to help to announce your intent (i.e. what subdirs will you be working on) on the perl6-compiler list. It's not neccessary to do so, though, as long as you commit fast enough. :-) Other people who would like to help is encouraged to announce the intent on this list, in a similar fashion; I'd be glad to hand out subversion committer bits -- just drop me a line or find me on irc.perl.org #perl. Also, ycheng has a good idea of converting Synopsis as working specs, by adding unit test directly into the .pod files. To that end, I'm trying to set up svk mirrors from here: http://cvs.perl.org/cgi/cvsweb.cgi/perl6/doc/design/syn/ Into pugs/t/Synopsis/S01.pod, and then use them directly as unit tests, eventually subsuming the existing 02atoms.t and 06sub.t. Before that is done, though, hacking on the current synopsis-based tests is still very welcome. Another change I'll make tomorrow is to run the test harness using: pugs -MTest::More So we'll have access to is(), ok() and other primitives. I'll write more on the list when that part is ready. Again, I'd like to thank you for your willingness to help. :) Thanks, /Autrijus/ PGP.sig Description: This is a digitally signed message part
Re: Junction Values
On Fri, Feb 18, 2005 at 11:31:54PM -0800, Brent 'Dax' Royal-Gordon wrote: Junctions are intended to ultimately be used in boolean tests. That's why the values of the junction have an any/all/one/none relationship. The proper data structure here is an array. (Actually, ironically enough, it's probably a set, not an array.) It's one set for any()/all()/one() and two sets for none(). Of course, if something (eg. functions) cannot be tested for equality, then we'll have to assume them to be unique from each other anyway, in which case junctions do act as arrays. [1] Note, however, that this needs to be done carefully. For example, while it doesn't really make sense for the string arguments of a call to Cprint to be junctions, the object argument is another matter entirely: #!/usr/bin/perl6 # naive tee $OUT=$OUT open( $_) for @ARGS; print or die Can't write to $!.filename: $! for *$IN;# Or however it's done this week I think it's an unary = this week, according to S04: print for =*$IN; Thanks, /Autrijus/ pgpGifnGif84A.pgp Description: PGP signature
Re: Junction Values
Hmm. On rereading my last message, I feel that it comes across as angry, and critical of this entire discussion or perhaps of particular participants. That was certainly not my intent and I apologize if that's how it appeared. I genuinely respect the contributions of every person on this list, and even when (as now) I strenuously disagree with the ideas expressed, I know that those contributions are sincere and offered with the best interests of Perl at heart. I still stand by every point I made in that last message, but I'm sorry that I let my frustrations leak into the discussion. Damian
Re: Junction Values
Brent 'Dax' Royal-Gordon wrote: Rod Adams [EMAIL PROTECTED] wrote: The caller is not in a position to know if the callee is internally structured in such a way that passing in a raw junction makes sense. Sure they are. It's called reading the documentation. If it doesn't say it can handle junctions, it probably can't. I don't want to have to stop in the middle of a hundred-line function to think, Does Store::Market.get act sanely when I give it a junction? Do I need to explode it manually, or will it handle the junction nicely on its own? You call functions where you don't know what data types they are expecting? That's... surprising. Even in a loosely typed world like Perl, knowing what a sub or method is expecting to be fed seems like a good idea to me. I see checking for accepting junctions as input as being on the same level as Does it want a list or an arrayref here?. When I'm writing my own insanely large functions, I'm constantly hitting the docs to see the nuances about the method calls I'm not already intimately familiar with. And if I'm going to attempt to use a function in a new way (like feeding it a Junction), I recheck the docs to make sure I'm not setting myself up for trouble down the road. Your mileage may vary. -- Rod Adams. (PS - This should not be construed to be an attack on you or your programming style. It is not. Though I've never seen you in action, I have every reason to believe you are a fully competent developer. It is simply a response to your statement above, explaining why I thought the attitude expressed there represented a weak argument.)
='s LHS
Is ='s LHS still automatically quoted? What are the rules? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Junction Values
Damian Conway wrote:
Rod Adams wrote:
All I want now is for autothreading to be explicit.
It already *is*.
The only way that:
is_prime($x)
can ever autothread is if $x holds a junction. But that can now only
happen if there's an explicit Cuse junctions in scope where $x was
assigned to (or the explicit use of some other module that also
activates Cuse junctions). So $x having a junction must be a known
possibility at that point.
Of course, literal junctions *will* autothread in all circumstances:
is_prime(any(6,7,8))
is_prime(6|7|8)
I had not caught the difference between:
use junctions;
$x = 6|7|8;
if is_prime($x) {...}
and
if is_prime(6|7|8) {...}
before. Is this new, or yet another important detail I missed along the
way? Or is this a side effect of not being able to store a Junction, and
can go away if C use Junctions is turned on?
But they're both explicit too: you're explicitly using junction
constructors, so the autothreading can hardly come as a surprise.
*If* we are guaranteed than an explicitly created junctions will always
autothread, I'll agree with this.
I will, however, question if this is optimal. Compare two simple cases:
C $x == any(4,5,6) and C $x all(4,5,6) . Both of them are prime
candidates to some optimizations, but the optimizations are likely
rather different. If we pass the junction into the operator, then it can
perform some custom tailored code, to make things much more efficient,
instead of relying on a more generalized junction optimizer to handle
things.
What this also means is that if you wish to pass an anonymous junction,
you can't. You have to do something like:
{
use junctions;
some_func(my $x = any(4|5|6));
}
Which just seems silly.
And if:
is_prime($x)
does happen to autothread when you weren't expecting it to, then one
of two things will happen. Either the subroutine will be 'pure' in
which case there's no problem in autothreading it; or else the
subroutine will have side effects, in which case you'll get an
explicit warning when the autothreading occurs.
I addressed earlier concept of how does perl know when there are side
effects, particularly with the execution path can weave to parts written
in pure-parrot. In particular, if the Patrick responded by implying
that there was no such side effect protection. see:
http://www.nntp.perl.org/group/perl.perl6.language/19210 (my post)
http://www.nntp.perl.org/group/perl.perl6.language/19212 (Patrick's
response)
I see your statements on the subject, and Patrick's to be at odds. But
then again, it might be that I've misread something again, though I'm
doing my best to avoid it now.
I request some clarification on this. If nothing else, to make sure you
and Patrick have the same understanding of what's happening.
This problem goes away completely with explicit autothreading. perl
would no longer be making assumptions about what to autothread, and what
to carp over.
Personally, I think it's completely fascist to require a Cuse
junctions pragma in order for junctions to even be stored in
variables. It's as bizarre as requiring Cuse strings or Cuse
references or Cuse undef or Cuse infinities would be. Yes, it
*is* possible to get unexpected behaviour from passing a junction
where it isn't expected, but it's already possible to get unexpected
behaviour by passing a string or an undef or a reference or an object
where it isn't expected. Junctions are nothing new in that respect.
I had it in my head that if I were to get my »Junction« explicit
threading idea, I was going to follow up by saying the block against
storing junctions was a case of diminishing returns at that point, and
should probably go away. I appreciate the stop-gap measure that it was,
but I'd prefer to solve the real problem at hand.
Ironically, by using the Awesome Power of Junctions:
I hope I never gave the impression that I felt Junctions were not
powerful... That was not the case. If anything, I was arguing that they
were *too* powerful... But in the end, I realized it's just the implicit
autothreading I didn't like.
Look, I do understand the arguments in the other direction. I've
understood them for the past five years that I've been developing the
concept of superpositional data-types. I've thought them through
numerous times myself, and in the end: I just don't buy them.
The whole point of junctions is to make the threading of operations on
datasets both automatic and implicit; to make it Do The Right Thing
without the hassles of explicit threading. If you don't want that,
that's fine: just don't use junctions. Use arrays and hyperoperators
instead. And we'll happily give you a Cno junctions pragma so you
can be emphatic about not wanting them.
I can certainly understand the hassles of explicit threading if one is
thinking:
$y = func(any(3|4|5));
has to be explicitly written as:
$y = any(any(3|4|5).values().map(func($_)));
or some such, but is it
Re: ='s LHS
Patrick R. Michaud skribis 2005-02-19 14:53 (-0600): On Sat, Feb 19, 2005 at 09:10:05PM +0100, Juerd wrote: Is ='s LHS still automatically quoted? What are the rules? S02 says that = still autoquotes any bare identifier to its immediate left, even keywords and macros. Thanks - I wonder how I managed to read that without absorbing the information. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ='s LHS
On Sat, Feb 19, 2005 at 09:10:05PM +0100, Juerd wrote: Is ='s LHS still automatically quoted? What are the rules? S02 says that = still autoquotes any bare identifier to its immediate left, even keywords and macros. Pm
Re: Junction Values
Damian Conway wrote: Hmm. On rereading my last message, I feel that it comes across as angry, and critical of this entire discussion or perhaps of particular participants. That was certainly not my intent and I apologize if that's how it appeared. I genuinely respect the contributions of every person on this list, and even when (as now) I strenuously disagree with the ideas expressed, I know that those contributions are sincere and offered with the best interests of Perl at heart. I still stand by every point I made in that last message, but I'm sorry that I let my frustrations leak into the discussion. Damian Well, I for one, never took any offense to any of the responses sent my way. And I appreciate the patience it's likely taken to not just completely Warnock me. However, I also realize that I might have stepped on some toes of the course of this long discussion. Which was never my intention, and I'll apologize to any who feel I've slighted them in the process. I do believe everyone on this list shares the same goals of making Perl 6 the possible language that it can be. However, opinions will vary as to what that actually means. Being a group of people that can by and large be described as having a fairly large egos, these differences of opinion can become rather passionate. And passion leads to some pretty extreme responses. It certainly hasn't helped matters that the exact nature of my proposal has changed in some fairly drastic ways on a regular basis, as I came to a better understanding of what Junctions were, and how they were being implemented. I apologize for any confusion this may have caused, but I do think the resulting discussions have shed some new insights on Junctions, Sets, what it means to have a sigil, why junctions can't just be another class, and several other topics. Poor Mr. Fowles is likely having nightmares figuring out how to summarize all of this. Positions I still stand by: - Sets belong in the language, and need more support. This can likely be done at the module level, but I'd like them better incorporated, preferably with their own sigil. However, I believe they can peacefully coexist with Junctions, and one concept does not need to crowd out the other. - Implicit autothreading is a Bad Thing, and should not happen. This is almost entirely due to the side effects such behavior can generate. To keep the power of junctions viable, explicit threading should be trivially easy, but it should be explicit, none the less. -- Rod Adams
Re: Junction Values
On Sat, Feb 19, 2005 at 02:40:00PM -0600, Rod Adams wrote:
Damian Conway wrote:
Of course, literal junctions *will* autothread in all circumstances:
is_prime(any(6,7,8))
is_prime(6|7|8)
I had not caught the difference between:
use junctions;
$x = 6|7|8;
if is_prime($x) {...}
and
if is_prime(6|7|8) {...}
before. Is this new, or yet another important detail I missed along the
way? Or is this a side effect of not being able to store a Junction, and
can go away if C use Junctions is turned on?
It's a side effect of not being able to store a junction.
I will, however, question if this is optimal. Compare two simple cases:
C $x == any(4,5,6) and C $x all(4,5,6) . Both of them are prime
candidates to some optimizations, but the optimizations are likely
rather different. If we pass the junction into the operator, then it can
perform some custom tailored code, to make things much more efficient,
instead of relying on a more generalized junction optimizer to handle
things.
There's nothing to *prevent* us from passing a junction into a routine
that perform custom tailored code for the junction--it's just not
the default. If infix:«» wants to optimize for junctions, we define
it with something like
multi sub *infix:«»(Junction $x, Junction $y) returns bit { ... }
and it can then optimize appropriately. Autothreading routines
by default occurs only when the junction arguments are bound to scalar
parameters that are inconsistent with the Junction type (S09).
And if:
is_prime($x)
does happen to autothread when you weren't expecting it to, then one
of two things will happen. Either the subroutine will be 'pure' in
which case there's no problem in autothreading it; or else the
subroutine will have side effects, in which case you'll get an
explicit warning when the autothreading occurs.
I addressed earlier concept of how does perl know when there are side
effects, particularly with the execution path can weave to parts written
in pure-parrot. In particular, if the Patrick responded by implying
that there was no such side effect protection. see:
http://www.nntp.perl.org/group/perl.perl6.language/19210 (my post)
http://www.nntp.perl.org/group/perl.perl6.language/19212 (Patrick's
response)
I see your statements on the subject, and Patrick's to be at odds. But
then again, it might be that I've misread something again, though I'm
doing my best to avoid it now.
AFAICT there aren't any conflicts between my and Damian's statements.
The example given in the 19210 post supposed that a Junction would
get passed to a pure Parrot function, but didn't actually provide
code to demonstrate that. Any pure Parrot routine declared as
accepting scalars inconsistent with Junctions would be autothreaded
the same as any other routine.
Assuming that a Junction *is* passed to a pure Parrot routine
(e.g., via a list or other data structure), and assuming that
Parrot is not itself supporting autothreading, then it's fairly
straightforward to define the Junction type such that requests
to stringify, numify, or otherwise access/evaluate the Junction
as a non-Junctional value will throw an exception.
All of this knowledge, which comes almost innately during the
process of writing code, can become almost Halting Problem hard
for the compiler or runtime to figure out.
So far I haven't seen anything about Junctions that requires an
awful lot of knowledge, guessing, or exhaustive evaluation on
the part of the compiler/runtime system. They will likely need
to do a bit of checking of the arguments to decide when to
autothread a call, but they're going to be doing other sorts
of argument checking anyway, and the additional checking to be
performed is fairly shallow -- just testing each argument
for isa(Junction) or its equivalent. (We don't have to perform
deep inspection of arrays or the like.)
Pm
Re: Junction Values
Rod Adams wrote:
I had not caught the difference between:
use junctions;
$x = 6|7|8;
if is_prime($x) {...}
and
if is_prime(6|7|8) {...}
There isn't one.
Is this new, or yet another important detail I missed along the way?
Or is this a side effect of not being able to store a Junction, and can go
away
if C use Junctions is turned on?
Yes, it's a side-effect of the new default prohibition on junction assignments
(though I'm still working hard to convince everyone that that prohibition
cripples junctions and that having to use junctions before you can assign a
basic Perl 6 scalar datatype to a variable is an abomination).
I will, however, question if this is optimal. Compare two simple cases:
C $x == any(4,5,6) and C $x all(4,5,6) . Both of them are prime
candidates to some optimizations, but the optimizations are likely rather
different.
If we pass the junction into the operator, then it can perform some custom
tailored code,
to make things much more efficient, instead of relying on a more
generalized junction
optimizer to handle things.
Sure. That's why we have the ability to specify subroutines where junctive
args are *not* autothreaded, by typing the corresponding parameter as taking a
junction:
multi sub infix:«==» (YourType $x, Junction $y) is symmetrical {...}
multi sub infix:«» (YourType $x, Junction $y) is symmetrical {...}
These two multisubs can optimize for junctive arguments to their hearts'
content.
I addressed earlier concept of how does perl know when there are side effects,
particularly with the execution path can weave to parts written in
pure-parrot.
In particular, if the Patrick responded by implying that there was no such
side
effect protection. see:
http://www.nntp.perl.org/group/perl.perl6.language/19210 (my post)
http://www.nntp.perl.org/group/perl.perl6.language/19212 (Patrick's response)
I don't see that Patrick's response implies that at all. In fact, I think his
statement that:
Well, the ultimate answer is that both Dan and Patrick (and others)
will negotiate the exact interface when we get to that point, and
that we don't seem to be too concerned about it at the moment.
(It could just be that we're both burying our heads in the sand
hoping it'll be magically solved by the other. :-)
However, in working out these examples I'm fairly comfortable that
it can be made to work at the Perl 6 compiler level if need be,
although it will probably be a lot more efficient if we can find a
way to do it within Parrot.
seems to confirm that detecting and reporting autothreaded side-effects is
entirely possible.
If nothing else, to make sure you and Patrick have the same understanding of what's happening.
I'm sure we will.
This problem goes away completely with explicit autothreading.
perl would no longer be making assumptions about what to autothread, and
what to carp over.
But that's the whole point of junctions! Namely that perl works it out for
you. If you don't want that to happen then don't use junctions (and don't
allow them to be used, by specifying Cno junctions).
If you want explicit threading (I refuse to call it autothreading; if it has
to be manually specified, it certainly isn't auto) then use arrays instead,
and thread your subroutines and operators over them using the explicit
hyperoperator notation (see example below).
But bowdlerizing the concept of junctions isn't the answer.
I'm no longer doing that.
Or at least, I'm no doing anything anywhere close to as extreme as some
of my other ideas over the last week or two. Which I can see perfectly
well, in retrospect, how you felt I was gutting the power away from
junctions, and how frustrating that must have been for you.
Thank-you for understanding that.
But I still don't like implicit autothreading, and likely never will. I
don't know how to explain it, but it just feels very wrong. It's down
there with using typeglobs to pass filehandles, which is thankfully
history.
I understand your qualms, even if you can't nail down the exactly reasons for
them.
However, I still disagree with them. I truly believe that junctions (including
their autothreading behaviour) ought to be core to Perl 6...and not ham-strung
in any way.
I appreciate that some people will not like the potential autothreading of:
if is_prime($x) {...} # Might possibly autothread
but I think it's sufficient to give those people:
# At the top of the program...
no junctions;
# and then...
if is_prime($x) {...} # Can't possibly autothread
As for explicit threading: hey, you've already got it. Just use an array
instead of a junction, and only allow explicit junctives. Either:
# At the top of the program...
no junctions 'assignment'; # Junctive constants okay
# and then...
if is_prime(any(@x)) {...} # Explicitly threaded
or, even more
Set sigils (was: Re: Junction Values)
On Sat, 19 Feb 2005 15:20:59 -0600, Rod Adams [EMAIL PROTECTED] wrote: Positions I still stand by: - Sets belong in the language, and need more support. This can likely be done at the module level, but I'd like them better incorporated, preferably with their own sigil. However, I believe they can peacefully coexist with Junctions, and one concept does not need to crowd out the other. Instead of primary sigils, what about secondary sigils on an array to mark it as an unordered set? @|foo = any @foo = all @^foo = one # can arrays be curried arguments? hmm @!foo = none After all, why should scalars get all the good secondary sigils? :) Ashley Winters
Lingering questions about Junctions.
Okay, Now that I've largely accepted junctions (except implicit autothreading, which is Bad.), I see some corners that need to be poked at in terms of how they fit into the language as a whole. All of these examples assume an appropriate level of use junctions; is in effect. - Can junctions be used as array/hash subscripts? In an rvalue context, this makes sense, in that you can simply return a junction of the deferences. But in an lvalue context, this gets dubious for everything except all() junctions. Consider: @x = 1..10; @x[any(4,3)] = 7; What does @x look like now? @x[all(4,3,2)] = 7; makes sense, as long as it means: @x[4,3,2] »=« 7; I don't want to even think about what: @x[none(1,2)] = 7; does. - Can you have non-scalar junctions? As the discussions surrounding C .. demonstrated, it's not that hard for someone to create a situation where a junction of lists might come into existence. But let's consider something a step beyond. %x = (a = 1, b = 2, c = 3) | (d = 4, e = 5, f = 6); @y = %x.keys; Does this explode, or does @y have something useful in it now? Before dismissing the concept completely, it's perfectly possible to create something much like a junctive hash via references: %x = (a = 1, b = 2, c = 3); %y = (d = 4, e = 5, f = 6); $z = one(\%x, \%y); @w = $z.keys; - What does it mean to sort a list of junctions? @x = any(1,6), all(2,5), one(3,4); @x = @x.sort; Does sort() carp on junctions, or is it just one of the weird things you have to live with if you're playing with junctions? -- Rod Adams
Re: Junction Values
On Sat, Feb 19, 2005 at 02:40:00PM -0600, Rod Adams wrote: I addressed earlier concept of how does perl know when there are side effects, particularly with the execution path can weave to parts written in pure-parrot. Patrick responded by implying that there was no such side effect protection. I should've included this in my previous post...and write it now simply to promote clarity/completeness: My response in #19212 was intended to show that the side-effect problems being described don't exist, and therefore there isn't any need for side-effect protections such as the ones being proposed. I didn't mean to imply that they would be needed but not available. Pm
Re: Junction Values
However, I also realize that I might have stepped on some toes of the course of this long discussion. Which was never my intention, and I'll apologize to any who feel I've slighted them in the process. Personally, I've found the thread to be incredibly useful in (1) understanding Junctions, and (2) getting a handle on the various ways in which they can be implemented. So it's been worthwhile for me. And no offenses have been intended or taken. Pm
#perl6, pugscode.org, and more
Hi. As my today's journal ( http://use.perl.org/~autrijus/journal/23258 ) announced, we have created a #perl6 channel on freenode to discuss everything about perl6, in particular to coordinate development of the Perl6 Compiler and Pugs. All is welcome to join. Also, I've registered http://pugscode.org/ and populated it with some basic information. As the site says, I'm handing out committer bits pretty liberally, so if you are willing to patch things, write tests, and hang out on IRC, please contact the team on IRC or by mail. :) See you on #perl6! Thanks, /Autrijus/ pgpzH2jHVDVMG.pgp Description: PGP signature
Re: Junction Values
Rod~ On Sat, 19 Feb 2005 15:20:59 -0600, Rod Adams [EMAIL PROTECTED] wrote: Poor Mr. Fowles is likely having nightmares figuring out how to summarize all of this. Not really nightmares, more sleepless nights twitching in fear... But I did skip writing it this week as this thread is the only one of great length and I was hoping to wait for it to resolve... Which it sounds like it is doing :-) Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
Re: Junction Values
Damian Conway wrote:
Rod Adams wrote:
Is this new, or yet another important detail I missed along the way?
Or is this a side effect of not being able to store a Junction, and
can go away if C use Junctions is turned on?
Yes, it's a side-effect of the new default prohibition on junction
assignments (though I'm still working hard to convince everyone that
that prohibition cripples junctions and that having to use junctions
before you can assign a basic Perl 6 scalar datatype to a variable is
an abomination).
FWIW, I agree with you that having something half enabled by default
make little sense. But I'll accept it as a stop gap until I get my
explicit threading.
And I really don't like the implications of how turning on use
junctions can also suddenly change the threading semantics of
junctions. Talk about subtleties in action...
I imagine some intermediate level programmer decides they are ready to
start playing with stored junctions. He adds a use junctions; at the
top of his file, thus turning it on for all functions written in that
package. Suddenly, some of his function calls with stop implicitly
threading, and instead start carping in some truly spectacular ways.
Said programmer quickly takes away the use junctions;, and never
considers using stored junctions again. It's just not worth the trouble,
in his mind.
If, however, he was conditioned to put in some »«'s whenever he wanted
his junctions to thread, he would not encounter this problem.
I will, however, question if this is optimal. Compare two simple cases:
C $x == any(4,5,6) and C $x all(4,5,6) . Both of them are prime
candidates to some optimizations, but the optimizations are likely
rather different.
If we pass the junction into the operator, then it can perform some
custom tailored code,
to make things much more efficient, instead of relying on a more
generalized junction
optimizer to handle things.
Sure. That's why we have the ability to specify subroutines where
junctive args are *not* autothreaded, by typing the corresponding
parameter as taking a junction:
multi sub infix:«==» (YourType $x, Junction $y) is symmetrical {...}
multi sub infix:«» (YourType $x, Junction $y) is symmetrical {...}
These two multisubs can optimize for junctive arguments to their
hearts' content.
I guess I misunderstood your statement of literal junctions *will*
autothread in all circumstances to mean _all_ circumstances, not just
ones where the callee didn't explicitly say they could accept them, or
if the current use junctions; status is in alignment with the moon, or
other such things.
I will allow you to alter that statement if you now find it
insufficiently qualified.
I don't see that Patrick's response implies that at all. In fact, I
think his statement that:
Well, the ultimate answer is that both Dan and Patrick (and others)
will negotiate the exact interface when we get to that point, and
that we don't seem to be too concerned about it at the moment.
(It could just be that we're both burying our heads in the sand
hoping it'll be magically solved by the other. :-)
However, in working out these examples I'm fairly comfortable that
it can be made to work at the Perl 6 compiler level if need be,
although it will probably be a lot more efficient if we can find a
way to do it within Parrot.
seems to confirm that detecting and reporting autothreaded
side-effects is entirely possible.
Let me attempt to clarify the discrepancy as I see it.
I'll take Damian's recent comment of: And if C is_prime($x) does
happen to autothread when you weren't expecting it to, then one of two
things will happen. Either the subroutine will be 'pure' in which case
there's no problem in autothreading it; or else the subroutine will have
side effects, in which case you'll get an explicit warning when the
autothreading occurs.
and my 19210 code of:
$x = 3|4;
$y = fun($x);
sub fun ($x) {
warn enter: fun($x)\n if $DEBUG;
$x + 1;
}
I hope it's clear that whether or not fun() has side effects is a
runtime decision, and can't realistically be determined at function call
time.
Now, let's assume that this falls under Damian's heading of happens to
autothread when I wasn't expecting it to.
If $DEBUG is off, no worries.
If $DEBUG is on, I expect my explicit warning, as promised.
What I am questioning is how perl decides when to give my warning. Does
perl inspect fun() to see if there are any side effect causing calls in
it? Or does it keep an internal note to itself saying I'm
autothreading. This class of functions is Bad., and then when it
encounters one of those functions, carp?
Now throw in a quote from Patrick (19212): As you've written things
above, Cfun is autothreaded (your option #3), and we'll see two
Cwarn output lines if $DEBUG is set.
Somehow, that's not the kind of explicit warning I was expecting from
Damian's comment.
As for the
precedence for x and ~
According to S03, ~ is tighter than x, while in Perl 5, . was looser than x. This can be surprising in things like @ x 75 ~ $zap Which has to be written as (@ x 75) ~ $zap in order to make sense. Was this intentional? What is the rationale? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Junction Values
Rod Adams wrote: Simply put, I want my junctions. Standard in Perl 6. I want my hyper operator superstrength arrays. Standard in Perl 6. I want them both at the same time. Standard in Perl 6. I never want to see implicit threading. Ever. If this is the only stumbling block, then it's easily solved. Instead of ruining junctions by imposing all kinds of complex and annoying hoops and hurdles (i.e. Cuse junctions and Cno junctions), we can just offer a Cno autothreading pragma that prevents any non-explicit junction from autothreading any operator or subroutine. Put it at the top of your code and you'll never get any implicit threading. Damian
Re: Lingering questions about Junctions.
Rod Adams [EMAIL PROTECTED] wrote:
- Can junctions be used as array/hash subscripts?
In an rvalue context, this makes sense, in that you can simply return a
junction of the deferences. But in an lvalue context, this gets dubious
for everything except all() junctions. Consider:
@x = 1..10;
@x[any(4,3)] = 7;
What does @x look like now?
@x[all(4,3,2)] = 7;
makes sense, as long as it means:
@x[4,3,2] »=« 7;
I don't want to even think about what:
@x[none(1,2)] = 7;
does.
The naive meaning of all of these would be::
any(map { @x[$_] = 7 } 4,3)
all(map { @x[$_] = 7 } 4,3,2)
one(map { @x[$_] = 7 } 1,2)
none(map { @x[$_] = 7 } 1,2)
But I'm not sure the naive interpretation is correct.
- Can you have non-scalar junctions?
As the discussions surrounding C .. demonstrated, it's not that hard
for someone to create a situation where a junction of lists might come
into existence. But let's consider something a step beyond.
%x = (a = 1, b = 2, c = 3) | (d = 4, e = 5, f = 6);
@y = %x.keys;
Does this explode, or does @y have something useful in it now?
Do junctive operators force scalar context on their arguments? If so,
we know what happens (you get a junction of arrayrefs); if not, I
suppose it's up for negotiation.
- What does it mean to sort a list of junctions?
@x = any(1,6), all(2,5), one(3,4);
@x = @x.sort;
Does sort() carp on junctions, or is it just one of the weird things you
have to live with if you're playing with junctions?
Good question. Spaceship and cmp aren't quite like the normal boolean
ops, unfortunately; I'm not quite sure what to do about that.
...actually...
Pretend for a moment that cmp is implemented exactly as:
multi sub infix:cmp (Any|Junction $lhs, Any|Junction $rhs) {
return -1 if $lhs lt $rhs;
return 0 if $lhs eq $rhs;
return 1 if $lhs gt $rhs;
}
Then things compare this way:
any(1,6) cmp all(2,5) = -1 (1 is less than both 2 and 5)
all(2,5) cmp any(1,6) = 1 (both 2 and 5 are greater than 1)
all(2,5) cmp one(3,4) = undef (no conditions match)
one(3,4) cmp all(2,5) = undef (no conditions match)
one(3,4) cmp any(1,6) = undef (no conditions match)
any(1,6) cmp one(3,4) = undef (no conditions match)
Happily, all of these are commutative (is this generally true?), and
the Cundefs would be treated as 0s. So this actually would work,
although it would sort in an...interesting...order.
--
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: precedence for x and ~
Juerd wrote: According to S03, ~ is tighter than x, while in Perl 5, . was looser than x. No. According to S03, *unary* ~ is tighter than x. *Binary* ~ is looser: symbolic unary ! + - ~ ? * ** +^ ~^ ?^ \ multiplicative * / % x xx + + + ~ ~ ~ additive+ - ~ +| +^ ~| ~^ Damian
Re: Junction Values
Damian Conway [EMAIL PROTECTED] wrote: Yes, it's a side-effect of the new default prohibition on junction assignments (though I'm still working hard to convince everyone that that prohibition cripples junctions and that having to use junctions before you can assign a basic Perl 6 scalar datatype to a variable is an abomination). Point of consideration: is accidentally autothreading over a junction any more dangerous than accidentally looping forever over an infinite lazy list? -- 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: precedence for x and ~
Damian Conway skribis 2005-02-20 11:28 (+1100): According to S03, ~ is tighter than x, while in Perl 5, . was looser than x. No. According to S03, *unary* ~ is tighter than x. *Binary* ~ is looser: symbolic unary ! + - ~ ? * ** +^ ~^ ?^ \ multiplicative * / % x xx + + + ~ ~ ~ additive+ - ~ +| +^ ~| ~^ Oh. I'm ashamed to admit I hadn't looked at the first column. Sorry. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Lingering questions about Junctions.
Brent 'Dax' Royal-Gordon wrote:
The naive meaning of all of these would be::
any(map { @x[$_] = 7 } 4,3)
all(map { @x[$_] = 7 } 4,3,2)
one(map { @x[$_] = 7 } 1,2)
none(map { @x[$_] = 7 } 1,2)
But I'm not sure the naive interpretation is correct.
A junction as an array index or hash key returns a junction of the
corresponding elements/entries. So:
@x[4|3] = 7
is the same as:
any(@x[4], @x[3]) = 7
But I've repeated stated my strong belief that junctions are scalar values,
*not* lvalues. So the result of that assignment ought to be:
Can't modify constant item in scalar assignment at demo.pl line 1
- Can you have non-scalar junctions?
Do junctive operators force scalar context on their arguments?
Yes.
If so, we know what happens (you get a junction of arrayrefs);
Yes.
if not, I suppose it's up for negotiation.
No. ;-)
- What does it mean to sort a list of junctions?
Brent's analysis is spot on, assuming that Ccmp on junctions works as he
envisaged. Personally, I think I'd implement Ccmp as:
multi sub infix:cmp (Any|Junction $lhs, Any|Junction $rhs) {
return -1 if $lhs lt $rhs;
return 1 if $lhs gt $rhs;
return 0
}
instead, but the differences are marginal: Brent's version treats junctions
that can be equal or greater than as being equal; mine favours the inequality
instead.
Ultimately, of course, a particular list of junctions may not be well-ordered
at all. For example:
sort 1|10, 5|6, 11|0
in which *any* permutation of the list is a plausible sort. So sorting
junctions isn't necessarily always meaningful.
Damian
Foreign modules in test scripts?
Hi! General testing question: Is it ok for a CPAN module to use other modules from CPAN only for the test scripts (e.g. Text::Diff)? First, I'm not sure about the usage policy. Maybe it's more common to write tests more low level. Second, I know there is a build_requires option in Build.PL, but does the CPAN(PLUS).pm know about that option and really only download and use those build_requires temporarily during module build/test or does it fully install them? Thanks, Steffen -- Steffen Schwigon [EMAIL PROTECTED] Dresden Perl Mongers http://dresden-pm.org/
Re: Junction Values
Damian Conway wrote:
Rod Adams wrote:
I never want to see implicit threading. Ever.
If this is the only stumbling block, then it's easily solved.
Instead of ruining junctions by imposing all kinds of complex and
annoying hoops and hurdles (i.e. Cuse junctions and Cno
junctions), we can just offer a Cno autothreading pragma that
prevents any non-explicit junction from autothreading any operator or
subroutine. Put it at the top of your code and you'll never get any
implicit threading.
Well, allow me to explain what I want in a little more detail, so I can
be sure I'm getting it.
I want to be able to feed a junction to functions that handle it, but I
also want to thread over ones that do not. But I do not want the
decision of which way to go to be made for me.
So, I want to be able to pass a raw junction into C == , because it
understands junctions, and will take care of the threading for me,
likely in a way that's much more efficient than my generalized »«
threading ever could. I do not consider this implicit threading. It's
passing the task of threading off to C == , which itself performs some
form of explicit threading.
But when I'm faced with some function that does not directly support
junctions, or one which does, but not in a way that I like, I want to be
able to thread my junction over it.
I do not think that what you said above is enough to accomplish this. I
believe what I need to separate your threading desires from mine is two
fold:
1) I need my »« modifier which forces explicit threading, which will not
normally be needed under use autothreading; conditions.
2) I need no autothreading; to alter the calling syntax to require »«
when threading is desired (or you can do a .values() and .junctiontype()
and roll your own if you really want to). But I can still pass junctions
around at will, withstanding normal type check requirements.
Then the only argument left is whether use autothreading or no
autothreading should be default. I would, of course, say no
autothreading;, and then turn back on the ability to store junctions.
IMO, no autothreading would provide enough cover for the unsuspecting,
removing the Bad Side Effects problems that spawned Larry's no junction
storage default. At the same time, junctions still have enormous power
via the »«. If people don't want to have to bother figuring out when to
thread for themselves, they can then turn on use autothreading, and
let perl attempt to figure it out for them.
Also, if no autothreading is default, the person new to Perl6 will
always have something to present to investigate to figure out what is
going on. In my code, it'll be the funny looking C »$junction«
things. In your code, it'll be the C use autothreading; at the top of
the page.
The only implementation problem I see is a potential for the »« to be
mis-parsed, since » and « seem to be serving several different roles
these days, but I don't think any of them conflict with this meaning. If
you want to rename »« to something else, I'm open to suggestions. Just
leave it fairly simple.
As for why implementation should be easy (or at least the delta between
your way and my way is easy):
- The functionality of »$junction« has to be defined anyways if
autothreading happens. It's just calling an already existent chunk of code.
- The logic of when to thread becomes:
given $situation {
when marked_with_»«()
{ thread }
when use_autothreading() damians_ouija_board()
{ thread }
default
{ don't thread }
}
And you've already defined how the ouija board works, everything else
should be boilerplate for the compiler/runtime to handle.
This sound reasonable enough?
-- Rod Adams
Re: Foreign modules in test scripts?
Is it ok for a CPAN module to use other modules from CPAN only for the test scripts (e.g. Text::Diff)? Yes. See http://phalanx.kwiki.org/index.cgi?StandardDotTFiles for examples of .t files that only run if a certain module is installed. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Foreign modules in test scripts?
On 2005-02-20, Steffen Schwigon [EMAIL PROTECTED] wrote: Hi! General testing question: Is it ok for a CPAN module to use other modules from CPAN only for the test scripts (e.g. Text::Diff)? First, I'm not sure about the usage policy. Maybe it's more common to write tests more low level. Second, I know there is a build_requires option in Build.PL, but does the CPAN(PLUS).pm know about that option and really only download and use those build_requires temporarily during module build/test or does it fully install them? Steffen, If you are considered about the extra module requirement for your users, one option is to distribute the testing modules you want in your own distribution, in a private 'inc' directory that doesn't get installed. Personally, I would probably just the list the module as a dependency, because that's easy for me. Mark -- http://mark.stosberg.com/
Re: TAP docs
http://www.petdance.com/random/tap.html Looks good. Thanks for working on this. You're welcome. Everyone: I still need more comments. Pete Krawczyk's the only one to provide complaints yet. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: TAP docs
Andy Lester wrote: http://www.petdance.com/random/tap.html Looks good. Thanks for working on this. You're welcome. Everyone: I still need more comments. Pete Krawczyk's the only one to provide complaints yet. The synopsis uses passive voice; . is called TAP. Id turn that around. TAP, the Test Anything Protocol, is . Everything else reads fine. Id like to see Description replaced by Remarks, but maybe that fish is already fried. xoxo, Andy
Re: TAP docs
The synopsis uses passive voice; . is called TAP. Id turn that around. TAP, the Test Anything Protocol, is . Fixed, thanks. Everything else reads fine. Id like to see Description replaced by Remarks, but maybe that fish is already fried. Battered, fried, slathered with tartar sauce and lemon, and eaten, along with cole slaw and corn fritters, by a hungry guy from Wisconsin. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: TAP docs
is skip supposed to be case sensitive? is it Skip, skip or SKIP ? TODO seems to be all caps. -jason gessner [EMAIL PROTECTED] On Feb 19, 2005, at 8:48 PM, Andy Lester wrote: The synopsis uses passive voice; . is called TAP. Id turn that around. TAP, the Test Anything Protocol, is . Fixed, thanks. Everything else reads fine. Id like to see Description replaced by Remarks, but maybe that fish is already fried. Battered, fried, slathered with tartar sauce and lemon, and eaten, along with cole slaw and corn fritters, by a hungry guy from Wisconsin. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: TAP docs
On Feb 19, 2005, at 8:53 PM, Jason Gessner wrote: is skip supposed to be case sensitive? is it Skip, skip or SKIP ? Both TODO and SKIP are case-insensitive. I've updated to make that explicit. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Lingering questions about Junctions.
On Sun, Feb 20, 2005 at 11:52:09AM +1100, Damian Conway wrote:
But I've repeated stated my strong belief that junctions are scalar values,
*not* lvalues. So the result of that assignment ought to be:
Can't modify constant item in scalar assignment at demo.pl line 1
Yay for sanity. :) It's how pugs implement it, too.
Brent's analysis is spot on, assuming that Ccmp on junctions works as he
envisaged. Personally, I think I'd implement Ccmp as:
multi sub infix:cmp (Any|Junction $lhs, Any|Junction $rhs) {
return -1 if $lhs lt $rhs;
return 1 if $lhs gt $rhs;
return 0
}
Hrm, so Junction.isa(Any) == False? I need to retype print(), say()
and other primitives, then.
Thanks,
/Autrijus/
pgpAdcg9pfTmK.pgp
Description: PGP signature
Re: TAP docs
On Feb 19, 2005, at 8:53 PM, Jason Gessner wrote: is skip supposed to be case sensitive? is it Skip, skip or SKIP ? Either way. I've updated it. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: TAP docs
Under TESTS AND PLANS: The plan, the first sentence of the third paragraph seems to fit better at the end of the previoius paragraph: This is a safeguard in case your test dies quietly in the middle of its run. It should be the first non-diagnostic line output by your test program. In certain instances, ... Under the test line, the emphasized concepts could reflect their necessity more easiliy: * ok or not ok (required) * Test number (recommended) * Description (recommended) * Directive (internal use or something) Thus ends any nitpicky things my brain clicked on. Andy Lester wrote: Get those comments in ASAP, please. -- Ian Langworth Project Guerrilla Northeastern University College of Computer and Information Science
