Re: Quick question: (...) vs [...]
John M. Dlugosz 提到: What is the difference between (1,2,3) and [1,2,3] ? One is a List and one is an Array; you cannot push into a list, but you can into an array. my @a := (1,2,3); my @b := [1,2,3]; @a.push(4); # fails @b.push(4); # works Cheers, Audrey
Re: syntax question: method close is export ()
John M. Dlugosz 提到:
Does that mean that traits can come before the signature? Or should it
be corrected to
method close () is export { ... }
It's a simple typo. Thanks, fixed in r14572.
Cheers,
Audrey
Re: Edits to submit
John M. Dlugosz 提到: I've edited several of the S??.pod files,but I have not heard back from the owner ($Larry, whose name is on the top of the file) about accepting merging or rejecting my changes. I've posted the files to http://www.dlugosz.com/Perl6/offerings/ so they don't get lost, until someone with authority wants to diff them. I'm diffing them (slowly), and have committed your stylistic edits to S02.pod. Thanks! However, in S02 you removed the Code class and replaced it with Routine, but that does not really work; for example, a bare block is a Code, but it cannot be a Routine since it can't be wrapped in place, and caller() would bypass it when considering caller frames. Cheers, Audrey
Re: Edits to submit
Audrey Tang 提到: However, in S02 you removed the Code class and replaced it with Routine, but that does not really work; for example, a bare block is a Code, but it cannot be a Routine since it can't be wrapped in place, and caller() would bypass it when considering caller frames. I should've been more explicit. While I don't really have a problem with replacing Code with Callable (except the latter is more wordy, so why not replace Callable with Code...), the issue is that your S02.pod edits indicates that a variable foo must always be bound to a Routine object. However, variable with the sigil can be bound to a Block as well, so replacing Code with Routine at line 1487 and 1512 doesn't quite work. :-) Cheers, Audrey
Re: Conceptual questions about Objects
John M. Dlugosz wrote:
A method can refer to private attributes etc. in other objects than
self. This is unlike Smalltalk and like C++. Which objects? Obviously,
those that _have_ them in the first place.
Correct, though those classes also has to trust the calling class:
class MyClass { has $!attr; trusts YourClass }
class YourClass {
method foo (MyClass $obj) {
$obj!MyClass::attr; # Access to $obj's private attr
}
}
Does the variable used as the invocant, or return value if it is an expression,
have to be statically typed as being of the identical class?
The $obj above must be evaluated to an object of class MyClass.
AFAICS, the spec doesn't really say if a derived class needs to
explicitly trust YourClass for it to be used this way:
class MyDerivedClass is MyClass {};
YourClass.foo(MyDerivedClass.new(attr = 1)); # Not sure if this works.
If class C { has $.a; ... }, then I understand that members may refer to
$.a directly but outside of the scope of members defined in the class
they can only be reached by accessors, a() as a method call.
Well, $.a is exactly the same as $(self.a) -- see S12/are just
shorthands of Cself.foo for the definition.
Methods in class C may call $!a, which is the private accessor method.
Outside the scope, private methods of class C are invisible.
But, it is also stated that in derived and trusted classes, and even in
the class itself, $.a is an accessor call?
Well, $.a is merely shorthand for $(self.a) so derived classes can call
it just fine. However in trusted classes, $.a wouldn't make much sense,
as you need to use either $obj.a or $obj!YourClass::a there.
Is this accessor different from the
function form used outside the class? Why keep the variable syntax?
Because it's jolly convenient, especially in interpolated strings, I
suppose:
say My position is $.x - $.y - $.z;
I'm getting a picture of 3 forms of access: Really direct, direct but
asking the class to access it rather than knowing how storage works, and
indirect that may involve your own code to do other things besides just
get/set the attribute. But I think the middle one can be handled
invisibly by the compiler -- it's no different from a tied hash.
The middle one is not that different from the first one, because from an
implementation viewpoint, once YourClass trusts MyClass, then code in
MyClass might as well have knowledge about how the storage works.
How private is private? I wonder if what you've called private things
are really more like protected in C++ (accessible by the derived
class) and that 'my' attributes are really private, as are submethods.
It's all confused. Who is allowed to access what?
No, private methods are not accessible from derived classes, unless the
base class explicitly trusts them -- See L12/the exclamation form may
be used only in the actual class, not in derived classes.
Cheers,
Audrey
Re: Conceptual questions about Objects
John M. Dlugosz wrote:
That seems to be saying that using the method-call form is preferred, as
it abstracts whether it is a real hard attribute or not.
Er, it is not so.
The $.foo notation is good not only for calling accessors, but also as a
way to specify context when calling oneself's methods. Consider:
class Foo {
method bar ($x, $y) { ... }
method baz (
$.bar: 1, 2;
@.bar: 3, 4;
}
}
Here we are simply typing $.bar as a shorthand of $(self.bar), and @.bar
as @(self.bar), as well as supplying them with arguments; they do not
mandate that there exists a bar attribute for our class.
In other words, there needs to be no real hard attribute bar, no
matter if you call the bar method as self.bar(), $.bar(), or simply $.bar.
Cheers,
Audrey
Re: Conceptual questions about Objects
John M. Dlugosz wrote: OK, trust is not implicit on derived classes. Is that because there is no rule that says it is, or is there a mention of that somewhere in the official docs? There is. S12 Line 561: Every Idot declaration also declares a corresponding private Iexclamation storage location, and the exclamation form may be used only in the actual class, not in derived classes. Cheers, Audrey
Re: our methods?
John M. Dlugosz 提到: In S29, there are definitions like our Capture method shape (@array: ) is export But in S12 there is no mention as to what an our method is. It states that my is used to make private methods, and ^ to make class methods. I think this is a doc relic and should be fixed globally in that file. S02/Return types: If a subroutine is not explicitly scoped, it belongs to the current namespace (module, class, grammar, or package), as if it's scoped with the Cour scope modifier. Any return type must go after the name: So this line: our Capture method shape (@array: ) is export is really the same as: method shape (@array: ) of Capture is export The prefixing of our is there to make the return (of) type stand out. Cheers, Audrey
Re: S09 editorial fixes
John M. Dlugosz 提到:
= on Parallelized parameters and autothreading
use autoindex;
do { @c[$^i, $^j, $^k, $^l] = @a[$^i, $^j] * @b[$^k, $^l] };
Shouldn't those be semicolons? Ditto for subsequent examples.
Also, what does the do do? I think it is only meaningful if there was
something using this block's return value. I suspect it is a relic of p5
notation.
No, something more subtle is going on -- the do STATEMENT notation
sees a stand-alone block in statement position, so it's automatically
called with no arguments.
Here is a rewrite of that section starting from line 1044 onward.
Sanity-check before I check it in?
In the abstract (and often in the concrete), this puts an implicit
loop around the block of the closure that visits all the possible
subscript values for that dimension (unless the parameter is actually
supplied to the closure, in which case the supplied value is used as
the slice subscript instead).
This implicit loop is assumed to be parallelizable.
So to write a typical tensor multiplication:
Cijkl = Aij * Bkl
you can simply call a closure with no arguments, allowing the Cautoindex
pragma to fill in the defaults:
use autoindex;
- $i, $j, $k, $l { @c[$i; $j; $k; $l] = @a[$i; $j] * @b[$k; $l] }();
or you can use the Cdo STATEMENT syntax to execute a stand-alone closure,
which also implicit loops:
use autoindex;
do - $i, $j, $k, $l {
@c[$i; $j; $k; $l] = @a[$i; $j] * @b[$k; $l]
}
or even use placeholder variables instead of a parameter list:
use autoindex;
do { @c[$^i; $^j; $^k; $^l] = @a[$^i; $^j] * @b[$^k; $^l] };
That's almost pretty.
Re: S09 editorial fixes
Audrey Tang 提到:
John M. Dlugosz 提到:
= on Parallelized parameters and autothreading
use autoindex;
do { @c[$^i, $^j, $^k, $^l] = @a[$^i, $^j] * @b[$^k, $^l] };
Shouldn't those be semicolons? Ditto for subsequent examples.
Also, what does the do do? I think it is only meaningful if there was
something using this block's return value. I suspect it is a relic of p5
notation.
No, something more subtle is going on -- the do STATEMENT notation
sees a stand-alone block in statement position, so it's automatically
called with no arguments.
Er, sorry, that wasn't entirely correct. :-)
It's actually using the do BLOCK form, which implicitly calls the
block once, with no arguments, as defined in S04/The do-once loop.
So the paragraph that mentioned do STATEMENT in my previous mail
should instead read:
or you can use the Cdo BLOCK syntax (see LS04/The do-once loop) to
call that closure, which also implicit iterates:
Cheers,
Audrey
Re: S09 editorial fixes
John M. Dlugosz 提到:
But about your answer, automatically called with no arguments. Isn't
that what a bare closure normally does anyway? Say, I introduced extra
{} just for scoping or naming the block, where a statement is expected.
foo;
bar;
{ my $temp= foo; bar(temp); } #forget about $temp.
Correct, but a pointy - $i {...} is not bare, and neither is blocks
with placeholders such as { $^i }.
In fact, the latter is currently an error in Pugs:
$ ./pugs -e '{$^i}'
*** Blocks with implicit params cannot occur at statement level
at -e line 1, column 1
The relevant paragraph is S04/The do-once loop:
Although a bare block is no longer a do-once loop, it still executes
immediately as in Perl 5, as if it were immediately dereferenced with
a C.() postfix, so within such a block CCALLER:: refers to the
scope surrounding the block. If you wish to return a closure from a
function, you must use an explicit prefix such as Creturn or Csub
or C - . (Use of a placeholder parameter is deemed insufficiently
explicit because it's not out front where it can be seen. You can, of
course, use a placeholder parameter if you also use Creturn.)
I guess the wording in the last parenthesized parens is insufficiently
explicit, and maybe we should change it to say that it's really a syntax
error to use placeholder blocks in statement positions. Sounds reasonable?
Cheers,
Audrey
Re: S09 editorial fixes
John M. Dlugosz 提到:
I just finished another pass on S09v24, and in this posting I note
editorial issues with the file that can easily be corrected. This is as
opposed to subjects for deep discussion, which I'll save for later and
individual posts.
= on Mixing subscripts
Within a C.[] indexing operation...
Why the dot? The examples don't use a dot, and this makes it sound like the
dot is involved and that is confusing. I see that C.{} was also mentioned
earlier.
The dot is there to signify that we're talking about postcircumfix:[
], the indexing function, instead of circumfix:[ ], the array
construction function. I guess we can say Within a postcircumfix C[]
indexing operation, but I'm not sure it's clearer.
= on The semicolon operator
Another thing that's not going to fly easily is simply dropping out
terms to the end of the section.
That is out of place. The transition is wrong, and it does not express
something that is unique to this topic. I think it is a relic.
It's there to explain that why we use an explicit Whatever Asterisk:
0..* :by(2)
instead of simply dropping out the right-hand term:
0.. :by(2)
Because :by(2) in term position is a pair constructor, not a named
argument in the current expression.
Suggestions welcome on how to make the transition more smooth, though. :-)
Cheers,
Audrey
Re: S09 editorial fixes
Larry Wall 提到:
Yes, unless we decide we need something like that for list
comprehensions. Maybe looping modifiers allow placeholders in what
would otherwise be an error...
Sure. How about this:
Use of a placeholder parameter in statement-level blocks triggers a
syntax error, because the parameter is not out front where it can be
seen. However, it's not an error when prefixed by a Cdo, or when
followed by a statement modifier:
# Syntax error: statement-level placeholder block
{ say $^x };
# Not an syntax error, though $x doesn't get the argument it wants
do { say $^x };
# Not an error at all
{ say $^x } for 1..10;
I do find it interesting that, because any block just inside a left
parenthesis is immediately called like a bare block, we have:
my $x = {1+1}; # $x is a Code
my $y = ({1+1});# $y is 2!
Is that correct?
Cheers,
Audrey
Re: S09 editorial fixes
Larry Wall 提到:
I was originally thinking just loop modifiers, but I suppose
{ say $^x } if foo();
also can be made to make some kind of sense, in the same way that
if foo() - $x { say $x }
is supposed to work.
Right. I've committed the clarification (as a new section). Thanks!
Yes, current STD has the inside of () and [] as statementlist,
which throws away all but the last statement. Arguably [] at least
should probably be semilist though, and maybe () too.
my @x := [{1+1}; {2+2}]; @x is currently [4], should be [2,4]?
my @x = ({1+1}; {2+2}); same deal?
That's what I'd expect, yes.
Cheers,
Audrey
Re: S09 editorial fixes
Nicholas Clark 提到:
So if the semicolon is replaced with a comma, like this,
my @x := [{1+1}, {2+2}];
the {} acts as a hash constructor, and @x is [{2 = undef}, {4 = undef}] ?
No, {} acts as a closure constructor, and @x contains two closures that
returns 2 and 4 respectively when called:
@x[0](); # 2
@x[1](); # 4
Basically, {} is only a hash constructor if the inside is either empty,
or contains only a list starting with a pair or a hash:
$hash = { };
$hash = { %stuff };
$hash = { a = 1 };
$hash = { a = 1, $b, $c, %stuff, @nonsense };
$code = { ; };
$code = { @stuff };
$code = { a, 1 };
$code = { a = 1, $b, $c == print };
The examples above are from LS04/Statement parsing.
Cheers,
Audrey
Re: S09 editorial fixes
Thom Boyer 提到:
Audrey Tang wrote:
$code = { a = 1, $b, $c == print };
The examples above are from LS04/Statement parsing.
According to those rules, that last assignment to $code seems to be a
hash, not code. Or does the C == mean that the contents aren't a
list?
Correct, because == binds looser than , (i.e., Terminator is looser
than Comma), so the toplevel in that block is not a list, but a feed.
Cheers,
Audrey
Re: Generalizing ?? !!
在 Jun 11, 2007 5:10 AM 時，Jonathan Lang 寫到： A variation of chaining associativity gets used, with the chaining rule being '$v1 op1 $v2 // $v1 op2 $v3' instead of '$v1 op1 $v2 $v2 op2 $v3', as is the case for comparison chaining. But wouldn't that make: True ?? undef !! Moose; evaluate to Moose, instead of undef as we wanted? Cheers, Audrey
Re: .perl, nested arrays, parens and a bug with .perl after hyperop
在 May 21, 2007 8:45 AM 時，Juerd Waalboer 寫到： Steffen Schwigon skribis 2007-05-21 1:28 (+0200): That's ARRAY := ARRAY there, so the following should dwym: my @foo := [ 1, 2, 3 ]; However, this does not work with pugs, so I don't know if I am wrong, or pugs is wrong. Pugs is wrong and will be corrected before 6.28.0. :-) Audrey
Re: pugs: aborting smoke tests
在 Apr 20, 2007 7:45 PM 時，Agent Zhang 寫到： On 4/13/07, Agent Zhang [EMAIL PROTECTED] wrote: Okay, I think I've fixed the bug by defaulting to YAML.pm instead of YAML::Syck. As confirmed by Ingy++, The current version of YAML::Syck on CPAN is having problem with single-quotes in its emitter: http://colabti.de/irclogger/irclogger_log/perl6? date=2007-04-17,Tuesel=65#l108 I've noticed that this issue didn't affect Larry's recent smokes. Maybe he was using an older YAML::Syck? or he simply didn't install YAML::Syck at all? Oops, it was a regression introduced in YAML::Syck 0.84. I've fixed the issue and released 0.85, which should again serialize strings containing single-quotes correctly. Thanks! Audrey
Re: [perl #41617] make test-pir fails on x86 linux, r14402
在 Feb 26, 2007 3:37 AM 時，Eric Hanchrow (via RT) 寫到： # New Ticket Created by Eric Hanchrow # Please include the string: [perl #41617] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41617 Here's what I did: $ svn co -r14402 http://svn.pugscode.org/pugs pugs $ cd pugs $ perl Makefile.PL $ make $ PATH=$PATH:/usr/local/src/langs/parrot-svn/ make test-pir I saw this: Linking pugs.new ... cp pugs /usr/local/src/langs/pugs/blib/script/pugs /usr/bin/perl -Iinc -MExtUtils::MY -e MY-fixin(shift) /usr/ local/src/langs/pugs/blib/script/pugs cd perl5/Data-Capture perl Makefile.PL make Can't open for input: No such file or directory at /usr/share/perl5/Module/Install/ Admin.pm line 135. BEGIN failed--compilation aborted at Makefile.PL line 3. make[1]: *** [build_perl5] Error 2 make[1]: Leaving directory `/usr/local/src/langs/pugs' Thanks, please svn up the pugs tree and try again. Cheers, Audrey
Re: Packed array status?
2007/2/27, Geoffrey Broadwell [EMAIL PROTECTED]: As a simpler case than a full 3D engine port, I have some OpenGL benchmarks in Perl 5 that I can port -- these have much reduced requirements. Principly, they need: 1. Basic math and string operators (not grammars) 2. Basic looping and simple control structures 3. Basic subroutine handling 4. Basic I/O: read file, print to STDOUT (printf is a bonus) 5. Read access to command line args 6. Perl scalars, hashes, and arrays, with one level nesting 8. eval (tight inner loops are generated) 9. High-resolution time 10. Access to SDL OpenGL constants 11. Procedural calls to OpenGL, with scalar return values 12. Procedural or OO calls to SDL, with scalar (and object, if OO) return values (no callbacks) Pugs at the moment support all of the above, using the Perl 5 bridge for use perl5:SDL and use perl5:OpenGL. So the sole requirement seems to be: 7. Packed arrays with access to raw data pointer to give to API Is it possible to point us to some use cases of such packed arrays, especially the raw data pointer API part? Also, if you would translate a few such use cases to the syntax in S09 (http://perlcabal.org/syn/S09.html) and committing them under t/data_types/, then it'd be much easier to measure which parts of packed arrays needs to be specced/implemented first. Cheers, Audrey
Re: Packed array status?
2007/2/27, Geoffrey Broadwell [EMAIL PROTECTED]: 7. Packed arrays with access to raw data pointer to give to API Is it possible to point us to some use cases of such packed arrays, especially the raw data pointer API part? Are you looking for Perl code that creates such packed arrays and passes them to OpenGL? Or are you looking for links to manpages for the OpenGL calls themselves? Or both? The former. Also, if you would translate a few such use cases to the syntax in S09 (http://perlcabal.org/syn/S09.html) and committing them under t/data_types/, then it'd be much easier to measure which parts of packed arrays needs to be specced/implemented first. I can write some tests that build packed arrays of some of the types I need and then go snooping around it checking the contents ... would that help? Somehow I'm thinking it's a bad thing if data types tests require OpenGL ... but it seems hard to tell whether the implementation is actually creating a packed array, or just faking the Perl-side behavior using an unpacked array, unless we make a call to some C API that can confirm the results. That is correct. However as you noted, our buf should be as good as a C-level packed buffer, so you can assume that when writing the tests. Alternately, we can assume some fairly simple C FFI calls such as strlen() (or some such) that manages the structs we'd like it to manage. Thanks, Audrey
Re: recent changes
在 Feb 9, 2007 5:17 AM 時，Larry Wall 寫到： Questions and feedback welcome, but please don't follow up to this message--start a new thread for a new topic. Bear in mind that this is completely untested code, still fairly buggy and incomplete. Not even pugs can parse it (yet). Note: After some typo fixes and minor workarounds, Pugs now parses it just fine -- the task now is how to run it, and run it _fast_, before we make it part of sanity. :-) Cheers, Audrey
Re: Pugs on Windows
在 Feb 6, 2007 11:07 PM 時，Gabor Szabo 寫到： On http://www.pugscode.org/ when I click Download I get to the wiki on rakudo and (yippi it works again !) but the link to the Win32 binary builds of Pugs and Parrot brings me to http://jnthn.net/public_html/perl6/ which is 404. Fix the rakudo wiki to point to http://jnthn.net/perl6/ ? Cheers, Audrey
Re: hello, does anybody who knows the svn respo of synopsis docs?
在 Dec 18, 2006 5:52 AM 時，Fayland Lam 寫到： we are trying to translate them into Chinese. so I just wonder where can I get the .pod source? http://svn.perl.org/perl6/doc/trunk/design/syn/ Cheers, Audrey
ANN: Pugs Repository URL Changed.
After a week of planning, and with plenty of help from clkao++, obra+ +, #jifty, #bps and #perl6, I'm glad to announce that Pugs now has a new, permanent URL for its subversion repository: http://svn.pugscode.org/pugs/ (HTTP) https://svn.pugscode.org/pugs/ (HTTPS) Subversion users, please switch your working copy this way: svn switch --relocate http://svn.openfoundry.org/pugs http:// svn.pugscode.org/pugs SVK users, please update the mirror path: svk mirror --relocate //mirror/pugs http://svn.pugscode.org/pugs Commit bits are re-mailed to all existing committers and metacommitters; please set your password again by following the URL in the mail. If you have not received the new commit bit, please let me know on #perl6 or via email. Metacommitters can now manage invitations with a prettier interface at http://commitbit.pugscode.org/, powered by CommitBit. We are still working on restoring the read-only mirrors at openfoundry and svn.perl.org. Thanks to yet another a soon-to-be- announced open source product from #bps, we plan to turn them into full R/W mirrors, so we can distribute the load by setting up one replication server per continent. Have fun! Audrey
Re: mmd-draft.txt
在 Oct 26, 2006 10:26 AM 時，TSa 寫到： I figure that http://svn.openfoundry.org/pugs/docs/notes/multi_method_dispatch/ mmd-draft.txt hasn't made it into S06 yet. So what is the current state of affairs? The original plan was to have Larry review it in Brazil and check it in along with an implementation (or two), but that may have to wait a bit now that Larry can't make it to Brazil... Could someone explain me the voting mechanism mentioned in the document? I get that it works from left to right and compares the narrowness of types of the competing targets at that position. But what information is recorded on the score cards and how is that finally used in selecting the dispatch target? A variant's score cards only records two Boolean values for each variant: voting and qualified. The final resolution is by consensus: After all the positions are processed, if all variants consider a single unique variant to be qualified, it is chosen. Otherwise an ambiguity error is raised. Thanks, Audrey
Re: variables inside an eval
在 Oct 29, 2006 4:34 PM 時，Richard Hainsworth 寫到：
If I have the following
my $self = some text;
my $nself = ~eval(q/self is $self/,:langperl5);
then surely $nself should be self is some text.
But it is not. $self is not set inside the eval in pugs.
But
say ~eval(q/self is $self/);
yields
self is some text
Is this correct behaviour?
It's now fixed as of r14574 -- scalar lexical variables now pass into
Perl 5 just fine. Enjoy!
Oh, and you can now also write:
sub f ($x, $y) {
use v5;
$x + $y
}
say f(1,2); # 3
That is, any block that begins with use v5; is now handled by Perl
5. This should eliminate
some of the workarounds with eval('sub{}', :langperl5), and it's
now made into Spec in S01 and S11.
Thanks,
Audrey
Re: variables inside an eval
在 Oct 29, 2006 4:34 PM 時，Richard Hainsworth 寫到：
If I have the following
my $self = some text;
my $nself = ~eval(q/self is $self/,:langperl5);
then surely $nself should be self is some text.
But it is not. $self is not set inside the eval in pugs.
The lexical pad is not yet shared with Perl 5. Can you commit a test
in t/perl5/ to test that?
(I've just sent you a commit bit; please add yourself to AUTHORS
first. :-))
If yes, then how can I use content from a scalar inside an eval
with perl5?
As a workaround:
my $nself = eval(q/sub { my $self = shift; self is
$self }/, :langperl5)($self);
Audrey
[ANNOUNCE] Pugs 6.2.13 released!
After nearly four months of development and 3400+ commits, I'm very glad
to announce that Pugs 6.2.13 is now available:
http://pugs.blogs.com/dist/Perl6-Pugs-6.2.13.tar.gz
SIZE: 6839270
SHA1: b06b8434c64e9bb5e3ab482282fbae0a6ba69218
Motivated by increasing use of Pugs in production, this is an extra
release
in the 6.2.x series, offering another 200%+ improvement in performance,
comprehensive support for interoperability with Perl 5 modules, a
built-in
grammar engine via native perl5 embedding, and much better support for
roles, classes and objects.
The web-based presence of Pugs and Perl 6 has improved as well:
* http://run.pugscode.org/ puts the Pugs shell in your browser.
* http://spec.pugscode.org/ annotates the Synopses with smart-
linked tests.
* http://smoke.pugscode.org/ annotates that further with fail/
pass/todo records.
* http://rakudo.org/perl6/ is a Wiki dedicated to collect Perl 6
related information.
* http://www.programmersheaven.com/2/Perl6-FAQ offers a
comprehensive FAQ on Perl 6.
Thanks again to all lambdacamels on #perl6 for building this new ship
together;
it is truly an exhilarating voyage. :-)
Have -Ofun!
Audrey
(The change log below is also available in HTML format:
http://pugs.blogs.com/pugs/2006/10/pugs_6213_relea.html#more
)
= Changes for 6.2.13 (r14401) - October 17, 2006
== Build System
* Perl 5 embedding is now enabled by default
** For Windows users, Perl 5.8.x is required
** Set the `PUGS_EMBED` environment variable to `noperl5` to disable
this
* Prompting for Parrot embedding is now disabled by default
** Set the `PUGS_EMBED` environment variable to `parrot` to enable this
* Support for compiling using GHC 6.6
** GHC 6.4.1+ is still supported, but 6.6 will be required in the
next release
== Feature Changes
=== Interactive Shell and Command-Line Flags
* New `pugs -d` flag to display a trace for debugging
* The `:r` command now resets the environment once, not twice
* The return value of blocks, such as `gather {...}`, is displayed
correctly
* `$_` is no longer clobbered with the result of each expression's
evaluation
=== Perl 5 Interoperability
* Arrays and Hashes now round-trip from Pugs to Perl 5 land and back
* Importing functions from Perl 5: `use perl5:CGI header param`
* Passing unboxed values across runtimes no longer leaks memory
* When embedding Perl 5.8+, Unicode flag is now on for Pugs-to-Perl5
strings
* `eval($str, :langperl5)` now accepts non-ASCII characters in `$str`
=== Lexical Syntax
* Capture literals: `\($bar: 1, 2, 3, named = 4)`
* Here-docs now work as specced; also warns against inconsistent
indentation
* Interpolation of chained calls: `$foo.meth.meth.meth.meth()`
* List comprehension: `for 0 list(@x) 10 {...}`
* Named character escapes: `\c[LATIN CAPITAL LETTER Y]`
* New grammatical category `term:`, separated from the `prefix:`
category
* New magical variables: `$?COMPILER` and `$?VERSION`
* Parse for `LABEL: STMT`, although it's currently treated the same
as `STMT`
* Pod directives: `=begin`/`=end` and `=for` now terminate without
`=cut`
* Pod variables: `$=FOO` and [EMAIL PROTECTED] give you access to the Pod
section FOO
* Quote adverbs no longer take non-parens brackets: `rx:P5{...}` is
valid again
* Shell-like quoting rules implemented for ` $x qq 'q' `
* Signature literals: `:($foo is copy = 42, $, @)`
* Support for UTF-8, UTF-16 and UTF-32 encoded source files
* Support for backquotes and `qx/.../` for capturing external command
output
* User-defined infix associativity: `sub infix:foo is assoc
('right') {...}`
* `\123` and `\03` are now errors; write `\d123` and `\o03`
instead
* `$::x` now means exactly the same a `$x`, instead of `$*x`
* `%h` now means `%h{}` -- the entire hash, not the empty string as
key
* `($::('x'))` with two adjacent closing parens now parses correctly
* `0_123_456` now parses as `0d123456`, not an error
* `12` is now a fatal error: Odd number of elements in Hash
* `q()` and `qw()` with parentheses are parsed as functions, not quotes
=== Declarators and Operators
* Argument interpolation via prefix `|` and `|`
* Binding to qualified uninitialised symbols: `fully::qualify := sub
{...}`
* Contextual variables are now declared with `my $x is context`, not
`env $x`
* Hyperised reduce operators: `[+]` and `[\+]`
* Implicit invocation assignment: `.= uc` is parsed as `$_ = $_.uc`
* Mid-block redeclaration no longer allowed: `my $x; { $x = 1; my $x
= 2 }`
* Negated comparison operators: `!eqv`, `!=:=` etc; `!~~` replaces `!~`
* New infix comparison operators: `===` and `eqv`
* New infix non-short-circuiting boolean AND operator: `?`
* Nullary reduction of builtin operators gives identity values: `[*]
() === 1`
* Postfix operators can be called with a dot: `.++`, `$x.++`, `$x.\ ++`
* Prefix `=` now iterates on arrays as well: [EMAIL PROTECTED]
* Short-circuiting chained comparison: `1 2 die('foo')` no
Re: Runtime Role Issues
在 Oct 12, 2006 2:39 PM 時，Ovid 寫到： --To forcefully add a role to a class at a distance during runtime, use a class object call (see Moose::Meta::Class for more about these APIs): ^Dog.add_role(^Catlike); That's more of what I was thinking, but where is this documented? I can't find it in http://dev.perl.org/perl6/doc/design/syn/S12.html. I see it in the Moose docs, but is this in Perl 6? I thought it was. Well, it's in Perl 6, and Moose is currently the metaobject layer when the VM that runs Perl 6 happens to be perl5... Right after the 6.2.13 release (which is ready now, except for changelogging), we'll switch to the Moose team's MO system, ensuring that the introspectio APIs work exactly the same way on both GHC and perl5 virtual machines. Thanks, Audrey
Re: Runtime Role Issues
在 Oct 12, 2006 5:43 AM 時，Tim Bunce 寫到： On Tue, Oct 10, 2006 at 01:31:59PM -0700, Ovid wrote: Hi all, In doing a bit of work with traits (roles) in Perl 5 (http://perlmonks.org/?node_id=577477), I've realized some edge cases which could be problematic. First, when a role is applied to a class at runtime, a instance of that class in another scope may specifically *not* want that role. I always thought when a role is applied to a class at runtime you get a new (anonymous) subclass. The original class isn't affected. Right, that's what usually happens with: my Dog $fido .= new; $fido does Catlike; Here $fido's class become a new (memoized, anonymous) class that still has Dog as its name, but is no longer equivalent to the vanilla ^Dog class object. To forcefully add a role to a class at a distance during runtime, use a class object call (see Moose::Meta::Class for more about these APIs): ^Dog.add_role(^Catlike); Thanks, Audrey
Re: error when using - as lambda function
在 Oct 3, 2006 10:22 PM 時，Wim Vanderbauwhede 寫到：
say (- $n { - $f { $f($n,$f) }.( - $n, $f { $n2 ?? 1 !! $n*$f
($n-1,$f)
}) }).(5);
say OK;
#say (- $n { - $f { $f($n,$f) }.( - $n, $f { $n2 ?? 1 !! $n*$f
($n-1,$f)
}) }).(5);
say OK;
It's extremely subtle -- $n2 should never have parsed in the first
place, because it's always a
hash dereference (as in $n2); put a whitespace before the sign to
get the infix comparison
operator you're looking for.
See LS03/Changes to Perl 5 operators/Note that Perl 6 is making a
consistent three-way distinction
for more details on this distinction.
Pugs should have never admitted the first $n2 case (by scanning
outward to a matching and
failing+backtracking), and should instead say someting like write $n
2 instead. Can you commit a
test to make sure that 12 is a parse failure, perhaps as t/syntax/
parsing/lt.t?
A commit bit is on your way. Remember to add yourself to AUTHORS
first. :-)
Thanks!
Audrey
Re: Nested statement modifiers.
在 Oct 4, 2006 7:46 AM 時，Damian Conway 寫到：
[Apologies for the last post. Gmail got a little eager.
Here's what I meant to send...]
Juerd wrote:
Which can also be written as:
do { do { say 1 if 1 } if 1 } if 1;
Sorry, no it can't. From S4
(http://dev.perl.org/perl6/doc/design/syn/
S04.html#The_repeat_statement):
Unlike in Perl 5, applying a statement modifier to a do block is
specifically disallowed...
However, I wonder if this is too strict. Disallowing while and
until after a do block
is fine (and can be coded directly in those two statement modifier
macros), but is there a
reason to disallow other modifiers?
Thanks,
Audrey
Re: Nested statement modifiers.
在 Oct 4, 2006 10:17 AM 時，Damian Conway 寫到：
Audrey asked:
However, I wonder if this is too strict. Disallowing while and
until after a do block is fine (and can be coded directly in those
two statement modifier macros), but is there a reason to disallow
other modifiers?
Well, for a start, there's this syntactic problem:
do { say vale, munde asper; mori(); }
if $lang eq 'Latinus';
*nod* The use case here is
do { .foo for @bar } if $baz;
But I guess you can always protect it with a parens:
(do { .foo for @bar }) if $baz;
Which also makes the syntactic problem go away. So indeed,
disallowing statement modifiers after do{} altogether seems sane.
Thanks!
Audrey
Re: trying to use a role within a role
在 Sep 30, 2006 6:26 PM 時，Richard Hainsworth 寫到：
role win_text {
has $.win_mytxt1 is rw;
has $.win_mytxt2 is rw;
};
role mywindow {
has $.border is rw;
has $.colour is rw;
does win_text;
};
my $w = new mywindow;
$w.border = 2;
$w.colour = 'red';
say $w.border;
say $w.colour;
$w.win_mytxt1 = 'quick red fox';
$w.win_mytxt2 = ' jumped over the lazy dog';
say $w.win_mytxt1 ~ $.win_mytxt2;
On the last line it should be $w.win_mytxt2, not $.win_mytxt2.
At this moment only role mywindow does win_text works; the
statement-level does form was not implemented, but I should be
able to do so in the next few days. I've sent you a Pugs commit bit;
can you check this test of yours in under t/oo/ somewhere?
Thanks!
Audrey
Re: trying to use a role within a role
在 Oct 2, 2006 5:56 PM 時，Audrey Tang 寫到： At this moment only role mywindow does win_text works; the statement-level does form was not implemented, but I should be able to do so in the next few days. Update: It's now implemented as r13782. Richard: The t/README file should get you started at writing (and committing) your first test; people on irc.freenode.net #perl6 will definitely help as well. Pugs operates under a seek-forgiveness-not-permission model, so it's easiest to just copy a test in the same directory, modify it, and check it in. If anything went wrong, the gnomes on #perl6 will fix it right away. :-) Thanks! Audrey
Re: Motivation for /alpha+/ set Array not Match?
在 Sep 28, 2006 3:03 AM 時，Carl Mäsak 寫到： Audrey (): Indeed... Though what I'm wondering is, is there a hidden implementation cost or design cost of making /foo+/ always behave such that $foo.from returns something, compared to the current treatment with the workaround you suggested? Has this been settled or addressed off-list? 'fraid not yet... Because from my perspective as one who has never used P6 rules for anything in particular, but who in the future most likely will, the proposed semantics seems a lot saner and more useful. It'd be sad to let pass this opportunity to fix (what from my perspective appears to be) a shortcoming of the rule semantics. *nod* The lack of .from/.to is merely an annoyance, but the spaced-out stringification is really, really surprising with /foo+/. Thanks, Audrey
Re: Motivation for /alpha+/ set Array not Match?
在 Sep 22, 2006 10:36 PM 時，Patrick R. Michaud 寫到： Out of curiosity, why not: /foo bar bar $xyz:=(foo+)/ and then one can easily look at $xyz.from and $xyz.to, as well as get to the arrayed elements? (There are other possibilities as well.) I'm not arguing in favor of or against the proposal, just pointing out that there are ways in the existing scheme to get at what is wanted. Indeed... Though what I'm wondering is, is there a hidden implementation cost or design cost of making /foo+/ always behave such that $foo.from returns something, compared to the current treatment with the workaround you suggested? Thanks, Audrey
Re: [svn:perl6-synopsis] r12346 - doc/trunk/design/syn
在 Sep 23, 2006 8:36 PM 時，Markus Laire 寫到： On 9/23/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: @args = [EMAIL PROTECTED],1,2,3; -push [,] @args;# same as push @foo,1,2,3 +push [,] @args;# same as push(@foo: 1,2,3) I don't quite understand this. Shouldn't C[,] @args be equivalent to C[EMAIL PROTECTED],1,2,3 just as C[+] 0,1,2,3 is equivalent to C0+1+2+3? So why is there C: instead of C, after C@foo? Does this have something to do with the fact that C@args is C[EMAIL PROTECTED],1,2,3 and not C@foo,1,2,3? Exactly. Per this interpretation, [EMAIL PROTECTED] is shorthand for \(@foo :), and [,] would first flatten the contents of @arg, and then process each one; if an element is Capture, it is joined into the current arglist; if it's not, then it's made a simple positional. I wasn't sure about this treatment, so I checked on #perl6 with Larry; an alternative is to treat the elements of @foo always as positional arguments, but that will make the two [,] calls below nonequivalent: my @args = [EMAIL PROTECTED], 1, 2, 3; [,] @args; [,] [EMAIL PROTECTED], 1, 2, 3; I'd prefer to make them equivalent, on the principle that all listops conceptually flatten+concat their arguments first, and then process each element regardless of its origin. Thanks, Audrey
Re: [svn:perl6-synopsis] r12346 - doc/trunk/design/syn
在 Sep 24, 2006 12:21 AM 時，Audrey Tang 寫到： 在 Sep 23, 2006 8:36 PM 時，Markus Laire 寫到： On 9/23/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: @args = [EMAIL PROTECTED],1,2,3; -push [,] @args;# same as push @foo,1,2,3 +push [,] @args;# same as push(@foo: 1,2,3) I don't quite understand this. Shouldn't C[,] @args be equivalent to C[EMAIL PROTECTED],1,2,3 just as C[+] 0,1,2,3 is equivalent to C0+1+2+3? So why is there C: instead of C, after C@foo? Does this have something to do with the fact that C@args is C[EMAIL PROTECTED],1,2,3 and not C@foo,1,2,3? Exactly. Per this interpretation, [EMAIL PROTECTED] is shorthand for \(@foo :), and [,] would first flatten the contents of @arg, and then process each one; if an element is Capture, it is joined into the current arglist; if it's not, then it's made a simple positional. I wasn't sure about this treatment, so I checked on #perl6 with Larry; an alternative is to treat the elements of @foo always as positional arguments, but that will make the two [,] calls below nonequivalent: my @args = [EMAIL PROTECTED], 1, 2, 3; [,] @args; [,] [EMAIL PROTECTED], 1, 2, 3; I'd prefer to make them equivalent, on the principle that all listops conceptually flatten+concat their arguments first, and then process each element regardless of its origin. On the other hand, it can also be argued that [,] TERM, TERM, TERM; is shorthand for |(TERM), |(TERM), |(TERM) and the treatment will depend solely on TERM's scalar-context type without considering list flattening. Per that interpretation, indeed these two need not be equivalent: my @args = [EMAIL PROTECTED], 1, 2, 3; [,] @args; # four positionals, same as |@args [,] [EMAIL PROTECTED], 1, 2, 3; # one invocant, three positionals, same as | ([EMAIL PROTECTED]), |(1), |(2), |(3) however, having a listop that does not do flatten+concat doesn't feel quite right, so I'd still like the flatten-concat-explode model as currently specced. Thanks, Audrey
Motivation for /alpha+/ set Array not Match?
From S05: If a subrule appears two (or more) times in any branch of a lexical scope (i.e. twice within the same subpattern and alternation), or if the subrule is quantified anywhere within a given scope, then its corresponding hash entry is always assigned an array of CMatch objects rather than a single CMatch object. However, fglock and I both find the quantified clause very surprising. Intuitively: /foo bar bar foo/ should set $foo to an Array with two Match elements. However: /foo+/ should set $foo to a single Match, with multiple positional Match elements, each one representing one match in the quantified match. Moreover: /foo bar bar foo+/ should set $foo to an Array with two Match elements, the first being a simple match, and the second has multiple positional submatches. The thinking behind the separate treatment is that in a contiguous quantified match, it does make sense to ask the .from and .to for the entire range, which is very hard to do if it's an Array (which can have 0 elements, rendering $foo[-1].to dangerous). Also stringification for $foo on a /foo+/ match should perhaps not be space-separated, i.e. it should follow Match semantics not Array semantics. To recap: Is it possible to amend the quantified clause to have it produce Match objects, and reserve Array only for noncontiguous same-named subrules? Thanks, Audrey
Re: Unpacking tree node parameters
在 Sep 4, 2006 2:11 AM 時，Gaal Yahas 寫到：
Unless I'm mistaken, this doesn't cast back to subroutine signature
land
very well:
sub f1 (Dog ($fido, $spot)) { ... }
sub f2 (Dog $ ($fido, $spot)) { ... }
sub f3 (Dog :($fido, $spot)) { ... }
Correct.
Unless Audrey's latest S03 patch pertains here as well, and Dog
distributes; in that case it would be as if the programmer had written
sub f1 ([Dog $fido, Dog $spot]) { ... }
Yes, except there's no [] there; it's two positional parameters.
as described in the preceding section, Unpacking array
parameters. If
this is *not* the case, then f1 is not ambiguous!
TimToady++ just confirmed on IRC that it is indeed the case.
Please clarify, so I can clean up the confusing paragraph and
introduce
the optionality of the colon less jarringly.
Woot! :-)
Audrey
Re: Trying to use Perl5 modules
在 Sep 11, 2006 2:07 PM 時，Trey Harris 寫到： In a message dated Mon, 11 Sep 2006, Richard Hainsworth writes: I am trying to find out how to use (in perl6) perl5 modules that contain subroutines. Imports from Perl 5 modules don't currently work. Actually, explicit imports do work (as of a couple weeks ago): use perl5:Time::gmtime gmtime; say gmtime.wday; Implicit imports is not yet supported, though... Audrey
Re: single named param
在 Sep 12, 2006 6:59 PM 時，Gaal Yahas 寫到： What invocant is constructed in this signature then? method foo ($just_a_named_param) Is the signature for foo really the same as that of bar? sub bar ($just_a_named_param) As Larry said, they shouldn't be the same; the first one is foo.signature === :($ : $just_a_named_param); The second one is: bar.signature === :($just_a_named_param); I was sort of assuming you could tell by a signature if it was for a method or a sub. That's correct; the method keyword augments the signature with an unnamed $ invocant if it's not explicitly specified. (In Pugs.Val.Code terms, that's nullID for both the p_label slot and (v_name . p_variable).) Cheers, Audrey
Re: single named param
2006/9/12, Gaal Yahas [EMAIL PROTECTED]: Does this mean a single named parameter called $x, or a default invocant and a single required positional named $x? A default invocant prolly doesn't make sense there... There's nothing to default to. :-) Audrey
Reduced assignment operator?
Consider these cases: [=] $x, $y, $z; [+=] $a, $b, $c; S03 is currently inconsistent. It first says these are not supported: The final metaoperator in Perl 6 is the reduction operator. Any infix operator (except for non-associating operators and assignment operators) can be surrounded by square brackets in term position to But then implies it is on the defaulting table below: [=]() # undef(same for all assignment operators) I don't see an obvious problem in supporting them as a syntactic expansion. But would it be useful? And is there some hidden corners that I missed? Thanks, Audrey
Re: IO::Socket, or any IO
在 Sep 8, 2006 10:33 PM 時，Michael Snoyman 寫到：
Thanks Audrey. I actually found that after writing that post.
What I had wanted to do was write a threaded server, implemented in
Perl 6 only (ie, including Perl 6 regexs). I got that working
almost entirely, when I couldn't find any thread implementation. I
tried using fork() to get a same effect, but it seems that fork
also isn't available. Was I missing something, or are these just
features that I need to wait for?
async{} creates a thread:
my $thr = async { ... };
You can use the usual .join, .detach, .yield methods on it.
Thanks,
Audrey
Re: IO::Socket, or any IO
在 Aug 25, 2006 12:54 AM 時，Michael Snoyman 寫到： I was thinking of rewriting a little webserver program I wrote in Perl 5 using Pugs. I was wondering what the equivilent (if any) of IO::Socket is. I suppose I could use an external webserver and use CGI to get this working with IO, but my preference would be a pure Perl 6 approach. See examples/network/http-server.pl in the Pugs tree. :-) Cheers, Audrey
Re: multi method dispatching of optional arguments (further refined)
2006/9/4, Ph. Marek [EMAIL PROTECTED]: On Sunday 03 September 2006 14:25, Mark Stosberg wrote: Luke Palmer wrote: On 9/3/06, Mark Stosberg [EMAIL PROTECTED] wrote: Note that the variant /with/ the parameter can be considered an exact match, but but the variant /without/ it cannot be considered an exact match. Excuse me for getting into this thread with only minor knowledge about perl6, but will there be MMD based on the *value* of parameters? Like Haskell has. Why, yes, see the various Unpacking sections in S06, as well as where type constraints. We're st^H^Hadapting as much as we can. :-) Audrey
Re: Compiling pugs r12925 failed
2006/9/2, Markus Laire [EMAIL PROTECTED]: I tried to compile pugs r12925 with parrot r14364 (both current as of yesterday) and make for pugs failed with this message: Heya. r12925 is at the middle of gaal's mad hax0ring to support :(Sig) syntax in addition to \(Capt) syntax. Can you try again? Maybe remove blib6\lib\Prelude.pm.yml before typing make, too. Thanks! Audrey
Re: Compiling pugs r12925 failed
2006/9/2, Markus Laire [EMAIL PROTECTED]: On 9/2/06, Audrey Tang [EMAIL PROTECTED] wrote: 2006/9/2, Markus Laire [EMAIL PROTECTED]: I tried to compile pugs r12925 with parrot r14364 (both current as of yesterday) and make for pugs failed with this message: Heya. r12925 is at the middle of gaal's mad hax0ring to support :(Sig) syntax in addition to \(Capt) syntax. Can you try again? I get same error with r12939 (except that line 516 is now line 517) This is quite strange, as I cannot duplicate this failure mode; neither can others in #perl6. Nevertheless, I've attempted a fix. Can you try again with r12945? Thanks, Audrey
Re: Naming the method form of s///
2006/9/1, Juerd [EMAIL PROTECTED]: Luke Palmer skribis 2006-08-31 15:48 (-0600): I don't think using a method (even if called s) is good huffman coding. My expectation is that copying substitution will be used much - perhaps even more than mutating substitution! And so a method called s is poor huffman coding... why? (I do agree with your frequency conjecture) Because of the awkward syntax that goes with a method: two parens, four delimiters, comma[s]?. .s(/bar/, baz); # 20 keypresses on a US keyboard Minor nit, but: .s: /bar/,'baz'; # 17 keypresses... Audrey
Re: Where to put test for tr///?
2006/8/26, Mark J. Reed [EMAIL PROTECTED]: I noticed that tr/// doesn't currently exist in pugs. I want to add a test, but I'm not sure where it goes. My first instinct is to create a new tr.t in operators/, but I could also see adding it to builtins, or even to the trans test in string. So I thought I'd solicit opinions before diving in. String's trans.t seems like a good place to put it... Audrey
Re: Same-named arguments
2006/8/26, [EMAIL PROTECTED] [EMAIL PROTECTED]:
So what's the rationale behind the latest changes? I thought p6
consistently regarded the sigil as part of the name; seems like that
should go for named parameters, too. In fact, sigils would seem to be
a good way to distinguish named parameters from pairs.
Mostly, it's that func('x' = 1) requires a bit too much typing, and also
makes it hard for func() to change its signature later on to accept things
other than Code.
Alternatively, reserve either :k(v) or k=v for named parameters and
use the other for pairs. I don't see the value of conflating those two
things syntactically - is it just for compatibility with p5 modules
that take their parameters as hashes?
Indeed. Were it not for Perl5, I think forcing people to always write
:named($param) instead of named=$param is a cleaner solution.
The rationale behind autoquoting-as-named is that, the autoquoted
identifiers are the same set of names you can use on the signature line:
func(Some string with embedded space = $value);
would be taken as Pair, not named, because one cannot declare a
parameter name that contains space in func's signature line.
On the other hand, I'd have no problem with parens-disambiguation going
away, such that fx=1 means just f(x=1), and use f('x'=1) when
you mean a Pair.
Cheers,
Audrey
Re: pugs: rw block parameters
在 2006/8/25 上午 4:37 時，Larry Wall 寫到：
On Thu, Aug 24, 2006 at 03:11:10PM -0400, Mark J. Reed wrote:
: On 8/24/06, Larry Wall [EMAIL PROTECTED] wrote:
: On Wed, Aug 23, 2006 at 05:01:43PM -0400, Mark J. Reed wrote:
: : Sorry if this is a known question, but I didn't see it
mentioned in the
: : recent archive or FAQ.
: :
: : for ($a, $b) { $_ = ... }
: :
: : gives me a Can't modify constant item: VRef Scalar.
:
: Which is correct as the default.
:
: Not according to the spec. S04 says:
Oops, sorry, was confusing implicit $_ with explicit -$_. You are
correct.
And indeed I confused it as well. Fixed as of r12675.
Mark, can you add a test to t/statements/for.t? A commit bit is on
its way to your inbox. :-)
Thanks!
Audrey
PGP.sig
Description: This is a digitally signed message part
Re: === and array-refs
在 2006/8/18 上午 3:31 時，Ben Morrow 寫到： Just to make sure I've got all this straight: =:= compares names === compares containers eqv compares values =:= evaluates both sides as lvalue -- that's VAR() -- and compare them with ===. === evaluates both sides as rvalue and, for container (mutable) types, compares their pointer address. eqv evaluates both sides as rvalue and, for container (mutable) types, compares their content values. None of the three coerces their arguments to concatenated List (aka list flattening, aka slurpy context). So given an array @W, my @X := @W;# @X =:= @W my @Y = @W;# @Y === @W but @Y !=:= @W my @Z = @W.clone; # @Z eqv @W but @Z !=== @W Your Array example would be correct with the $ sigil: my $w = [1,2,3,4]; # Scalar containing Array my $x := $w; # $x =:= $w my $y = $w; # $y === $w but $y !=:= $w my $z = $w.clone; # $z eqv $w but $z !=== $w However, infix:= when its left-hand side is an array, has an different signature (and indeed, different precedence) than when its left-hand side is a scalar: my $y = $w; # does not flatten $w my @Y = @W; # does flatten @w, essentially doing a .clone my @Z = @W.clone; # same as my @Z = @W really. So the two assignments (@Y and @Z) above turns out to be the same thing, and neither will make === hold afterwards. Cheers, Audrey PGP.sig Description: This is a digitally signed message part
Re: designing a test suite for multiple implementations
在 2006/8/12 上午 3:01 時，jerry gay 寫到： for managed, i have a few ideas. currently, the suite lives in the pugs repo. this is a fine first approximation, but i believe it will soon be time to move this suite (it doesn't make sense to keep the official tests in a non-official repo in the long term.) It's available in the official repo: http://svn.perl.org/perl6/pugs/trunk/t/ If you'd like to change the mirror point to http://svn.perl.org/perl6/t/ That's fine. However, currently the commit bit to that directory does not make it easy for people to help out, and while we can do this through a test-pumpking that reviews each patches and commit by hand, I don't think that's a wise move to take. It's true that you need an openfoundry.org account to write tests for perl 6 may make people feel this to be less official. If we can get a good invitation system to hand out commit bits to svn.perl.org, I'm all for moving everything to there. Robrt had set one up for svn.perl.org/parrot/, but that is currently not actively promoted because of the policy that new committers to that directory has to sign TPF's Contributor License Agreement. If we can relax that policy for the perl6/ or perl6/t/ directory, so we can migrate the openfoundry committers over without them having to sign the CLA by paper -- digitally clickthrough would be fine -- then I agree that we can migrate everything to svn.perl.org. the question is, should it be moved into their own repository, or into the repo of the official perl6 implementation (if such a beast will indeed exist,) Currently the svn.perl.org repo is the most official-sounding one, by the domain name alone. (But I don't understand the motivation for putting the tests with the true implementation -- I thought the idea is to decouple the tests with any implementations.) So I think svn.perl.org is the right choice, if the admins are okay with a more relaxed commit bit policy there. Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: designing a test suite for multiple implementations
在 2006/8/12 下午 6:15 時，Nicholas Clark 寫到： There's nothing technical stopping the Perl 6 tests being on svn.perl.org, but in a different svn repository from the current repositories, is there? Well, technically yes, except that SVK doesn't support svn:external yet. Setting a svn:external property in the right place on both Parrot and Pugs would mean that both could check out the same testsuite, and both could commit back to it. That's assuming that the new repo, say, http://svn.perl.org/ perl6tests/, can give out commit permissions to parrot and pugs committers, yes. But as Jerry's initial motivation was moving Perl 6 tests to a more official location, and that http://svn.perl.org/perl6/ is the official repo for the Perl 6 design documents, I wonder what's the advantage of hosting the tests in a separate repository. Can you elaborate on that? Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: underscores in the core lib
在 2006/8/11 下午 2:35 時，Luke Palmer 寫到： I think that standard functions ought not to have underscores *most of the time*, because their presence indicates something that could be better named or is miscategorized. However, for methods, especially advanced or introspective methods, I think longer names that describe the action are better than short ones that only describe the action if you understand the pun. Huffman coding does not imply that *everything* is short. .SKID and the like are methods of Object, and as such should be considered part of the standard functions, as they are available to all terms. Methods for the other implicit-coerced-to types (Bit/Int/Num/Str/ List) share this concern; because all terms may be coerced implicitly into them, their methods also have unbounded visibility. For other built-in types, I think underscore names are just fine. For example, metaclass methods such as Class.has_method should indeed remain as such. :) Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: Array Definitions
在 2006/8/2 下午 2:48 時，Arthur Ramos Jr. 寫到： I'm new to the mailing lists. I've just started reading all the Apocalypse and Exegeses with the goal of becoming involved in some manner. Try reading the Synopses first. :-) The Apocalypses and Exegesis are no longer updated, and has diverged considerably with the current spec. One question I have is whether there will be a change to matrix coding. I'd personally like to see a simplification from the C coding. For example: Rather than (or in addition to) the C style: array[0][1][2] = 42; change it to (or allow the use of) the simplification: array[0,1,2] = 42; @array[0;1;2] is the current syntax; see S09 for details. Cheers, Audrey PGP.sig Description: This is a digitally signed message part
Re: [svn:perl6-synopsis] r9725 - doc/trunk/design/syn
在 2006/7/28 上午 7:54 時，Aaron Crane 寫到： The motivation for s/environmental/contextual/ is clear: avoiding a term that's already used for something else. But, on the same grounds, I'm not sure that contextual is the right term, and especially not Cis context -- Perl already has contexts, and this isn't one. The idea is that context is something you pass along in each of your calls. If your function body is a simple call, then it does not affect the context; the callee gets the same context as you are getting. So one can say that want is really one of the contextual variables that gets reassigned every time a function is called when a particular type is expected. Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: Patch for S03
在 2006/7/23 上午 7:33 時，Agent Zhang 寫到： Hello, everyone~ Here's my patch for S03. Thanks, applied (and the previous one on S02 too)! Audrey PGP.sig Description: This is a digitally signed message part
Re: Patch for S02
在 2006/7/19 下午 10:16 時，Agent Zhang 寫到： I found some nits while copying Perl 6 Synopsis 2 by hand. The patch created by my TortoiseSVN for S02 has been pasted at the end of the mail. Thanks, applied as r10314. Audrey PGP.sig Description: This is a digitally signed message part
Re: IMCC Reentrancy
在 2006/7/18 上午 1:54 時，Audrey Tang 寫到： If you have a way to make IMCC reentrant that involves upgrading to a more recent version of flex and passing one additional parameter, go for it! Send us a patch and if it passes all the tests, we'll apply it. As flex 2.5.30+ is not API compatible with the current flex IMCC is using, I wonder how it is different from re2c or regel, in particular that shoehorning an additional YYLEX parameter to make it work with bison will also involve overhauls beyond the original bison interface. I guess my question is: If I send two patches, of equal size, one uses re2c and is much cleaner and faster; another uses a kluged-up flex with its new, backward-incompatible reentrant API, would you reject one and apply the other? If you are willing to let alternative scanners go in, I'd much rather working on that instead of trying to work around the bison/flex interface. Code is easier for me to write than English. Hence: 09:22 @audreyt imcc scanner is now reentrant. 09:22 @audreyt I think it wouldn't take more than another hour to get it based on re2c 09:22 @audreyt but I'm willing to take what is felt more comfortable. :-) Audrey PGP.sig Description: This is a digitally signed message part
Re: IMCC Reentarancy
Vishal, 在 2006/7/16 下午 11:57 時，Vishal Soni 寫到： a. Remove flex and implement re2c b. Remove static and global variables Now that the flex part is done, are you still willing to help removing the remaining static/global state? Apart from this we also need to refactor the code to get rid of arrays to a hash table implementation for macros. This would rock, too. Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: [svn:parrot] r13343 - trunk/compilers/imcc
在 2006/7/18 上午 4:38 時，Allison Randal 寫到： [EMAIL PROTECTED] wrote: This is not a maintainable build solution. Revert and come back when you have one. Reverted. Audrey PGP.sig Description: This is a digitally signed message part
Re: Checkin #13345
在 2006/7/18 上午 4:49 時，chromatic 寫到： I don't believe there's a working heuristic for guessing which parameter the user failed to provide. That's why I didn't write the original version that way. Does r13347 look better? If not, please revert both my changes. As an aside, regardless of the three changes, this still segfaults: ./parrot -D 1 as does this: ./parrot '' Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: [svn:parrot] r13343 - trunk/compilers/imcc
在 2006/7/18 上午 4:38 時，Allison Randal 寫到： This is not a maintainable build solution. Revert and come back when you have one. Please clarify: What, exactly, is not maintainable? The presence of a .diff file, or the fact that it needs to be applied manually? If the latter, an extra line of Makefile rule suffices. If the former, a bison post-processor wrapper is needed. Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: [svn:parrot] r13343 - trunk/compilers/imcc
在 2006/7/18 上午 5:24 時，Audrey Tang 寫到： 在 2006/7/18 上午 4:38 時，Allison Randal 寫到： This is not a maintainable build solution. Revert and come back when you have one. Please clarify: What, exactly, is not maintainable? The presence of a .diff file, or the fact that it needs to be applied manually? If the latter, an extra line of Makefile rule suffices. If the former, a bison post-processor wrapper is needed. Assuming both were considered unmaintainable, fixed them, and committed again as r13348. I'd be willing to revert r13348 again if you find anything wrong with it, but a more specific response would be appreciated. Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: [svn:parrot] r13343 - trunk/compilers/imcc
在 2006/7/18 上午 6:21 時，Audrey Tang 寫到： 在 2006/7/18 上午 5:24 時，Audrey Tang 寫到： 在 2006/7/18 上午 4:38 時，Allison Randal 寫到： This is not a maintainable build solution. Revert and come back when you have one. Please clarify: What, exactly, is not maintainable? The presence of a .diff file, or the fact that it needs to be applied manually? If the latter, an extra line of Makefile rule suffices. If the former, a bison post-processor wrapper is needed. Assuming both were considered unmaintainable, fixed them, and committed again as r13348. I'd be willing to revert r13348 again if you find anything wrong with it, but a more specific response would be appreciated. The obvious wrong thing with it is that it doesn't come with a check for flex = 2.5.33. Joshua on #parrot said he'll fix that in the morning. Another obvious point was the resilience of the post processor against bison outputs. Fortunately, it appears that with bison = 2.2, multiple %lex-param is supported (though they need to be declared in separate lines, unlike %parse-param), and multiple %parse- param is also made available to all functions including the destructor. Hence if we can bump the version dependency of bison too, then this can work without source-level patching at all (committed as . So, is this maintainer-side dependency (bison 2.2+, flex 2.5.33+; does not affect the user) a reasonable cost for IMCC reentrancy? Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: flex/bison version for Parrot?
在 2006/7/18 下午 1:41 時，Chip Salzenberg 寫到： What versions of flex and bison will work now? I'd like to make Configure.perl (or perhaps the Makefile at runtime?) choke on -- maintainer if the right versions aren't found. Flex 2.5.33, Bison 2.2. Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: Checkin #13345
在 2006/7/18 下午 3:55 時，jerry gay 寫到： On 7/18/06, chromatic [EMAIL PROTECTED] wrote: On Tuesday 18 July 2006 02:21, Audrey Tang wrote: Does r13347 look better? If not, please revert both my changes. I think it's still misleading. #13364 is probably as accurate as Parrot can report. and has the distinction of compiling on windows, too :) # audreyt++ Actually, chromatic meant r13344, not r13364. Chromatic: Your original commit log noted room for possible improvements with the English message, which I interpreted as a invitation to help, and acted accordingly, but probably was mistaken, and thereby perceived as rude. I'm sorry about the miscommunication. I'd like to apologize publicly for saying that you can revert both my changes if you think it's stylistically bad English; I should have said I'd be willing to revert to r13344 if you find inaccuracies with it. I was already committing a revert to r13344, but it clashed with your r13367 a few minutes ago; for the record, I think your freshly-committed r13367 gives far better error message than either r13344 or r13364. It's very hard for me to write tests for English parts of a project, as they are often subjective calls. In this particular case, please forgive me for making a change without submitting as test+patch first to the mailing list, which I should have done in the first place. You would be correct to chide me for abusing my Parrot commit bit; from now on, I'll learn to avoid committing anything without a clear consensus from the parrot porters. Again, very, very sorry for causing your distress. It was not meant that way, and I'll learn to adjust my behavior. Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: IMCC Reentarancy
在 2006/7/17 下午 3:41 時，Joshua Hoblitt 寫到： 4th Option: fix flex. ;) Turns out flex 2.5.30+ has a reentrant mode. However, it also has an incompatible API with earlier flex, even in non-reentrant mode. I've attached a patch under http:// rt.perl.org/rt3//Public/Bug/Display.html?id=34669 (need flex 2.5.30+ to run) that updates imcc.l to deal with %option reentrancy and the additional yyscanner parameter. However, imcc.y currently only allows one additional param to be passed as YYLEX_PARAM, and it's already taken by the Parrot interpreter, so until we put yyscanner into the interp somehow, or change the generated bison parser, this wouldn't work. As I'm writing this, I noticed that Allison has ruled that we go with PIR/PGE and eventually C-based libpge instead -- since a lexer refactoring that doesn't affect the IMCC API will somehow throw important projects on Parrot into a dead stall, and thread safety for PIR compilation is not a 1.0 goal anyway -- I'll abandon working on this, and focus on helping getting a C-based libpge started instead. :-) Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: IMCC Reentrancy
在 2006/7/18 上午 1:21 時，Allison Randal 寫到： LOL :) Audrey, I love you dear, but you always have an interesting way of interpreting what I say. :) Yes, I'm not willing to start a 6+ month project to gut IMCC. The cost is too great and the benefit isn't great enough. Indeed, and I'd like to apologize publicly for the snipping. However, the re2c or regel-based scanner refactoring isn't different from a flex upgrade patch, as it (by definition) can't affect IMCC's public API at all. An additional advantage is that they will let us rid of the flaky API situation with flex. In any case it wouldn't take 6 months. In vsoni's original words: a. Remove flex and implement re2c b. Remove static and global variables And you answered: The cost/benefit balance on this solution is not good. A lot of people are depending on IMCC now, and a refactor of that magnitude will throw several important projects on Parrot into a dead stall. So, my answer is: No. It will involve overhauls, but again, the public interface -- at bison level and above -- cannot break. So the dead stall ruling -- effectively dismissing re2c and other scanner alternatives instantly -- strikes me as extremely surprising. If you have a way to make IMCC reentrant that involves upgrading to a more recent version of flex and passing one additional parameter, go for it! Send us a patch and if it passes all the tests, we'll apply it. As flex 2.5.30+ is not API compatible with the current flex IMCC is using, I wonder how it is different from re2c or regel, in particular that shoehorning an additional YYLEX parameter to make it work with bison will also involve overhauls beyond the original bison interface. I guess my question is: If I send two patches, of equal size, one uses re2c and is much cleaner and faster; another uses a kluged-up flex with its new, backward-incompatible reentrant API, would you reject one and apply the other? If you are willing to let alternative scanners go in, I'd much rather working on that instead of trying to work around the bison/flex interface. - A version of PGE written in C is a good idea, because it will spread Perl 6 regexes/grammars far and wide. (It will be difficult, because of all the Parrot features that will have to be reimplemented in a standalone PGE. But, it is possible.) Well, as discussed in #parrot, an offline-parser (i.e. one that does not permit changes to the gramamr during parsing) with rule syntax can be much more easily generated as a C-emitter backend from either PIR/PGE or Perl5/PCR. I'm looking into it with vsoni right now,. Audrey PGP.sig Description: This is a digitally signed message part
Re: IMCC Reentarancy
在 2006/7/16 下午 11:57 時，Vishal Soni 寫到： a. A clean implementation rather than a prototypish implementation I think that the lemon+re2c, being the more modern parsing tools, will make refactoring/hacking considerably easier. Whilst you are converting the current IMCC implementation into the new toolchain, you'll be in the best position to find out inconsistencies, to-be- deprecated spots, as well as best strategies to hack in new features, such as nested expressions and composable macros. So I'd regard the lemon+re2c refactoring as a good preparation step (synchronize with the PIR mindset) before a full-fledged rewrite. Once that's in place, the rewrite may be reachable via a set of gradual refactor+deprecation cycle, which will make transition much, much easier. Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: [perl #39796] [TODO] Implement .loadlib pragma in IMCC
在 2006/7/14 上午 5:26 時，Leopold Toetsch via RT 寫到： Err, t/dynpmc/dynlexpad.t is using .loadlib and is testing fine. Please try to provide a minimal parrot test showing the problem. Trying (though it remained a bit elusive), but if you make realclean, and then change languages/tcl/src/tclsh.pir so that it uses .loadlib instead of :immediate, and then make, cd into languages/tcl and make test, you'll notice that all tests fail with: # got: 'set_string_keyed() not implemented in class 'TclObject' # current instr.: '__prepare_lib' pc 19483 (runtime/tcllib.pir:122) # called from Sub '_main' pc 3 (src/tclsh.pir:42) Changing it back to :immediate makes tests pass again. Alternately, skipping the Parrot_register_HLL part in IMCC makes tests pass again. Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: [perl #39796] [TODO] Implement .loadlib pragma in IMCC
在 2006/7/14 上午 6:45 時，Audrey Tang 寫到： Changing it back to :immediate makes tests pass again. Alternately, skipping the Parrot_register_HLL part in IMCC makes tests pass again. After several rounds of trial-and-error, I've committed r13294 that works around the problem: * Tcl: Change back to .loadlib. Simply adding this line to tcllib.pir: .loadlib 'dynlexpad' appears to fix the problem. According to leo, .loadlib acts like a dummy HLL, so there is an order dependency to be observed by .loadlib calls. This may not be a problem if Parrot_register_HLL_type takes the HLL name instead of the current max HLL_idx, but the current state renders this workaround neccessary. So this ticket is probably good to be closed again, though it still leaves me somewhat puzzled. :) Audrey PGP.sig Description: This is a digitally signed message part
Re: _group in library name (was Re: r13272 - in trunk: compilers/imcc docs/imcc src)
在 2006/7/12 下午 9:38 時，Chip Salzenberg 寫到： On Wed, Jul 12, 2006 at 05:29:08PM -0700, [EMAIL PROTECTED] wrote: * Apply heuristics that tells .loadlib 'perl6_group' # HLL dynamic PMCs and .loadlib 'dynlexpad'# non-HLL dynamic PMCs apart, by locating the '_group substring inside the library name. Urque, that's really not OK even in the short term. Could you alter it to use an adverb: .loadlib 'perl6_group' :hll please? Started looking into it, but discovered that Leo has since fixed it, by having .loadlib deal with both cases properly, so there's no need for an adverb now. Thank, Audrey PGP.sig Description: This is a digitally signed message part
Re: [svn:parrot] r13270 - trunk/languages/perl6
在 2006/7/12 下午 8:16 時，Allison Randal 寫到： [EMAIL PROTECTED] wrote: Modified: trunk/languages/perl6/perl6.pir = = --- trunk/languages/perl6/perl6.pir (original) +++ trunk/languages/perl6/perl6.pir Wed Jul 12 17:05:26 2006 @@ -24,9 +24,7 @@ .namespace [ 'Perl6' ] -.sub '__loadlib' :immediate -$P1 = loadlib 'perl6_group' -.end +.loadlib 'perl6_group' .sub '__onload' :load $P1 = loadlib 'perl6_group' If Leo's comment about .loadlib being compile-and-runtime is already implemented, then you should be able to eliminate that runtime call to the loadlib opcode too. Indeed, though as I tested it (both at the time of the commit and at this moment), that appears to not be the case yet. Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: [svn:parrot] r13270 - trunk/languages/perl6
在 2006/7/13 上午 3:35 時，Audrey Tang 寫到： If Leo's comment about .loadlib being compile-and-runtime is already implemented, then you should be able to eliminate that runtime call to the loadlib opcode too. Indeed, though as I tested it (both at the time of the commit and at this moment), that appears to not be the case yet. Apologies; Leo did make it happen, it's just a make realclean is needed before it can take effect. I've taken out the extra loadlib call in :load in perl6.pir. Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: [perl #39792] [TODO] Deprecate :immediate in favour of .loadlib and .const
在 2006/7/11 下午 7:33 時，Chip Salzenberg via RT 寫到： Now think about the alternatives if your goal is to have the table ready to go at runtime without any computational overhead at all, e.g. a CRC table. And if we can restrict :immediate using some security principal in the future so it can only do things that are not destructive -- and always yield the same result -- in other words, do not depend on the environment, then this use would be totally fine. Your example is well within the realm of pure evaluation, and does not make use of unbounded (environment-dependent) evaluation. But I think this ticket can be morphed into once the security sandboxing is here, prevent :immediate to do something silly. Would you agree with that? I can create another ticket for .loadlib. Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: [perl #39792] [TODO] Deprecate :immediate in favour of .loadlib and .const
在 2006/7/11 下午 11:52 時，Bob Rogers via RT 寫到：
But by compile time you both unambiguously mean PIR compile time,
not HLL compile time, since there's no HLL involved. But an HLL
compiler always has the option of building a PIR constant at HLL
compile
time [2], so that just leaves the case of human-generated PIR. So it
seems that the real question is this: Does PIR have a need to be an
eval-during-compilation language in its own right?
Yes. :immediate is only useful for hand-written PIR, not compilers
targeting PIR;
contrary to the appearance, it is useless for implementing BEGIN{}-
like semantics for HLLs,
let alone unifying their semantics in some way.
So far we have been enable to produce a use case that requires
unbounded evaluation
that interacts with the environment during :immediate time. However,
Chip and Allison
already said they would like to reserve this feature for some future,
unanticipated
applications, and that it's okay for PIR tools to say we simply
break down under :immediate.
I really cannot argue with that argument (essentially let's punt and
see); therefore
this ticket is probably best reserved until Parrot actually has a
security model, in which
time I'll then argue that :immediate should be subjected to severe
restrictions.
Thanks,
Audrey
PGP.sig
Description: This is a digitally signed message part
Re: [perl #39792] [TODO] Deprecate :immediate in favour of .loadlib and .const
So far we have been enable to produce a use case that requires unbounded evaluation (typo, it's unable above.) PGP.sig Description: This is a digitally signed message part
[TODO] Implement .loadlib pragma in IMCC
Allison and Chip expressed their go-ahead with a .loadlib pragma, to replace this current use: .sub foo :immediate $I0 = loadlib XXX .end With this: .loadlib XXX This might be done as part of vsoni's IMCC refactoring, or as a lexer action that loads the library as soon as this directive is seen. In any case, this will let dependency checkers have a much easier time to figure out what dynamic libraries a .pir file is loading, without actually have to invoke Parrot themselves. Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: [perl #39792] [TODO] Deprecate :immediate in favour of .loadlib and .const
在 2006/7/12 上午 12:22 時，Chip Salzenberg 寫到： In short, to say that :immediate is unpredictable is to make a null statement, because in practice, all computation is unpredictable. Yes. And it is the designer's choice to introduce unpredictability into the PIR level. If the designer allows rand() inside :immediate, it's the designer's call; if the designer allows rm -rf, it's again the designer's call. There are degrees of unpredictability, and currently there is no evidence that we require any of it in hand-written PIR code. You ruled that we wait to see if a use case come up; that is fine with me. And hey, even if we reach consensus, there is no security model yet to implement any of this on, so I prefer to have this discussion when Parrot can actually tell rm-rf apart from rand(). Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: [perl #39792] [TODO] Deprecate :immediate in favour of .loadlib and .const
在 2006/7/12 上午 12:40 時，chromatic via RT 寫到： To follow this argument logically, I don't see alternatives besides removing :init or sandboxing all potentially destructive operations -- and I have plenty of Perl 5 code that legitimately deletes files in BEGIN blocks as evidence that this potential sandboxing is a fairly undecidable operation. I would like to see a single one example of that code. Please discard the histrionics; you're poisoning the well. No. If you think PIR is a language for people to write manually to code applications in, _and_ it has some legitimate use for deleting files in :immediate blocks, then your argument may make some sense. As you failed to produce even one example, I cannot see your point. Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: [perl #39792] [TODO] Deprecate :immediate in favour of .loadlib and .const
在 2006/7/12 上午 12:33 時，chromatic via RT 寫到： Because people might write code, by hand, that does careless things in :immediate subs? Yes. This is the difference between forcing syntax highlighters, security checkers, dependency analyzers, and refactoring browsers to run rm-rf, and let users run it. The _entire point_ of static analysis is that you can check for errors and faults before running it, from a safe standpoint. Saying that we kill the analyzers with :immediate in an intermediate language level -- that's meant for compilers to target -- without any useful thing we know of in return, is _very_ different from arguing the same thing for Perl 5. And some of the more dangerous parts of Perl 5 BEGIN -- for example filehandles in it leaking into the generated code, or action- at-a-distance compilation -- is considered a bug and prevented in Perl 6. Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: [perl #39792] [TODO] Deprecate :immediate in favour of .loadlib and .const
在 2006/7/12 上午 12:51 時，Allison Randal via RT 寫到： Chip Salzenberg wrote: [*] Just what it _is_ intended for is an open question. I think the user base will answer it, if we let them, in time. To give a concrete and immediately relevant example: the fact that people are using :immediate to load libraries at compile-time is a good sign to us that this is something they're likely to need often. (Chip and I both think .loadlib is a good idea, to canonize this common behavior.) The best way to promote the evolution of a system is to make evolution easy. That is a sane argument, which is why I think punt-and-see has some merit: as soon as there is a workaround forced to be expressed at :immediate level, we can evaluate it and see if it's better handled declaratively. Can we agree on the punt-and-see, neither-encourage-nor-deprecate resolution for now, then? Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: [perl #39792] [TODO] Deprecate :immediate in favour of .loadlib and .const
在 2006/7/12 上午 12:57 時，chromatic 寫到： On Tuesday 11 July 2006 21:45, Audrey Tang wrote: If you think PIR is a language for people to write manually to code applications in, _and_ it has some legitimate use for deleting files in :immediate blocks, then your argument may make some sense. Come on, Audrey! That's a strawman argument. The point is emphatically NOT that people should be able to delete files in :immediate blocks. As I said in my previous message, the same problem potentially exists with :init -- and saying OH NO THE PARROT DESIGNERS WANT TO REMOVE YOUR HARD DRIVE!! THEY ARE EVIL AND WRONG (and they break static analysis) is not productive. No. With :init, the step of .pir-.pbc, as well as all tools that works with .pir without running it -- including the very important parrot -o -- are safe. The :init is part of the run time. We already know that the runtime needs a sandbox at some point. What we don't know is that why the PIR compiler -- supposedly something that's run only when HLL compilation is done -- would need a special feature for hand-written code alone, and very error- prone at that. I can see use cases for :init to interact with the user's environment; I cannot see use cases for :immediate to interact with who-knows-what's environment, and break the otherwise intact same .pir compiles to the same .pbc on the same environment property. Allison and Chip already elected to wait a while and see if someone finds a use for it, that actually requires unbounded evaluation. I now agree with them. Please stop it. Er, that's what I'm planning to do. Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: [perl #39792] [TODO] Deprecate :immediate in favour of .loadlib and .const
在 2006/7/12 上午 1:12 時，Allison Randal via RT 寫到： Audrey Tang wrote: That is a sane argument, which is why I think punt-and-see has some merit: as soon as there is a workaround forced to be expressed at :immediate level, we can evaluate it and see if it's better handled declaratively. Excellent. (Er, though you know that .loadlib isn't really any more declarative than :immediate, right? It's a compile-time directive. That is, it performs an imperative action at compile-time, just like the equivalent 'loadlib' in :immediate.) It is declarative because it only has one surface form, and dependency analysis programs can easily parse that. Compare to :immediate, which is essentially impossible to grok correctly without using error-prone heuristics. So both are imperative in its effect; .loadlib is declarative and makes toolmaker's life easier, because if I want to extract this information, I'm not required to run unbounded arbitrary code. Can we agree on the punt-and-see, neither-encourage-nor-deprecate resolution for now, then? Pretty much. Though I'd phrase it as :immediate will not be deprecated. And we wholeheartedly encourage people to use :immediate wherever it solves their problem. That is fine. I meant we don't encourage people to use :immediate when a simple .loadlib would do -- we encourage them to use .loadlib instead. Glad to see speedy consensus. Thanks a lot for your time. :) Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: Dynamic (was discussion for #39711 -- [TODO] Make PIR-PBC reentrant)
在 2006/7/5 上午 12:15 時，chromatic 寫到： On Tuesday 04 July 2006 21:01, Audrey Tang wrote: Hence I'm puzzled why you raise the dynamic language categorization as a justification, for that term usually refers to dynamic typing, not to :immediate. If it is referring to :immediate, then Python/ Ruby/PHP would become static languages. :-) That doesn't quite seem fair; dynamic is a lot broader than just typing. Certainly any statically typed language with decent support for generic operations (or at least type-safe polymorphism) and a non-static loading scheme would be sufficiently dynamic. I can't point to an example of such a language, but there you go. Haskell with Language.Haskell.Eval and Language.C.Eval is one such language that I know of. However, allowing unbounded evaluation within the assembler cycle does not facilitate dynamic programming, so I'd still say it's entirely besides the point for the :immediate discussion. I agree there should be a static subset of functionality, that guarantees (or at least declares) that their result will not change across different runs, and those operations may be allowed in :immediate. In that sense it's not unlike the manifest sections in CLR, or constant table constructor instructions in many other runtimes -- TrueType fonts included. Assembler-level unbounded evaluation via :immediate (aka BEGIN) does not facilitate dynamic languages at all, up and including Perl 5. Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Perl 6 Summary: 2006-02-13 through 2006-02-28
was applied. Following a question from Leopold Toetsch, Nicholas made an argument for ensuring that the configure system is flexible enough to allow arbitrary combinations of cores, which Leopold agreed with. http://xrl.us/oxwm Replacing zero-arg invoke with one-arg Steve Fink asked if anyone would object to him eliminating the zero-arg invoke op in favor of a one-arg invoke. Leopold Toetsch noted it had been proposed before. Dan Sugalski requested that the zero-arg be kept and the one-arg added as long as there was explicit documentation. http://xrl.us/oxwn stabs support Steve Fink tried stabs for the JIT and was impressed, but noted a problem when stepping over a keyed op. Leopold Toetsch thought it looked like a gdb error. Steve added some debugging information to the documentation. http://xrl.us/oxwo Helpful emacs gud/perldb debugging tool Steve Fink offered a tool he'd been using for some time. http://xrl.us/oxwp Non-inline text in Parrot assembly Tupshin Harper asked if there are any plans to have Parrot assembly support a distinct .string assembly section. Leopold Toetsch and Gregor replied. http://xrl.us/oxwq IMCC's bsr handling Steve Fink reported that IMCC doesn't handle bsr with non- constant args. A couple of ways of addressing this were discussed, and Leopold Toetsch created a partial fix. http://xrl.us/oxwr Objects, methods, attributes, properties, and other related frobnitzes Dan Sugalski wanted to be clear on some points before he started to work. There was a discussion, primarily on method redefinition. http://xrl.us/oxws Access to partial registers Tupshin Harper asked if it is possible to read and write from a part of a register in PASM. Several people replied that it wasn't, and Tupshin clarified his requirements. http://xrl.us/oxwt Datatype of PMC, pre-built Windows binaries of Parrot David asked how to determine the datatype of a PMC and if pre-built Windows binaries of Parrot are available. He received a number of answers to the first question. http://xrl.us/oxwu String plan Dan Sugalski posted a plan for reworking strings. http://xrl.us/oxwv Patch for jit.c to stop compiler warnings Steve Peters tried to send a patch, but Nicholas Clark didn't receive it. http://xrl.us/oxww Problem creating new PMC type Klaas-Jan Stol ran in to difficulties when he tried to create a new PMC type. Leopold Toetsch offered advice. http://xrl.us/oxwx Required build infrastructure stuff Dan Sugalski posted a few things which are needed in the build infrastructure. http://xrl.us/oxwy Targeting Parrot tutorial Simon Wistow inquired on the current state of the tutorial, and offered an article he thought might be useful. Gopal V wasn't certain TreeCC was needed, and linked to an article he liked. http://xrl.us/oxwz Patch to fix compiler warnings in smallobject.c Steve Peters proposed a patch to fix warnings, but Leopold Toetsch preferred explicit casts to get rid of warnings. http://xrl.us/oxw2 Using imcc as JIT optimizer Leopold Toetsch posted conclusions on the experiment. http://xrl.us/oxw3 Patches applied Several patches were applied: * bf compiler from Leon Brocard http://xrl.us/oxw4 * macro expansion in imcc by Jürgen Bömmels, following a lengthy discussion http://xrl.us/oxw5 * Macros in imcc from Jürgen Bömmels http://xrl.us/oxw6 * Initialization of various function pointers in packfile.c from NULL to NULLfunc by Simon Glover http://xrl.us/oxw7 * life.pasm modification by Leon Brocard http://xrl.us/oxw8 * Art Haas posted a patch for examples/mops/mops.py, but there was no confirmation that the patch was applied. http://xrl.us/oxw9 * formatting fix for docs/dev/rx.dev by Cal Henderson http://xrl.us/oxxa Language (perl6-language) Typo Alert: Synopsis 5 Amos Robinson found a typo and Luke Palmer promptly corrected it. http://xrl.us/oxxb Implementation of :w in regexes and other regex questions David Romano asked some questions on extending the Rules domain specific language, the semantics of whitespace skipping, and negated matching semantics. Luke Palmer replied and explained that the extensions were not yet specified, and recommend possible solutions to the other two questions. Discussion ensued. http://xrl.us/oxxc Overloading the variable declaration process Darren Duncan wondered if he could get default values in variables instead of undef, in order to avoid calling the constructor, by simply annotating the type of the variable. Audrey Tang explained that a similar construct
Re: namespaces, a single colon to separate HLL prefix?
在 2006/7/6 上午 3:30 時，Allison Randal 寫到：
Quick question, is there a syntax specified in Perl 6 for referring
to namespaces from other languages?
I'm reviewing the namespaces PDD and want to update this snippet:
--
IMPLEMENTATION EXAMPLES: Suppose a Perl program were to import some
Tcl module with an import pattern of ``c*'' -- something that might
be expressed in Perl 6 as use tcl:Some::Module 'c*'. This operation
would import all the commands that start with 'c' from the given
Tcl namespace into the current Perl namespace. This is so because,
regardless of whether 'c*' is a Perl 6 style export pattern, it is
a valid Tcl export pattern.
{XXX - Is the ':' for HLL approved or just proposed? Somebody
familiar with Perl 6 please fix the example in the preceding
paragraph to use the currently planned syntax for importing modules
from other languages.}
--
The : form is approved and canonical (line 303, the Modules spec, aka
S11.pm version 14).
use perl5:DBI;
However, currently it's only available at use/require line.
Afterwards, the user simply say:
my $dbh = DBI.connect(...);
Though I think this:
my $dbh = perl5:DBI.connect(...)
can be made to work, as it's currently parsefail, thought there is a
marginal case:
my $dbh = perl5:DBI; # currently parsed as perl5(:DBI)
but we can say that for each HLL-qualified module name, it's a single
token and is therefore recognized first.
Does that sound sane? If yes, S11 can be updated to reflect that.
Thanks,
Audrey
PGP.sig
Description: This is a digitally signed message part
Re: [perl #39711] [TODO] Make PIR-PBC reentrant
在 2006/7/5 上午 3:06 時，Allison Randal 寫到： Audrey Tang wrote: But I guess this bug ticket is not an appropriate place... Indeed. We need a Document :immediate ticket. I already filed that as #39716 a few hours ago; also #39715 and #39714, as per your suggestion: [TODO] Document IMCC's :immediate feature [TODO] IMCC errors should throw Parrot exceptions [TODO] Refactor IMCC to remove static globals As I cannot modify links on rt.perl.org, can you do that for me? Thanks, Audey PGP.sig Description: This is a digitally signed message part
v6.pm now runs Test.pm!
(Cross-posted from http://pugs.blogs.com/pugs/2006/07/ v6pm_now_runs_t.html) Due to clkao++ and fglock++'s work, the CPAN version of v6.pm now passes all Pugs sanity tests, up and including the Perl 6 Test.pm: # http://search.cpan.org/dist/v6-pugs/ # http://search.cpan.org/dist/v6-pugs/t/ That makes it the second implementation (after Pugs) and the fourth runtime (after Pugs's Haskell/JavaScript/PIR backends) that has access to the 11,000+ subtests in the test suite. Once the Parrot/ Perl6 implementation support for subroutines, arrays, hashes and use statements, it will join as the third implementation that can run the test suite. Development of v6.pm, the new AST, a concrete definition of multiple dispatch, etc. continues apace in #perl6; we are seeing nearly more than 50 commits per day in the past few days. (gaal++ describes it's just like the good old days of early Pugs development, but it's actually faster. now :-)) For example, v6.pm can now parse regex/ token/rule declarations natively. I'm very excited about this new cleanly-partitioned task space of Perl 6 implementation: (Non-Perl 5 Specific) * Descriptions of semantics in the test space; * Analytical summaries and stories in the spec space; * Algorithmic expression of effects and structures in the new AST space; (Perl 5 Specific) * Implementation APIs to embed them as Perl 5 modules; * Idiomatic, pure-perl5 sugar that makes Perl 6 semantics accessible; * Translation from Perl 6 surface syntax into those new perl 5 idioms; And the best thing is that, instead of a cyclic dependency as we had before, each layer are independent from the ones after it. It means that CPAN people can use Class::MOP and Data::Bind to improve their own frameworks; or to use the new idioms enabled by Moose.pm et all; all without necessarily switching to the Perl 6 surface syntax. And it also makes v6.pm's output idiomatic -- we just need to incrementally build a new Perl 5 idiom, which, as Bjorn Freeman- Benson noted, is a Very Good Thing. PGP.sig Description: This is a digitally signed message part
Re: Perl 6 compiler docs released - graffle questions, compiler questions
在 2006/7/5 上午 1:26 時，George Wood 寫到： Here are some probably for Audrey... 1. Page on Perl 6 on Haskell - Is runtime Specific AST actually the file Language.TH.Sytnax? Well, no, it's probably best to call it Pugs.AST, and link to src/ Pugs/AST.hs. 2. I am still trying to distinguish these Perl 6 on Perl 6 Perl 6 on Parrot Do they both emit pmc files? Perl 6 on Parrot will emit .pir files. Perl 6 on Perl 6 will emit .p6 files, but currently no such implementations exist, as it's still a few milestones away from now. :-) Thanks! Audrey PGP.sig Description: This is a digitally signed message part
Vanilla Perl, Win32, and Data::Bind support.
Hi Flavio: You asked me on #perl6 to build a Data::Bind binary distribution for Win32-ActivePerl. After working on it for 2 hours, I (re)discovered that it's impossible to do that, using the current generation of gratis downloads of Visual Studio C++ Express 2005, as it seems that Perl does not yet support the new manifest-driven deployment style with the msvcr80.dll prerequisite. Therefore I've built it on VanillaPerl build 3, with the dmake that comes with it: http://win32.perl.org/wiki/index.php?title=Vanilla_Perl Adam Kennedy and friends will probably release StrawberryPerl in a couple weeks, in which case it'd be nice to switch to it: http://win32.perl.org/wiki/index.php?title=Strawberry_Perl But for now, please install VanillaPerl-3, and extract this zip file to your C:\vanilla-perl\perl\: http://perlcabal.org/~audreyt/tmp/c-vanilla-perl-perl-site.zip It should create a site directory with an already-built Data::Bind. To build a newer Data::Bind from the Pugs tree, simply perl Makefile.PL ; dmake install from perl5/Data-Bind/. (Cc'ing perl6-compiler for other Win32 people who want to help out v6.pm development but has no VC++ 6.0 installed.) Thanks, Audrey PGP.sig Description: This is a digitally signed message part
[ANNOUNCE] Pugs 6.2.12 and v6.pm released! (reformatted)
(Mail.app totally scrambled the previous mail; sorry about this re- post.) I'm glad to announce that Pugs 6.2.12 is now available from CPAN: http://search.cpan.org/dist/Perl6-Pugs-6.2.12/ SIZE: 2693459 SHA1: c9731da8e597591ca7e279766481ce0bece8cfa4 This release features much better performance: Building Pugs is 3 times faster; compiling Perl 6 programs becomes 10 times faster; running Perl 6 programs is now up to 2 times faster. We also support various Perl 6 syntax changes since the last release, as well as exciting new features, such as atomic code blocks with Software Transactional Memory (STM) semantics. See the full change log for additional details of what's new in 6.2.12: http://pugs.blogs.com/pugs/2006/07/release_announc.html#more 6.2.12 marks the last release with the 6.0.x abstract syntax tree (AST) to represent Perl 6 programs. We are currently switching to a new AST that supports the new Signature/Capture calling convention, multi-dispatch with constraints, and a full Meta-Object Protocol (MOP). We are developing this new runtime simultaneously as Haskell modules and Perl 5 CPAN modules, to ensure that they have identical semantics. To this end, I'm happy to announce that v6.pm, a prototype Perl 6 Compiler implemented entirely in Perl 5, is also available from CPAN: http://search.cpan.org/dist/v6-pugs/ All Perl 5 components are released as separate CPAN modules. One can use them as pure-perl5 modules, to get fully-conformant Perl 6 features without the need of using Perl 6 syntax provided by v6.pm. (These CPAN modules maintain their own release cycles; we will release more components on CPAN as they are abstracted out from the Pugs runtime.) The .meta API for Object/Class/Method reflection is supported by the Moose and Class::MOP modules: http://search.cpan.org/dist/Moose/ http://search.cpan.org/dist/Class-MOP/ The compiler and runtime for Perl 6 Grammars (top-down) and operator precedence (bottom-up) is available as the Pugs::Gramamr::Rule and Pugs::Grammar::Precedence modules: http://search.cpan.org/dist/Pugs-Compiler-Rule/ The calling convention with named, optional, and slurpy arguemnts is supported by the Data::Bind module: http://search.cpan.org/dist/Data-Bind/ The precompile-Perl6-to-Perl5 mechanism is based on Module::Compile, a safe and composable replacement to source filtering: http://search.cpan.org/dist/Module-Compile/ http://search.cpan.org/dist/Filter-Simple-Compile/ In summary: Perl 5 is now a first-class virtual machine for Pugs, and in this journey toward self-hosting, we will share as much common structure as possible between the Perl 5, Haskell, and the Parrot runtimes. With a prototype end-to-end implementation written in pure Perl 5, we are entering the Hack, Hack, Hack phase of the (imaginary) Perl 6 timeline from nearly one year ago: http://pugscode.org/images/timeline.png I'd like to thank Flavio Glock for initiating and leading the v6.pm effort, and all lambdacamel and lambdamoose on irc.freenode.net #perl6 for their relentless enthusiasm in getting Perl 6 deployed to the Real World. See you on IRC! Audrey PGP.sig Description: This is a digitally signed message part
Re: [perl #39711] [TODO] Make PIR-PBC reentrant
在 2006/7/4 下午 8:50 時，Allison Randal via RT 寫到：
The :immediate feature isn't really a question of reentrancy (it
doesn't
hold static data over successive calls, and it doesn't return a
pointer
to static data).
That depends on the :immediate code. The equivalence of
BEGIN { $Static::data++ }
is possible through :immediate interface, and successive Parrot
execution and/or IMCC compilation can be affected.
In that regard is it as bad as having static globals.
Many languages-under-development may start out interpreted
and then move to compiled (punie, pheme, and TGE itself have all
followed this path). It's an easy way to get started on a language
implementation.
Yet none of Punie, Pheme nor TGE make use of :immediate, so I'm not
sure how this sentence relates to the question.
I do agree that taking a try-and-see attitude is a valid option; in
that case we can simply declare nothing but Parrot can work with
PIR, in the same way that nothing but perl5 can work with Perl 5.
Thanks,
Audrey
PGP.sig
Description: This is a digitally signed message part
