Re: [perl #34420] TODO suggestion: clean Parrot's ABI
Matt Diephouse [EMAIL PROTECTED] wrote: I've marked this ticket as such in RT, but I'd like to suggest that these TODO items become *requirements* for releases, and not desired goals. There's no real point in having a plan if you don't follow it, and this could provide some direction (always a good thing). Well, we can't enforce that it did happen in a reasonable time frame. If there are other important milestones reached, there will be a major release. leo
Re: [perl #34416] bug
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Leopold Toetsch via RT írta: Strange anyway. Folks reported that MinGW builds Parrot 0.1.2 ok. What can I say? Not for me. Not for me. Maybe they did not report their extra efforts to make it work? Yeah, seems so. Can MinGW users please come up with a patch to get things running out of the box, thanks. Other (new) errors: D:\extracted\parrot-0.1.2\languages\perl6perl perl6 -k examples\bnf.p6 languages/* is partially outdated, sorry. Márton leo
Carp in perl 6
Will there be a way to achieve what the Carp module does in perl 6? I
like the functionality it gives me, but think that it should be
builtin. Perhaps it could work like this:
caller.throw('an error');
Could this:
throw('an error');
just be another way to say:
$?BLOCK.throw('an error');
?
The mechanism Carp has for throwing exceptions from further down the
call stack seems a bit clunky. The above would mean we could do:
(caller Method, :skip(2)).throw('an error');
and possibly
# use a closure to search back through the call stack
throw_from({.package !~ $OUTER::?package}, 'an error');
Does this make any sense? Apologies if any of this has been discussed before.
Tom
Re: The S29 Functions Project
On Mon, Mar 14, 2005 at 01:07:45AM -0600, Rod Adams wrote: : It's been defined that Perl 6.0.0 does not dispatch on named parameters, : for better or for worse. If you don't like it, talk to Larry. That's a little bit of an overstatement. I've only said 6.0.0 doesn't *have* to support MMD on named parameters. I haven't said it mustn't. If the first implementation of Perl 6 figures out a decent way to handle it efficiently, I'm all for it, provided it doesn't unduly delay 6.0.0. At the time we made the decision, it wasn't clear to any of us in the room how to do it efficiently, but it might be obvious to someone else. Or maybe it's even okay to take a speed hit, as long as we don't punish the innocent with the guilty. And the long and the short of it is that it really depends on whether someone is willing to work on implementing it. We hope to get there someday, but it's not top priority for 6.0.0 unless someone decides to make it top priority. There are a number of things we might negotiate away to make it easier to get 6.0.0 out the door quicker, and this is only one of them. My only stipulation is that we trim things in such a way as to not make them impossible later. Which means, in the case of named MMD, that it is required that you use a colon to separate positional arguments from named arguments until named MMD is implemented, because we don't want the meaning of signatures to suddenly change. After named MMD is implemented we can remove the colon. There are really two different problems here--it's also an issue that you can use named notation on position args. and I don't have as good an idea for how to future proof against that changing its meaning, other than telling people not to do it yet. *If* all the long names for a particular short name use the same parameter naming scheme, then we could probably do some kind of global optimization to know that a particular named parameter always maps to a particular position. But that's a big if. It's certainly possible that the best way to future proof it is to simply do it right in the first place, even if it's slow to begin with. People can always write the positional form for speed when they need it. Larry
Re: [Pugs] Where to start with Modules
On Mon, Mar 14, 2005 at 10:11:45AM +, Matthew Campbell wrote: Hello All, Greetings! How does one go about this? Is there a list of priorities for modules that need porting to Perl6/Pugs? Should I just get going with a module that takes my fancy and try to get it to run under Pugs? Yes, that is the idea. Just pick something you like, rework it into Perl 6 syntax (or an approximation of it), and check in the Pugs source tree under modules/ directory; see Locale-KeyedText in there for an example. I'd also encourage you to hop on IRC (freenode.net #perl6) to talk a bit about what module(s) you are attempting to port over, so we can be more assistance when you run into Pugs's shortcomings. I'm also quite wary of treading on toes in doing this, do I need to get permission from the original developer of a module before attempting a port of it to Pugs? It helps to let the original author know what you're doing, and credit them accordingly, but I don't think you need permissions to start working. So, let me know when you'd like to receive the committer bit. :) Thanks, /Autrijus/ pgp9DzEuSlsYu.pgp Description: PGP signature
Re: [Pugs] Where to start with Modules
Thanks for the warm welcome Autrijus. I'll see you on #perl6 shortly then! Many Thanks Matt Campbell On Mon, 2005-03-14 at 18:23 +0800, Autrijus Tang wrote: On Mon, Mar 14, 2005 at 10:11:45AM +, Matthew Campbell wrote: Hello All, Greetings! How does one go about this? Is there a list of priorities for modules that need porting to Perl6/Pugs? Should I just get going with a module that takes my fancy and try to get it to run under Pugs? Yes, that is the idea. Just pick something you like, rework it into Perl 6 syntax (or an approximation of it), and check in the Pugs source tree under modules/ directory; see Locale-KeyedText in there for an example. I'd also encourage you to hop on IRC (freenode.net #perl6) to talk a bit about what module(s) you are attempting to port over, so we can be more assistance when you run into Pugs's shortcomings. I'm also quite wary of treading on toes in doing this, do I need to get permission from the original developer of a module before attempting a port of it to Pugs? It helps to let the original author know what you're doing, and credit them accordingly, but I don't think you need permissions to start working. So, let me know when you'd like to receive the committer bit. :) Thanks, /Autrijus/ -- Matthew Campbell [EMAIL PROTECTED]
[Pugs] Closing a file handle surprised the heck out of me
Given this Pugs program, t.p6:
my $fh = open(@ARGS[0]);
my @lines = =$fh;
$fh.close();
for @lines { print$_ }
running:
pugs t.p6 t.p6
produces no output. Move $fh.close() to after the for
loop and all is well. Is this a bug?
/-\
Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com
Re: Auto generated methods (was Re:The S29 Functions Project)
Rod Adams [EMAIL PROTECTED] wrote:
While that's a nice feature to have in general, I feel better about
going ahead and predefining that the builtins are already members of
Num, Str, Array, Hash for the shear performance and documentation values
of it.
That's exactly the plan, when it comes to Parrot. I'd like to have a lot
of function-like opcodes factored out into classes/*.pmc as methods.
Given:
pmclass P6Num extends Float { # the P6Num isa(Float)
...
}
pmclass Float {
METHOD cos() { ... } # return cosine of Float SELF
the method call in PIR can be written as:
d = x.cos() # normal method call
d = Float.cos(x) # class method, argument shifted down
d = P6Num.cos(x) # same
d = cos x # PIR opcode syntax [1]
cos d, x # PASM opcode syntax [1]
There'll be a table of such builtins with name, namespace, signature, so
that the current opcodes can be transparently replaced by methods.
I'm not quite sure if the same scheme should apply to:
op cos(out NUM, in NUM)
i.e. to opcodes that take natural types. But eventually such opcodes can
be recompiled inline with the help of the JIT subsystem, so that there's
no function call overhead at all. For now they probably remain as
opcodes.
The other problem with case 5 is that the long name would be cos, not
cosNum, since the first parameter is optional. So you'd have to
expand the search beyond just the long name, which can get expensive.
The method lookup will be done just once per call site, it shouldn't
really matter.
-- Rod Adams.
leo
[1] PMC versions aren't implemented
Re: for @list sub;
[EMAIL PROTECTED] wrote:
for [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] - $x { say $x };
should work. Are there any non-slashy versions of this?
I'd guess
for @a; @b; @c - $x { say $x;}
or
for (@a; @b; @c) - $x { say $x;}
(are parens mandatory here?)
Miro
Re: The S29 Functions Project
Rod Adams wrote:
And then internally dispatch on what is defined and undefined.
Why all that burden if Perl 6 is getting a strong type system,
that can do the sub selection and compile in dynamic dispatch if
needed?
I imagine:
multi sub cos( Num +$angle ) returns Num where { -1.0 = $_ = 1.0 }
class Radians is Num
{
}
class Degrees is Num
{
postfix:° ( Num $x ) { return $x * PI / 180 }
multi sub cos( Degrees +$angle ) returns Num where { -1.0 = $_ = 1.0 }
{
return cos( $angle * PI / 180 );
}
}
Note that cos(30°) calls cosNum while cosDegrees is used for
cases like:
Degrees $angle = 30.0;
if cos $angle 2.0 { print HaloO typechecker! }
And I still wonder if the ones without '°' on their keyboard could
directly call 'cosDegrees $angle'.
Regards,
--
TSa (Thomas Sandlaß)
Re: The S29 Functions Project
On Sun, Mar 13, 2005 at 06:03:20PM -0800, Larry Wall wrote: : One thing I've already done is make a list of Perl 5 functions I cannot : address until some future Apocalypse/Synopsis is generated on the topic. : By far the bulk of this list falls on S16. Partly because IPC is a mess, : and partly because I lumped all I/O in there. At some point we're going to have to make a decision how many of these automatically show up in ::* and how many have to be imported, and whether there's some subset of the latter that can be auto-imported on demand, and whether that's a good idea at all. It feels like a sop, and I'm not sure how many sops we can afford in Perl 6 before things get soggy. I ran into this problem while creating a mini-list of S29 functions (which Rod's work supercedes, I suspect, and I'm very glad he's taking this on). What are some guidelines we could use in deciding which functions are automatically in ::* ? Or is this just a case where we need to use past experience and best guesses as our guide? Pm
Re: [PROPOSAL] MMD: multi sub syntax
Leopold Toetsch [EMAIL PROTECTED] wrote: Syntax proposal: .sub foo @MULTI .invocant Integer a .invocant Float b .param pmc c ... Alternate syntax: .sub foo multi(Integer, Float) .param pmc a .param pmc b .param pmc c I'm now more inclined towards the second one: @MULTI smells too much like the pragmas @ANON or @LOAD and the second form is possibly simpler to extend if needed. The syntax plays also more nicely with plain methods: .sub bar method and eventually with .sub baz multi(String, int), method Comments? leo
Re: The S29 Functions Project
Patrick R. Michaud skribis 2005-03-14 8:10 (-0600): I ran into this problem while creating a mini-list of S29 functions (which Rod's work supercedes, I suspect, and I'm very glad he's taking this on). What are some guidelines we could use in deciding which functions are automatically in ::* ? Or is this just a case where we need to use past experience and best guesses as our guide? As much as I dislike it for CGI.pm, because it's slow and bloated, its idea of :standard is very useful. So my vote goes to putting almost nothing in ::, but having a simple pragma or module to import a certain group of standard functions. Without this pragma, methods should still work, IMO. use Standard; use standard; use v6 :standard; It would just do things like ::open ::= IO::open, where the target is the calling namespace only. -e should imply this. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Adding linear interpolation to an array
Juerd wrote: Larry Wall skribis 2005-03-11 8:45 (-0800): On Fri, Mar 11, 2005 at 03:58:13PM +0100, Thomas Sandlaß wrote: : Int @i; : Num @n = @i; # type error? I think the naive user is going to expect that to work, and I also suspect the naive user is right to expect it, because it makes sense. This may be one of those areas where we can successfully hide the high-falutin' theory from mere mortals simply because it maps onto what they expect already. It'd be great if this were a standard feature you can also use for your own objects. I fully agree with what Larry said about constant and copied parameter types. There we can easily go with covariant subtyping. OTOH the idea of a container providing a view of the values is a very high ideal. I think it is worthwhile to implement in the standard library for ubiquitous value types like Str, Num and Int. But I doubt that it can be achieved such that the Array class does respect any (future) value type! One idea that formally pushes the problem out of the Array class is to require a role ArrayEntry from every entry. But that would need very neat defaults to have a chance to be acceptable in the community---I hear people say: What? I need to implement that complicated role just to put my Blahh into an Array?. OK, would could go with independend types when the entry doesn't ArrayEntry, but then we might hear a slightly different complain: I can't mix my Blahhs with other objects in an array!. So I'm at a loss here. I believe $foo.Num in this case should return the Num-ified version of $foo. And maybe the int method numbers have is redundant, and should be spelled Int instead. Or, well, if this is the case, int should return an int (not Int) for consistency. Maybe +$foo even maps to $foo.Num, and ~$foo maps to $foo.Str and ?$foo maps to $foo.Bool? Hm, are charsets representable as classes/roles? my Str::utf8 $bar = ...; my Str::latin1 $foo = $bar; In my mindset that would read as my Str[utf8] $bar = ...; my Str[latin1] $foo = $bar; # type error? Or dynamic compatibility test? $bar = $foo could be allowed if the typechecker knew that latin1 subtypes utf8. More interesting is actually the typing of string constants: $foo = äöü; # Str[latin1] my Str[ASCII] $ascii = äöü; # type error? Hmm, since what is compile to you is runtime for the compiler it might by a normal store attempt that is then rejected by the object and caught by the compiler---cool. Is there also an unchecked store operation that can be used when the typechecker knows the assignment is (type-)correct? Regards, -- TSa (Thomas Sandlaß)
named subroutine parameters
I tried using named parameters (S06) and found this to work:
pugs sub formalize($text, +$case) { say $text } formalize('hello');
hello
bool::true
But unfortunately, this did not:
pugs sub formalize($text, +$case) { say $text } formalize('hello',
case='upper');
*** Error:
unexpected f
expecting term, ; or end of input
at interactive at line 1, column 44
I'm not sure where to fix this, but thought I should report it.
-kolibrie
Re: named subroutine parameters
Nathan Gray writes:
I tried using named parameters (S06) and found this to work:
pugs sub formalize($text, +$case) { say $text } formalize('hello');
hello
bool::true
But unfortunately, this did not:
pugs sub formalize($text, +$case) { say $text } formalize('hello',
case='upper');
*** Error:
unexpected f
expecting term, ; or end of input
at interactive at line 1, column 44
That's just because = doesn't autoquote its left side yet. Try:
sub formalize($text, +$case) { say $text } formalize('hello', 'case' =
'upper');
Luke
Re: named subroutine parameters
On Mon, Mar 14, 2005 at 10:15:25AM -0500, Nathan Gray wrote:
But unfortunately, this did not:
pugs sub formalize($text, +$case) { say $text } formalize('hello',
case='upper');
*** Error:
unexpected f
expecting term, ; or end of input
at interactive at line 1, column 44
Aye, bareword autoquoting needs some work. Jesse Vincent has
just committed a test case, and I'll look at it tomorrow.
Thanks for your report!
/Autrijus/
pgpXcYjanHwJk.pgp
Description: PGP signature
Re: Parrot 0.1.2 with MinGW32 (some experimets)
Leopold Toetsch wrote:
The test could include C 0? .
+$err_msg =~ s/\r//g;
Could you please provide one patch for items like above, thanks.
TortoiseCVS patch file attached.
S pozdravem Michal Jurosz
Index: imcc/t/imcpasm/opt1.t
===
RCS file: /cvs/public/parrot/imcc/t/imcpasm/opt1.t,v
retrieving revision 1.11
diff -u -r1.11 opt1.t
--- imcc/t/imcpasm/opt1.t 4 Mar 2005 17:49:01 - 1.11
+++ imcc/t/imcpasm/opt1.t 14 Mar 2005 15:10:07 -
@@ -622,18 +622,16 @@
##
SKIP: {
-skip(printf float output is unportable!, 1) if $^O eq 'MSWin32';
-pir_2_pasm_is('CODE', 'OUT', constant add big nums);
+pir_2_pasm_like('CODE', 'OUT', constant add big nums);
.sub _main
add N0, 10.0e20, 15.0e21
end
.end
CODE
-_main:
- set N0, 1.6e+22
- end
+/^_main:
+ set N0, 1\.6e\+0?22
+ end$/
OUT
-}
##
SKIP: {
Index: imcc/t/syn/file.t
===
RCS file: /cvs/public/parrot/imcc/t/syn/file.t,v
retrieving revision 1.26
diff -u -r1.26 file.t
--- imcc/t/syn/file.t 4 Mar 2005 17:49:04 - 1.26
+++ imcc/t/syn/file.t 14 Mar 2005 15:07:16 -
@@ -385,6 +385,7 @@
$enoent_err_msg = qx{$PARROT temp.imc}
}
+ $err_msg =~ s/\r//g if $^O =~ /^(MSWin32|msys)$/i;
is( $err_msg, OUT, including a non-existent file);
error:imcc:$enoent_err_msg
in file 'temp.imc' line 2
Re: The S29 Functions Project
Thomas Sandla writes:
Rod Adams wrote:
And then internally dispatch on what is defined and undefined.
Why all that burden if Perl 6 is getting a strong type system,
that can do the sub selection and compile in dynamic dispatch if
needed?
I imagine:
multi sub cos( Num +$angle ) returns Num where { -1.0 = $_ = 1.0 }
Lose the + on $angle. + indicates a named-only parameter. You want
this to be positional.
class Radians is Num
{
}
class Degrees is Num
{
postfix: ( Num $x ) { return $x * PI / 180 }
You probably shouldn't define this inside the Desgrees class. And you
should probably tell me whether it's a sub, a method, a macro, a
submethod, or a small puppy.
multi sub cos( Degrees +$angle ) returns Num where { -1.0 = $_ = 1.0 }
{
return cos( $angle * PI / 180 );
}
I think that's defining Degrees::cos to be a multi, to be differentiated
from other Degrees::cos'es. But that may be right.
I'd just make it a method.
method cos($angle:) returns Num where { -1 = $_ 1 } {
cos($angle * PI / 180);
}
}
Note that cos(30) calls cosNum while cosDegrees is used for
cases like:
Degrees $angle = 30.0;
if cos $angle 2.0 { print HaloO typechecker! }
That's certainly an interesting way to do it.
And I still wonder if the ones without '' on their keyboard could
directly call 'cosDegrees $angle'.
cosDegrees($angle) or Degrees::cos($angle), depending on whether you
defined it your way or my way. Uh oh, I thought we were going to make
single-invocant multis and methods the same everywhere...
Luke
Re: [Pugs] Closing a file handle surprised the heck out of me
On Mon, Mar 14, 2005 at 08:06:08AM -0800, Larry Wall wrote:
On Mon, Mar 14, 2005 at 10:58:00PM +1100, Andrew Savige wrote:
: my $fh = open(@ARGS[0]);
: my @lines = =$fh;
: $fh.close();
: for @lines { print$_ }
:
Hmm. It's probably a design bug. I'm wondering if we have to specify
that ordinary assignment not only copies logically but, in fact, always
does ** flattening (immediate flattening) like Perl 5
Except ** does not flatten recursively, so:
my $lines = [ =$fh ];
is still borked.
Do we want a *** nuke everything flat semantic device, if not the
operator? Or an eager context on the right hand side of =?
On the other hand, we can alternatively specify that closing a
file handle must force all thunks associated to it, i.e. in this
case fill @lines with real data. Pugs can do that just fine, but I
have no idea how parrot is to achieve that...
Thanks,
/Autrijus/
pgpc0yIr1u5Rf.pgp
Description: PGP signature
Re: [Pugs] Closing a file handle surprised the heck out of me
On Mon, Mar 14, 2005 at 10:58:00PM +1100, Andrew Savige wrote:
: Given this Pugs program, t.p6:
:
: my $fh = open(@ARGS[0]);
: my @lines = =$fh;
: $fh.close();
: for @lines { print$_ }
:
: running:
:
: pugs t.p6 t.p6
:
: produces no output. Move $fh.close() to after the for
: loop and all is well. Is this a bug?
Hmm. It's probably a design bug. I'm wondering if we have to specify
that ordinary assignment not only copies logically but, in fact, always
does ** flattening (immediate flattening) like Perl 5, and you *must*
use := binding to get lazy flattening. That is probably the course
of sanity. Since assignment is the primary means of violating FP's
no-side-effect idea, it makes sense that assignment is also what tries
its hardest to work around the issue when the user requests a side
effect like assignment. For example,
@foo = 1...;
would be an outright error, detectable at compile time in this case, while
@foo := 1...;
is perfectly fine. But my coffee isn't ready yet this morning,
so I reserve the right to be wronger than usual.
[Followups directed by default to p6l.]
Larry
Re: [Pugs] Closing a file handle surprised the heck out of me
On Mon, Mar 14, 2005 at 05:28:29PM +0100, Miroslav Silovic wrote: But it gets worse. my $lines = [ =$fh ]; seek($fh, 0); my $lines2 = [ =$fh ]; close $fh; $lines2 must somehow remember that seek has happened. That is fine because the three thunks are registered to the fh in evaluation order. What will be more fun is if they are all part of some other lazy lists, which may be accessed in some unpredictable order. That is why lazy languages typically use some sort of typechecking to avoid mixing computations with actions... :) Thanks, /Autrijus/ pgpo7uvHrvB8z.pgp Description: PGP signature
Re: [Pugs] Closing a file handle surprised the heck out of me
Autrijus Tang writes:
On Mon, Mar 14, 2005 at 08:06:08AM -0800, Larry Wall wrote:
On Mon, Mar 14, 2005 at 10:58:00PM +1100, Andrew Savige wrote:
: my $fh = open(@ARGS[0]);
: my @lines = =$fh;
: $fh.close();
: for @lines { print$_ }
:
Hmm. It's probably a design bug. I'm wondering if we have to specify
that ordinary assignment not only copies logically but, in fact, always
does ** flattening (immediate flattening) like Perl 5
Except ** does not flatten recursively, so:
my $lines = [ =$fh ];
is still borked.
Do we want a *** nuke everything flat semantic device, if not the
operator? Or an eager context on the right hand side of =?
On the other hand, we can alternatively specify that closing a
file handle must force all thunks associated to it, i.e. in this
case fill @lines with real data. Pugs can do that just fine, but I
have no idea how parrot is to achieve that...
Perhaps lists by assignment are COW lazy. So they behave just like
ordinary COW objects, except they can be lazy at the end:
my @a = gather {
for 1... {
say;
take;
}
};
@a[10]; # says 1 2 3 ... 10
@a[5] = 42;
@a[20]; # nothing printed
I wonder if that's DingTRT though...
Luke
Thanks,
/Autrijus/
Re: [PROPOSAL] MMD: multi sub syntax
Leopold Toetsch [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] wrote: Syntax proposal: .sub foo @MULTI .invocant Integer a .invocant Float b .param pmc c ... Alternate syntax: .sub foo multi(Integer, Float) .param pmc a .param pmc b .param pmc c I may well be missing something, but it seems to be that we're declaring the first two parameter's types twice (pmc and Integer, pmc and Float), which I'm not sure is a good idea. Of course, there is... .sub foo multi(Integer a, Float b) .param pmc c Though I don't know how I feel about that either (or rather, I'm not sure how other folks will). Thanks, Jonathan
Re: The S29 Functions Project
On Mon, Mar 14, 2005 at 08:10:15AM -0600, Patrick R. Michaud wrote: : I ran into this problem while creating a mini-list of S29 functions : (which Rod's work supercedes, I suspect, and I'm very glad he's taking : this on). What are some guidelines we could use in deciding : which functions are automatically in ::* ? Or is this just a case : where we need to use past experience and best guesses as our guide? You have the irritating habit of asking good questions I don't have an easy answer for. Please don't stop. Thinking about it a bit, it really comes down to an issue of pragmatics in the linguistic sense. The question is, if you glance at any particular function foo(), does it immediately pop into your head that this is probably a cultural meme, or does it sort of lazily evaluate to the possibility of a cultural meme. So by this main criterion, abs() is almost certainly the absolute value meme (unless you're at the gym), while dump() doesn't really mean much to people because it's too heavily overloaded. There are going to be several secondary criteria that modify the main criterion: * Sometimes we want to force a particular meme into the foreground. By the main criterion lock() isn't specific enough to be a keyword, but we can choose to force it to mean one thing. The fact that all such functions are the equivalent of Perl 5's 3rd-class keywords makes this easier, since the user can still override the meaning of lock() if they want to. (Or abs() for that matter.) * Another confounding factor is that memes tend to come in bundles, and you'd kind of like to keep the bundles together. So my earlier question really amounted to whether POSIX was really a valid bundle of memes. (Probably not.) On the other hand, the trig functions might well be a valid bundle, and we might want to keep them all together either in * or Trig. * On the other hand, maybe some meme bundles deserve to be split up into two bundles by the main criterion, with one bundle going into * and the other into Trig (or whatever). Arguably sin and cos are instantly recognizable, but the lesser known trig functions are more debatable. But these are all fuzzy boundaries, and people will see the boundaries in different places. * We're really talking about a three-way distinction here. In the middle we have the functions that are imported by default when you say use Trig rather than use Trig :all. There are some folks who would argue well-formed modules should never export any names by default, so that use Trig *only* makes sure that the Trig module is available, and you'd have to say use Trig :default or some such to get the default set. But that's just giving the middle memes a different collective name. * We do in fact have mechanisms for overriding any core feature, and we don't want Perl to turn into a language where you have to import a bunch of essential stuff at the top, it basically argues that in case of doubt, we should throw it into the core. We'll also have MMD to sort things out, so as long as things are well-typed, we shouldn't fall into a PHP function-name hell. * Backward compatibility with Perl 5 decisions certainly influences what Perl 5 programmers will expect, but not necessarily newcomers to Perl. We'll have to decide how to balance those where Perl 5 got it a little wrong. The upshot of all this is that, as you suspected, this is something we'll just have to work out as a community. What we can do right now is tell people not to be surprised when we move things around, and that we'll feel free to move things around until 6.0.0 is about to go golden. But maybe we could try to set some slushiness milestones on the road to hell freezing over... Larry
Re: The S29 Functions Project
Luke Palmer wrote: cosDegrees($angle) or Degrees::cos($angle), depending on whether you defined it your way or my way. Uh oh, I thought we were going to make single-invocant multis and methods the same everywhere... Sorry for messing up the syntax in my example code. What I wanted to achieve is to get a multi cos that has the same namespace as the rest of the standard functions. BTW, I'm unsure how packages, modules and classes roles interact with the type system and MMD. In particualr what can be put into the type slot of declarations/definitions: my SomeThing $x; Can SomeThing be a package? Ans if yes, what does it mean? -- TSa (Thomas Sandla)
[perl #34430] [PATCH] MRO breaks Tcl
# New Ticket Created by Will Coleda
# Please include the string: [perl #34430]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34430
Can I say again that I think it's cheating that python has tests directly in
t/ , so leo notices breakage there sooner? =-)
Attached is a patch that allows (cd languages/tcl make test) to work
again. Looks like an unguarded access in MRO. Didn't self apply so Leo could
poke at it, in case the tcl pmcs are exploiting a hole in pmc2c2.pl.
Index: src/pmc.c
===
RCS file: /cvs/public/parrot/src/pmc.c,v
retrieving revision 1.97
diff -b -u -r1.97 pmc.c
--- src/pmc.c 10 Mar 2005 16:41:28 - 1.97
+++ src/pmc.c 14 Mar 2005 17:24:42 -
@@ -470,10 +470,11 @@
parent_type = pmc_type(interpreter, class_name);
if (!parent_type) /* abstract classes don't have a vtable */
break;
+if (!Parrot_base_vtables[parent_type]) /* Makes Tcl Work Again */
+break;
class = Parrot_base_vtables[parent_type]-class;
-if (!class) {
+if (!class)
class = create_class_pmc(interpreter, parent_type);
-}
VTABLE_push_pmc(interpreter, mro, class);
if (pos = total)
break;
Re: [Pugs] Closing a file handle surprised the heck out of me
On Tue, Mar 15, 2005 at 12:21:19AM +0800, Autrijus Tang wrote:
: On Mon, Mar 14, 2005 at 08:06:08AM -0800, Larry Wall wrote:
: On Mon, Mar 14, 2005 at 10:58:00PM +1100, Andrew Savige wrote:
: : my $fh = open(@ARGS[0]);
: : my @lines = =$fh;
: : $fh.close();
: : for @lines { print$_ }
: :
:
: Hmm. It's probably a design bug. I'm wondering if we have to specify
: that ordinary assignment not only copies logically but, in fact, always
: does ** flattening (immediate flattening) like Perl 5
:
: Except ** does not flatten recursively, so:
:
: my $lines = [ =$fh ];
:
: is still borked.
:
: Do we want a *** nuke everything flat semantic device, if not the
: operator? Or an eager context on the right hand side of =?
I don't like ***. As with in rules, at some point you bail out
and go alphabetic. So you might write that as
my $lines = [ $fh.slurp ]
That doesn't work so well for
my $lines = [ .slurp ]
though...
: On the other hand, we can alternatively specify that closing a
: file handle must force all thunks associated to it, i.e. in this
: case fill @lines with real data. Pugs can do that just fine, but I
: have no idea how parrot is to achieve that...
I think we have to recognize that close() is a very non-FP-ish
operation. It's essentially a kind of database commit, so that you
or someone else can reliable open the file and know what's going to
be there. (We've essentally got the same problem writing lazy lists
to a file.) So I guess the question is whether we can intuit the
intent of the programmer with the close. There's the I'm tired of
this filehande so close it logically but don't flush anything vs the
close this Right Now and flush everything Right Now and maybe even
fsync to disk to make jolly sure we're in a known state.
Since the earlier sentiment can be handled merely by letting the handle
go out of scope and get garbage collected someday, we probably have
to treat close as the more violent intention. So if we can autoflush
output, we can also autofill input, but probably only for iterators
that were used in list context. An iterator in scalar context expects
the close to truncate the rest of the input. A Perl 5 programmer
expects that
$foo = $input;
will stop working if you close $input, but will expect
@foo = $input;
to produce all the values as if it had been eagerly flattened, because
that's what list context means in Perl 5. In Perl 6, list context
merely means the promise of flattening, but in the case of
$foo = [ =$fh ];
it means we have to fulfill the promise when $fh is closed. It really is
a kind of COW situation, where close is construed as a write to the
effective length of the input. The situation doesn't apply to
$foo = [ 1... ];
because by default there's no handle to close on the infinite sequence.
Just as well, I suppose...
If we can capture the COW semantics, then we wouldn't necessarily have
to fix assignment, but it might be a good idea in any case to define
@foo = (bar())
as
@foo := [**bar()]
just to force programmers to make their eager/lazy intent clearer by
distinguishing = from :=. Then the fact that = also does a top-level
copy just sort of naturally falls out.
Larry
Re: [Pugs] Closing a file handle surprised the heck out of me
On Mon, Mar 14, 2005 at 09:52:06AM -0700, Luke Palmer wrote:
: Perhaps lists by assignment are COW lazy. So they behave just like
: ordinary COW objects, except they can be lazy at the end:
:
: my @a = gather {
: for 1... {
: say;
: take;
: }
: };
: @a[10]; # says 1 2 3 ... 10
: @a[5] = 42;
: @a[20]; # nothing printed
:
: I wonder if that's DingTRT though...
My feeling is that it prints
11 12 13 14 15 16 17 18 19 20
and then if you say [EMAIL PROTECTED] you'll get:
1 2 3 4 5 42 7 8 9 10 11 12 13 14 15 16 17 18 19 20
That is, once a value is generated, it's just an ordinary array value.
The generator is just attached at the end, and doesn't care what you
do with existing values.
On the other hand, maybe you have to use my @a := if we make = eager.
Larry
Re: [Pugs] Closing a file handle surprised the heck out of me
The Principle of Maximum Differentiation of Similar Constructs also tends to argue for eager =. Plus there's the fact that it's the sort of restriction we can relax if we figure out how, but it would be hard to impose if people started to rely on lazy assignment and then we decided it was a bad idea. Larry
Re: The S29 Functions Project
On Mon, Mar 14, 2005 at 06:00:11PM +0100, Thomas Sandlaß wrote: : BTW, I'm unsure how packages, modules and classes roles interact with : the type system and MMD. In particualr what can be put into the type slot : of declarations/definitions: : : my SomeThing $x; : : Can SomeThing be a package? Ans if yes, what does it mean? Maybe it means that $x contains a Perl 5 style object, if not an actual Perl 5 object. Larry
Re: [Pugs] Closing a file handle surprised the heck out of me
Larry Wall wrote: The Principle of Maximum Differentiation of Similar Constructs also tends to argue for eager =. Plus there's the fact that it's the sort of restriction we can relax if we figure out how, but it would be hard to impose if people started to rely on lazy assignment and then we decided it was a bad idea. Yep. Does that put =, := etc into a category of operators that are hard to (usefully) overload in classes? I mean the eager = doesn't look like letting the left and right hand side have much to do or decide in the process---other than provide and swallow the value or complain about not beeing able to due so. Regards, -- TSa (Thomas Sandlaß)
Re: [Pugs] Closing a file handle surprised the heck out of me
: Given this Pugs program, t.p6:
:
: my $fh = open(@ARGS[0]);
: my @lines = =$fh;
: $fh.close();
: for @lines { print$_ }
:
: running:
:
: pugs t.p6 t.p6
:
: produces no output. Move $fh.close() to after the for
: loop and all is well. Is this a bug?
I wonder if IO::All could provide some inspiration here? Not so much for
solving this specific bug - but making easy IO things easy and making file
handle funkiness hard?
Just a meme for the pool ...
Nige
Re: The S29 Functions Project
Larry Wall wrote: On Mon, Mar 14, 2005 at 08:10:15AM -0600, Patrick R. Michaud wrote: : I ran into this problem while creating a mini-list of S29 functions : (which Rod's work supercedes, I suspect, and I'm very glad he's taking : this on). What are some guidelines we could use in deciding : which functions are automatically in ::* ? Or is this just a case : where we need to use past experience and best guesses as our guide? [snip] The upshot of all this is that, as you suspected, this is something we'll just have to work out as a community. What we can do right now is tell people not to be surprised when we move things around, and that we'll feel free to move things around until 6.0.0 is about to go golden. But maybe we could try to set some slushiness milestones on the road to hell freezing over... What I'm thinking of doing is creating a soft rule of: You can't declare a function into ::*. You have to create it elsewhere, and bind it in. Therefore, as I go through S29, I'll assign all functions to some module. I'll be using the P5/CPAN hierarchy as a strong guideline. We can then discuss what gets bound into ::*, and when, at some later point in time. -- Rod Adams
Re: The S29 Functions Project
On Mon, Mar 14, 2005 at 12:16:13PM -0600, Rod Adams wrote: : Therefore, as I go through S29, I'll assign all functions to some : module. I'll be using the P5/CPAN hierarchy as a strong guideline. : : We can then discuss what gets bound into ::*, and when, at some later : point in time. That's an excellent idea. We can encourage people to write the qualified name if they want to be future-proof past the 6.0.0 boundary. Larry
Re: [Pugs] Closing a file handle surprised the heck out of me
On Mon, Mar 14, 2005 at 07:04:12PM +0100, Thomas Sandlaß wrote: : Yep. Does that put =, := etc into a category of operators that : are hard to (usefully) overload in classes? I mean the eager = : doesn't look like letting the left and right hand side have much : to do or decide in the process---other than provide and swallow : the value or complain about not beeing able to due so. I'd hazard a guess that it constrains the allowable signatures for such an operator. Larry
Re: [Pugs] Closing a file handle surprised the heck out of me
Larry Wall writes: The Principle of Maximum Differentiation of Similar Constructs also tends to argue for eager =. Plus there's the fact that it's the sort of restriction we can relax if we figure out how, but it would be hard to impose if people started to rely on lazy assignment and then we decided it was a bad idea. I use = as my no-thinking, catch-all assignment. I'd really like lazy lists to be pervasive enough that I don't have to think about them any differently than I think about any other kind of list. Making = lazy and making = eager both have the same disadvantage, but in different places. If we make = lazy, then people who don't think about lazy lists will use it in modules and whatnot, and it will (at best) die when they try to write them to files or print them or do other things that infinite lists can't really do. On the other hand, if we make = eager, then people who write modules who don't think about lazy lists will be denying the users of their module lazy access when it would be perfectly acceptable. And I can't decide which is worse. But I think the latter is worse. The former puts the decision of how to use lazy lists on the module user, where the latter puts the decision on the module author. Just like Cuse fatal, we want the user to call the shots, because they're the one who knows how the module fits with the rest of the program. I think that as long as lazy lists die when you do things that you can't do to them to them (sic.), and they die with a nice error message that says where they were created, that lazy assignment should be fine. We who write perl6 will have to work a little harder, but we know that from Perl's philosophy anyway. And by harder, I mean to make the close example work; to make a filehandle understand that it has lazy lists attached to it and to flush itself when necessary. Of course, there are dragons hiding in that too. If you tie a lazy list to a filehandle and only ever plan to use its first two elements, and you close the filehandle while the list is still in scope, then a 100 megabyte file will give you trouble you never asked for. Maybe it's best to let the array decide. There are some lazy lists which are healthy to throw around recklessly, like C1 There are others, like C , which have nasty ordering dependencies, and are best kept at the expression level and not assigned (only bound... but your ordering dependencies can bite you there, too). If arrays are lazy by default, that basically mean they're behaving as tied values (because you can do anything while you generate), and that we might as well outright remove the Cis tied optimization restriction. And then we should remove it for scalars and hashes too, and (please) let it propogate through assignment if it wants to. I've always wondered how much we could actually optimize if we know things aren't tied anyway Junctions already do tie-like things without being tied (even though it's the *value* which is doing those things). Whew... stop for a breath here... /ramble This is a hard problem. And it touches on a lot of my active concerns. For the time being, I'll buy your argument that it's easy to relax assigment to lazy, but hard to harden it up to eager. Luke
Re: Adding linear interpolation to an array
On Mon, Mar 14, 2005 at 04:15:35PM +0100, Thomas Sandlaß wrote: : Hmm, since what is compile to you is runtime for the compiler : it might by a normal store attempt that is then rejected by the object : and caught by the compiler---cool. Is there also an unchecked store : operation that can be used when the typechecker knows the assignment : is (type-)correct? I think any routine with a fancy signature with potential run-time checking also has an entry that assumes the checking was done by the caller or the compiler. The trick will be to discourage people from bypassing the necessary type checking when they think they know better but don't really. Larry
Re: [PROPOSAL] MMD: multi sub syntax
On Mon, 2005-03-14 at 14:02 +0100, Leopold Toetsch wrote: Leopold Toetsch [EMAIL PROTECTED] wrote: Syntax proposal: .sub foo @MULTI .invocant Integer a .invocant Float b .param pmc c ... Alternate syntax: .sub foo multi(Integer, Float) .param pmc a .param pmc b .param pmc c I'm now more inclined towards the second one: @MULTI smells too much like the pragmas @ANON or @LOAD and the second form is possibly simpler to extend if needed. The syntax plays also more nicely with plain methods: .sub bar method and eventually with .sub baz multi(String, int), method Comments? I like the first one in that it has the names and the types of the parameters in one place. Does it need the @MULTI attribute if there are some parameters declared with .invocant? -- c
Namespaces
The archives have tons of articels regarding namespaces, mostly HLL policies and such, but little about Parrot semantics. I've started a new test file t/pmc/namespace.t that summarizes some of the current possibilities of namespace manipulation with Parrot. Please have a look at the supported syntax constructs. Are these sufficient for HLL writers? leo PS more tests welcome
Re: [perl #34430] [PATCH] MRO breaks Tcl
Will Coleda [EMAIL PROTECTED] wrote: Can I say again that I think it's cheating that python has tests directly in t/ , so leo notices breakage there sooner? =-) Feel free to cheat and append tcl tests to make test. Attached is a patch that allows (cd languages/tcl make test) to work again. Looks like an unguarded access in MRO. Didn't self apply so Leo could poke at it, in case the tcl pmcs are exploiting a hole in pmc2c2.pl. Hhm. Why does that PMC type (which one) not have a vtable? leo
Re: Auto generated methods (was Re:The S29 Functions Project)
Leopold Toetsch wrote:
Rod Adams [EMAIL PROTECTED] wrote:
While that's a nice feature to have in general, I feel better about
going ahead and predefining that the builtins are already members of
Num, Str, Array, Hash for the shear performance and documentation values
of it.
That's exactly the plan, when it comes to Parrot. I'd like to have a lot
of function-like opcodes factored out into classes/*.pmc as methods.
Given:
pmclass P6Num extends Float { # the P6Num isa(Float)
...
}
pmclass Float {
METHOD cos() { ... } # return cosine of Float SELF
the method call in PIR can be written as:
d = x.cos() # normal method call
d = Float.cos(x) # class method, argument shifted down
d = P6Num.cos(x) # same
d = cos x # PIR opcode syntax [1]
cos d, x # PASM opcode syntax [1]
There'll be a table of such builtins with name, namespace, signature, so
that the current opcodes can be transparently replaced by methods.
This looks like it's taking
multi method Num::cos (Num|Str +$base) returns Num
and generating
multi sub cos (Num $x, Num|Str +$base) returns Num
Which I believe is the opposite direction of what Larry was doing, and
doesn't seem to address the $_ issue.
Part of me wants get rid of all the C ?$x = $CALLER::_ 's and tell
people if they want to use $_, they need to say C .cos . Then the
other part of me turns around and beats up the part that thought that.
The other issue in my head is
multi sub split (Rule $r, Str $s, Num +$limit) returns List of Str
I would want the following to be implied from it:
multi method Rule::split (Str $s, Num +$limit) returns List of Str
multi method Str::split (Rule $r, Num +$limit) returns List of Str
So what I'm thinking of for a solution is to have a
my Foo $bar;
$bar.baz;
call that gets past all the Foo AUTOMETHs is to then scan all the subs
in scope named baz, find the one with a required parameter of type most
compatible to Foo, ties being broken by appearing earlier on the
parameter list, and use that parameter as the invocant.
-- Rod Adams
[Pugs] %hash{nosuch} not undef
Is the second of these two tests supposed to fail?
my %hash = ( bar = 'baz', quux = 'quuz' );
ok(defined(%hash{bar}), hash subscript);
ok(!defined(%hash{bargho}), non-existent hash subscript) or
diag(expected undef; got { %hash{'bagho'} });
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
bad file line breaks (was Re: Call for p6ification: Algorithm::Dependency)
At 1:09 AM +1100 3/14/05, Adam Kennedy wrote: At the request of Autrijus, I've just checked the P5 current version of Algorithm::Dependency into pugs, and now we need volunteers to P6ify it. As a reminder to those of you for whom it isn't common sense, the standard way to distribute code on the internet involves having all of your files encoded using UNIX line-breaks (not DOS/Windows, not MAC OS 9). All of the Algorithm::Dependency files had DOS linebreaks, and my first commit of them mainly involved changing them to UNIX linebreaks. They should have been UNIX at the initial checkin of the Perl 5 code. I made very few other changes in this commit (just #! and etc), and I made them prior to discovering the linebreak problems. Since any further changes will be a separate commit, it will be easier to see what changes were made between versions. -- Darren Duncan
Re: [perl #34420] TODO suggestion: clean Parrot's ABI
Matt Diephouse wrote: There's no real point in having a plan if you don't follow it, That sounds a bit naive. The benefit of a plan is primarily in the act of making it (it forces you to think about what you want to do). The secondary benefit comes when you track how actual progress deviates from the plan: this lets you think about how/why your plan wasn't accurate. Following a plan gives very little benefit. If the plan is accurate, then people will naturally follow it, without needing to be told. They may follow priorities (which may derived from the act of planning), but that's a subtly different thing. Dave.
[RFC] Test::CPANTS
I have an itch. It just came to me while surfing PerlMonks and CPAN. I noticed the new Test::Strict module which keeps me honest by making sure I always 'use strict'. I'll be adding that to my modules this evening. [I wish is did use warnings too]. My second thought was wouldn't it be cool if there was something like Test::CPANTS in which I could always verify that my modules were at least at a kwalittee rating of x or more during make test? Any thoughts? I've looked at the CPANTS modules and it looks possible, and I'm willing to take a crack at it it anyone thinks it will be of some use. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: [RFC] Test::CPANTS
On Mon, Mar 14, 2005 at 04:05:36PM -0500, Christopher H. Laco wrote: I have an itch. It just came to me while surfing PerlMonks and CPAN. I noticed the new Test::Strict module which keeps me honest by making sure I always 'use strict'. I'll be adding that to my modules this evening. [I wish is did use warnings too]. Acme::use::strict::with::pride does warnings too :-) http://search.cpan.org/dist/Acme-use-strict-with-pride/pride.pm I'm not suggesting that you use it in production code though. Partly because it is an Acme module, but mainly because it stops Exporter working. Then again, OO purists might consider that a feature. Nicholas Clark
Re: [RFC] Test::CPANTS
Christopher H. Laco wrote: I have an itch. It just came to me while surfing PerlMonks and CPAN. I noticed the new Test::Strict module which keeps me honest by making sure I always 'use strict'. I'll be adding that to my modules this evening. [I wish is did use warnings too]. My second thought was wouldn't it be cool if there was something like Test::CPANTS in which I could always verify that my modules were at least at a kwalittee rating of x or more during make test? Any thoughts? I've looked at the CPANTS modules and it looks possible, and I'm willing to take a crack at it it anyone thinks it will be of some use. I don't know if that answer your needs but Test::Distribution already performs several kwalitee tests on the modules and other files of a distribution. http://search.cpan.org/dist/Test-Distribution/ Sébastien Aperghis-Tramoni -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ] Close the world, txEn eht nepO
Re: [RFC] Test::CPANTS
Sébastien Aperghis-Tramoni wrote: Christopher H. Laco wrote: I don't know if that answer your needs but Test::Distribution already performs several kwalitee tests on the modules and other files of a distribution. http://search.cpan.org/dist/Test-Distribution/ Sébastien Aperghis-Tramoni -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ] Close the world, txEn eht nepO Yeah, I had looked at that, but there are two things keeping me from using Test::Distribution: prereq Checks whether all use()d modules that aren't in the perl core are also mentioned in Makefile.PL's PREREQ_PM. I have a few modules that are optional; not declared in PREREQ_PM. Probably not a problem since they're evaled in. However, there are plenty of cases where I'm usin-ing one module that is a child of another parent, and the parent is in PRERQ, but the child wouldn't be. versions Checks that all packages define $VERSION strings. Onlt the main module package has a version; not all of the other packages. Maybe that's a bad thing? -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: [RFC] Test::CPANTS
Christopher H. Laco wrote: Sébastien Aperghis-Tramoni wrote: Christopher H. Laco wrote: I don't know if that answer your needs but Test::Distribution already performs several kwalitee tests on the modules and other files of a distribution. http://search.cpan.org/dist/Test-Distribution/ Sébastien Aperghis-Tramoni -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ] Close the world, txEn eht nepO Yeah, I had looked at that, but there are two things keeping me from using Test::Distribution: prereq Checks whether all use()d modules that aren't in the perl core are also mentioned in Makefile.PL's PREREQ_PM. I have a few modules that are optional; not declared in PREREQ_PM. Probably not a problem since they're evaled in. However, there are plenty of cases where I'm usin-ing one module that is a child of another parent, and the parent is in PRERQ, but the child wouldn't be. versions Checks that all packages define $VERSION strings. Onlt the main module package has a version; not all of the other packages. Maybe that's a bad thing? -=Chris And I don't gain a ton by only running 4/6 tests via only/not. smime.p7s Description: S/MIME Cryptographic Signature
Re: [perl #34420] TODO suggestion: clean Parrot's ABI
Dave Whipp via RT wrote: Matt Diephouse wrote: There's no real point in having a plan if you don't follow it, That sounds a bit naive. The benefit of a plan is primarily in the act of making it (it forces you to think about what you want to do). The secondary benefit comes when you track how actual progress deviates from the plan: this lets you think about how/why your plan wasn't accurate. Following a plan gives very little benefit. If the plan is accurate, then people will naturally follow it, without needing to be told. They may follow priorities (which may derived from the act of planning), but that's a subtly different thing. Dave. It's nice to see so many professional project managers signing up :-) -- Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this special biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen
[Pugs] undef.t
Attached is a first shot at tests for undef. This mostly ports the p5 tests where appropriate, though there is some new behavior. Some of it is waiting for rules and subs. There are a few failures in aggregates, e.g. undef @ary doesn't. Not sure I'm not missing something in the spec, though. -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: [RFC] Test::CPANTS
Christopher H. Laco wrote: Yeah, I had looked at that, but there are two things keeping me from using Test::Distribution: prereq Checks whether all use()d modules that aren't in the perl core are also mentioned in Makefile.PL's PREREQ_PM. I have a few modules that are optional; not declared in PREREQ_PM. Probably not a problem since they're evaled in. However, there are plenty of cases where I'm usin-ing one module that is a child of another parent, and the parent is in PRERQ, but the child wouldn't be. Test::Prereq ? I don't know if it handle all those cases though. versions Checks that all packages define $VERSION strings. Onlt the main module package has a version; not all of the other packages. Maybe that's a bad thing? That's a quite classic troll starter I think :-) Sébastien Aperghis-Tramoni -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ] Close the world, txEn eht nepO
[RFC] A more extensible/flexible POD (ROUGH-DRAFT)
Gang,
My proposal is for an extensible version of POD. Basically what XML is
to HTML/SGML, this will be for POD. This is a very very very rough
draft. I am submitting it in hopes of getting some basic feedback on
the idea to see if I should carry it any further or not. So please if
you have an opinion on this, either positive or negative, please chime
in and let me know.
If nothing more I am hoping this might bring the debate over the future
of POD (or Kwid) out of the more transient #perl6 and into the more
concrete world of email as I think there are currently too many
opinions and not enough dialog.
- Stevan
(p.s. - I apologize in advance if my ideas sound a little jumbled
together, remember,.. this is very very rough)
INTRODUCTION
There has been a lot of chatter on #perl6 about POD vs. Kwid and how
best to do this and that, etc. etc. etc. and so on and so forth. It
seems to me that we will never be able to create a documentation format
which will make everyone happy in all cases.
But my question really is, why should we?
Just as with HTML, at some point the formatting information overtakes
the data being displayed and the data no longer has any real meaning in
relation to the markup around it. IMO, POD (and Kwid) are both too
formatting centric, and while much simpler than HTML, suffer on some
level from the same problem.
The early promise of XML was that data and formatting would be
separate. That you put the data in the XML and gave it meaning and
context, then you put the formatting into your stylesheet (XSL or CSS).
Of course we all know XML (and XSL and all its variants) have now
become a big ugly monster, but that does not mean those early ideas
were not good ones.
I am of the opinion that while documentation is traditionally a very
static thing, it should and need not be so. In fact, I feel that
documentation should be as much meta-data as it is prose. I think the
extensible POD-like format I will describe below could possibly bridge
that gap between meta-data and static documentation.
THE BASIC IDEA
When grossly simplified SGML, HTML XML all share a base set of
similar constructs. They are made up of Containers, Elements and
Entities. An Element is basically a tag with no embedded tags (BR or
HR are the most common in HTML). A Container is a tag which itself
has Elements within it. An Entity is just a special chunk of text
embedded within other text (in *ML they begin with '' and end with
';'). (NOTE: I am making the assumption that text is itself an implicit
element)
If we port this idea to a POD like syntax, it might look something like
this:
=container
=element: some string with Eentities in it
Some plain text contained Iwithin this container.
=end
The Container is begun the normal POD-ish way, and easily delimited
by an '=end' marker. An Element is very POD-ish as well, but is
identified by a trailing ':' after it's name. And entities take the
common POD form of an uppercase character and something inside of two
angle brackets.
NOTE: Anything following an Element or a Container declaration on the
same line can be thought of as being part of that element/container.
This is somewhat like how *ML tags have attributes.
A more complex example might be something like this:
=module
=project: Pugs
=name: Perl6::Pugs
=version: 6.0.11
=author
=name: Autrijus Tang
=email: [EMAIL PROTECTED]
=end
=description: Pugs - Perl6 Users Golfing System.
=dependencies
GHC 6.2 or above
=end
=copyright: Copyright 2005 Autrijus Tang.
=url: Lhttp://www.autrijus.org
=license
This library is free software; you can redistribute it
and/or modify it under the same terms as Perl itself.
=end
=end
As you can see any container or element can begin with a normal
identifier ('a-zA-Z_' but no spaces). Since they can be nested name
conflict can be avoided through scoping (module/name and
module/author/name do not conflict). Like *ML (but unlike POD and Kwid)
both whitespace and line breaks are not significant (at least not in
the same way). Unlike *ML, the tags are not so verbose and are fairly
easily readable by humans (at least in IMHO that is). The entities
can be pretty much any single uppercase letter (26 is likely enough).
Now, I am sure some of you are thinking that it is starting to look a
little like YAML. But YAML is much more complex and structured, and
therefore not really good for documentation. YAML has a much larger
syntax, for what I am proposing, what you see here is all of it.
And really, thats pretty much all of it. Details like code and verbatim
sections are not part of this, they are dictated by the formatter. All
we have in here is data, pure and simple.
FORMATTERS
(NOTE: this is currently the weakest part of this proposal/idea, and so
feedback on it is very
[Pugs] Return from within while broken
Hello,
In the latest SVN pugs version (r854 on http://svn.perl.org/perl6/pugs),
the following sub returns 24, not 42:
sub foo {
while (1) {
return 42;
}
return 24;
}
It seems the return statement jumps to the end of the while, instead of
returning from the sub.
Here is a test for this behaviour:
is(eval('sub foo { while (1) { return 24; } return 42; } foo()'), 24,
'return in while');
Calling PIR from a PMC
How does one call a PIR-defined sub from C? My current best guess is, to invoke the PIR sub Tcl::Joe: PMC *invokeme; STRING *Tcl,*joe; Tcl = string_from_const_cstring(INTERP, Tcl, 3); joe = string_from_const_cstring(INTERP, joe, 3); invokeme = Parrot_find_global(INTERP, Tcl, joe); VTABLE_invoke(INTERP,invokeme,); But I don't know what to put as the argument for next to VTABLE_invoke - I see some items in dynclasses/*.pmc use the string next, the code seems to allow for NULL - neither of them seem to actually invoke my method. (a .sub with a single print statement) Do I need to be setting up the calling conventions in my calling code? Is there some other step I'm missing? Is this already documented somewhere?
Re: [PROPOSAL] MMD: multi sub syntax
From: Leopold Toetsch [EMAIL PROTECTED] Date: Mon, 14 Mar 2005 14:02:30 +0100 Leopold Toetsch [EMAIL PROTECTED] wrote: Syntax proposal: .sub foo @MULTI .invocant Integer a .invocant Float b .param pmc c ... Alternate syntax: .sub foo multi(Integer, Float) .param pmc a .param pmc b .param pmc c What if one wants the first and third arguments to be the invocants? Then the first syntax gives .sub foo @MULTI .invocant Integer a .param pmc b .invocant String c ... But it's not as obvious how to do that for the second one, unless you use pmc as the explicit type name for any: .sub foo multi(Integer, pmc, String) .param pmc a .param pmc b .param pmc c In that case the first syntax strikes me as cleaner . . . -- Bob Rogers http://rgrjr.dyndns.org/
[Pugs] short-circuit operators
The following program: my $x = 1; my $y = 2; $x == 1 or $y = 42; printx='$x' y='$y'\n; prints x='1' y='2' in perl5, but prints x='1' y='42' in pugs. (I'm having a go at rewriting a small p5 script in p6 and finding out, by trial and error, what seems to work in Pugs and what doesn't). Oh, and should I add: use v6; at the top of my Pugs .p6 scripts? (I have no idea what that does, just noticed it in some other example scripts). Thanks, /-\ Find local movie times and trailers on Yahoo! Movies. http://au.movies.yahoo.com
Re: Calling PIR from a PMC
On Mon, 14 Mar 2005, William Coleda wrote:
How does one call a PIR-defined sub from C?
use the Parrot_call_sub_* API.
My current best guess is, to invoke the PIR sub Tcl::Joe:
PMC *invokeme;
STRING *Tcl,*joe;
Tcl = string_from_const_cstring(INTERP, Tcl, 3);
joe = string_from_const_cstring(INTERP, joe, 3);
invokeme = Parrot_find_global(INTERP, Tcl, joe);
VTABLE_invoke(INTERP,invokeme,);
But I don't know what to put as the argument for next to VTABLE_invoke - I
see some items in dynclasses/*.pmc use the string next, the code seems to
allow for NULL - neither of them seem to actually invoke my method. (a .sub
with a single print statement)
Do I need to be setting up the calling conventions in my calling code? Is
there some other step I'm missing? Is this already documented somewhere?
here's how i do it in mod_parrot, using the Parrot_* datatypes and the
Parrot_call_sub_* API. some of the logic has been factored out into
different functions for code reuse, but you get the idea:
Parrot_PMC get_sub_pmc(Parrot_Interp interp, char *namespace, char *name)
{
Parrot_PMC sub;
sub = Parrot_find_global(
interp,
namespace ? MAKE_PARROT_STRING(namespace) : NULL,
MAKE_PARROT_STRING(name)
);
return(sub);
}
int modparrot_call_sub(Parrot_Interp interp, char *namespace, char *name,
int *ret)
{
Parrot_PMC sub;
sub = get_sub_pmc(interp, namespace, name);
if (!sub) {
return(0);
}
*ret = Parrot_call_sub_ret_int(interp, sub, Iv);
return(1);
}
-jeff
Re: [PROPOSAL] MMD: multi sub syntax
On Mon, 2005-03-14 at 22:38 -0500, Bob Rogers wrote: What if one wants the first and third arguments to be the invocants? Then the first syntax gives .sub foo @MULTI .invocant Integer a .param pmc b .invocant String c ... But it's not as obvious how to do that for the second one, unless you use pmc as the explicit type name for any: .sub foo multi(Integer, pmc, String) .param pmc a .param pmc b .param pmc c It's not as bad as it seems. Because all three parameters use different registers, the order of the parameters in the signature here doesn't matter. (It may matter to the multi-method dispatcher, but it doesn't matter to the call. I also think it shouldn't matter to the dispatcher.) I'm not sure of any case in practice where having a non-dispatchable parameter between invocants makes sense with multi-methods, though. Do you have an example in mind? -- c
Re: bad file line breaks (was Re: Call for p6ification: Algorithm::Dependency)
On Mon, Mar 14, 2005 at 12:16:07PM -0800, Darren Duncan wrote: At 1:09 AM +1100 3/14/05, Adam Kennedy wrote: At the request of Autrijus, I've just checked the P5 current version of Algorithm::Dependency into pugs, and now we need volunteers to P6ify it. As a reminder to those of you for whom it isn't common sense, the standard way to distribute code on the internet involves having all of your files encoded using UNIX line-breaks (not DOS/Windows, not MAC OS 9). Actually, as we are using Subversion, there is a good way to solve this: svn ps -R svn:mime-type text/plain; charset=UTF-8 modules svn ps -R svn:eol-style native modules This way, everyone will be able to checkout the files with the local encoding. I have previously done so for lib/, t/, src/ and ext/, and I've just committed a change that sets them to modules/ too. :) Thanks, /Autrijus/ pgpRHr5WOKikH.pgp Description: PGP signature
nmake error building Pugs
Hi, I am having trouble building pugs (Perl6-Pugs-6.0.10 and Perl6-Pugs-6.0.11) on win2k professional. I am not able to get the new versions up (I have upgraded MakeMaker and Module::Install). I have put in some more details here . http://rt.cpan.org/NoAuth/Bug.html?id=11814 Thanks, ~Kiran
Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)
Hi Steven, I think one of the great features of JavaDoc is the ability to generate hyperlinked documentation - so someone can walk the inheritance/interface hierarchy within their browser. It also provides consistency across all Java packages. For things like MMD --- I'd like to traverse the hypertext 'linkbacks' to any given method. Which method *exactly* will get called in the super class? A hypertext documentation system that introspects on classes could help here. Wouldn't it also be good to link back to the modules that use the current module in its operating environment? There is a need for a higher level 'structural' documentation that hypertext is well suited to cover - something that spans more than one module. This will be especially important for CPan6 and connecting versions, and modules into bigger 'packages'. Ideally I think the documentation system should be as transparent as possible with the maximum of info found through introspection and a minimum of special tags provided by the programmer. My suggestion is the documentation system should spit out traversable HTML that can be integrated into CPAN6 so as to provide a consistent http://perldoc.com-esque look and feel - that is mirrored in everyone's personal installation as well as on CPAN6. All that said I think a per-module perldoc documentation reader is still very important too ... maybe your design could allow for traversable HTML conversion in the future? Nige On Mon, 14 Mar 2005, Stevan Little wrote: Gang, My proposal is for an extensible version of POD. Basically what XML is to HTML/SGML, this will be for POD. This is a very very very rough draft. I am submitting it in hopes of getting some basic feedback on the idea to see if I should carry it any further or not. So please if you have an opinion on this, either positive or negative, please chime in and let me know. If nothing more I am hoping this might bring the debate over the future of POD (or Kwid) out of the more transient #perl6 and into the more concrete world of email as I think there are currently too many opinions and not enough dialog. - Stevan (p.s. - I apologize in advance if my ideas sound a little jumbled together, remember,.. this is very very rough) INTRODUCTION There has been a lot of chatter on #perl6 about POD vs. Kwid and how best to do this and that, etc. etc. etc. and so on and so forth. It seems to me that we will never be able to create a documentation format which will make everyone happy in all cases. But my question really is, why should we? Just as with HTML, at some point the formatting information overtakes the data being displayed and the data no longer has any real meaning in relation to the markup around it. IMO, POD (and Kwid) are both too formatting centric, and while much simpler than HTML, suffer on some level from the same problem. The early promise of XML was that data and formatting would be separate. That you put the data in the XML and gave it meaning and context, then you put the formatting into your stylesheet (XSL or CSS). Of course we all know XML (and XSL and all its variants) have now become a big ugly monster, but that does not mean those early ideas were not good ones. I am of the opinion that while documentation is traditionally a very static thing, it should and need not be so. In fact, I feel that documentation should be as much meta-data as it is prose. I think the extensible POD-like format I will describe below could possibly bridge that gap between meta-data and static documentation. THE BASIC IDEA When grossly simplified SGML, HTML XML all share a base set of similar constructs. They are made up of Containers, Elements and Entities. An Element is basically a tag with no embedded tags (BR or HR are the most common in HTML). A Container is a tag which itself has Elements within it. An Entity is just a special chunk of text embedded within other text (in *ML they begin with '' and end with ';'). (NOTE: I am making the assumption that text is itself an implicit element) If we port this idea to a POD like syntax, it might look something like this: =container =element: some string with Eentities in it Some plain text contained Iwithin this container. =end The Container is begun the normal POD-ish way, and easily delimited by an '=end' marker. An Element is very POD-ish as well, but is identified by a trailing ':' after it's name. And entities take the common POD form of an uppercase character and something inside of two angle brackets. NOTE: Anything following an Element or a Container declaration on the same line can be thought of as being part of that element/container. This is somewhat like how *ML tags have attributes. A more complex example might be something like this: =module =project: Pugs =name: Perl6::Pugs =version: 6.0.11 =author =name: Autrijus Tang =email: [EMAIL PROTECTED]
Module popularity
The CPAN Search FAQ at http://search.cpan.org/faq.html reads: Q: Do you keep statistics on which modules are most popular? A: Not right now. But there are plans to add some kind of popularity metrics. I think the answer should be updated to point to the Phalanx project. Whom do we contact? -- Ian Langworth Project Guerrilla Northeastern University College of Computer and Information Science
Re: Module popularity
On Tue, Mar 15, 2005 at 01:16:34AM -0500, Ian Langworth wrote: The CPAN Search FAQ at http://search.cpan.org/faq.html reads: Q: Do you keep statistics on which modules are most popular? A: Not right now. But there are plans to add some kind of popularity metrics. I think the answer should be updated to point to the Phalanx project. Whom do we contact? Does the Phalanx project keep popularity metrics? Didn't they get it from somewhere else?
Re: Module popularity
Q: Do you keep statistics on which modules are most popular? A: Not right now. But there are plans to add some kind of popularity metrics. I think the answer should be updated to point to the Phalanx project. I'd rather it didn't. What people think of as popularity is not what Phalanx measures. Let's not stir the mud. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Module popularity
Fair enough. On Tue, 15 Mar 2005 00:37:26 -0600, Andy Lester [EMAIL PROTECTED] wrote: I'd rather it didn't. What people think of as popularity is not what Phalanx measures. Let's not stir the mud. -- Ian Langworth Project Guerrilla Northeastern University College of Computer and Information Science
Exists and Delete
How am I supposed to define a signature that says A scalar that refers to a hash or array element, but do not evaluate or autovivify the element? Or are these two are now strictly methods without functional forms? -- Rod Adams
Re: [Pugs] short-circuit operators
Andrew Savige wrote: Oh, and should I add: use v6; at the top of my Pugs .p6 scripts? (I have no idea what that does, just noticed it in some other example scripts). It tells that script needs perl v6.*.* to work and I think it's good practise to add that to every perl6 script. -- Markus Laire Jam. 1:5-6
Referencing a caller's slurpy array.
A06 says: If you |shift| or |pop| without an argument, it shifts or pops whatever slurpy array is in scope. Shall we assume that @_ is always an alias for this array, so I can say something like: multi sub pop (Array [EMAIL PROTECTED] = @caller::_) returns Scalar ? btw, is ?@ legal in a signature? It's not specifically mentioned in A/S04, but it makes sense it would be allowed along with ?%. -- Rod Adams
