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
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: 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: 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: Conceptual questions about Objects
John M. Dlugosz wrote: Seriously, Does this mean that the access of private attributes from trusted classes is a different form? And that's why you need the qualified syntax when I think it should not be necessary in all cases? Or should that passage really say not in non-trusted classes, including derived classes? It's a different form. Line 1207: (Private accessors are never virtual, and must be package qualified if called from a trusted scope other than our own. That is, it's either Cself!attr() or C$obj!TrustsMe::attr().) The reason is, I suspect, that what trusts does is putting a !TrustsMe::attr() into the trustee's scope, instead of somehow shadowing its own !attr() symbol. 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: 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: 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
[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: 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: 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 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: 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
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: 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: 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: 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: === 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 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: 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: S04
在 2006/7/1 下午 6:08 時，Tom Allison 寫到： I picked this up at the YAPC and made some markups on it. Apologies that it is not in a diff format, but that's going to come with practice. ... is there a file attachment somewhere? :-) I got stuck on some of the intended behaviors and prohibited behaviors of the 'goto' function. For the purpose of clarity would it be useful to provide a series of specific test cases (in perl 5) to identify what it does today and what (if anything) it will do differently? Yes, that would be very useful. The Pugs t/builtins/control_flow/ goto.t in particular needs to include all the S04 forms; I have sent you a commit bit -- please checkout http://svn.openfoundry.org/pugs with Subversion, add yourself to AUTHORS, and change/augment goto.t to include those test cases. Thanks! Audrey PGP.sig Description: This is a digitally signed message part
Re: lexical lookup and OUTER::
在 2006/6/24 上午 8:41 時，Patrick R. Michaud 寫到： because later in the scope $x may be declared, so it's safer to just put OUTER right there. I don't think $x can be declared later in the scope. According to S04, If you've referred to $x prior to the first declaration, and the compiler tentatively bound it to $OUTER::x, then it's an error to declare it, and the compiler is allowed to complain at that point. Hmm, looks like it's been changed this April. In that case, indeed the emitter can safely remove the implicit OUTER calls. Pugs's Parrot backend has been updated accordingly. Thanks! (...and Cc'ing p6l for the part below) However, the spec wording is ambiguous: $x = 1 if my $x; The compiler is allowed to complain, but does that means it's also okay to not die fatally, and recover by pretending as if the user has said this? # Current Pugs behaviour $OUTER::x = 1 if my $x; If it's required to complain, then the parser need to remember all such uses and check it against declaration later, and it'd be better to say that in the spec instead. Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: About default options ':ratchet' and ':sigspace' on rules
在 2006/6/3 下午 3:03 時，Shu-Chun Weng 寫到： I'll then rewrite most of my rules into tokens. And about the definition of ?ws, the engine I mentioned is Pugs::Complier::Rule, so that if what PGE does is considered the correct way, I will change the behavior of P::C::Rule. Yes, please do. :-) By the way, if someone can add it to S05 would make me more comfortable. Done as r9442. Cheers, Audrey
Re: ACID transactions for in-memory data structures
Rob Kinyon wrote: I'm pretty sure it wouldn't be very feasible to do this natively in P5. But, would it be possible to do it natively in P6? As in, supported within the interpreter vs. through some sort of overloading. Look at is atomic in S17draft, and Software Transaction Memory in general? Audrey signature.asc Description: OpenPGP digital signature
Re: A rule by any other name...
Patrick R. Michaud wrote: - sp is a single character of obligatory whitespace Hmm, it's literal ' ' (that is, \x20), not whitespace in general, right? For obligatory whitespace we have \s. This one has bugged me since the day I first saw it implemented in PGE. We _already_ have \s, blank, and space to represent the notion of a whitespace character -- do we really need a separate sp form also? (An idle thought: perhaps sp is better used as an :sp adverb and a corresponding ?sp regex?) Well, without /?sp/ to stand for /\x20/, it'd have to be written as /' '/, which is a bit suboptimal. Or as /\ /, which is even more suboptimal... Audrey signature.asc Description: OpenPGP digital signature
Re: A rule by any other name...
Ruud H.G. van Tol wrote: Are all or some of the following equivalent to sp? U+00A0 No-Break Space U+202F Narow No-Break Space U+FEFF Zero Width No-Break Space U+2060 Word Joiner No. A05 makes it explicit sp is just \x20, and S05 also says that it matches one space char, which also means U+0020 SPACE, although more vaguely. I think S05 can use this clarification diff: - / sp /# match a space char + / sp /# match the SPACE character (U+0020) Thanks, Audrey signature.asc Description: OpenPGP digital signature
Re: A rule by any other name...
Allison Randal wrote:
More importantly, whitespace skipping isn't a very significant option in
grammars in general, so creating two keywords that distinguish between
skipping and no skipping is linguistically infelicitous. It's like
creating two different words for shirts with horizontal stripes and
shirts with vertical stripes. Sure, they're different, but the
difference isn't particularly significant, so it's better expressed by a
modifier on shirt than by a different word.
This is not only space skipping; as we discussed, ws skips over
comments as well as spaces, because a language (such as Perl 6) can
defined its own ws that serves as valid separator. To wit:
void main () {}
void/* this also works */main () {}
Or, in Perl 6:
say time;
say#( this also works )time;
From a practical perspective, both the Perl 6 and Punie grammars have
ended up using 'token' in many places (for things that aren't tokens),
because :words isn't really the semantics you want for parsing computer
languages. (Though it is quite useful for parsing natural language and
other things.) What you want is comment skipping, which isn't the same
as :words.
Currently it's defined, and used, the same as :words.
I think the confusion arises from ws being read as whitespace
instead of as word separator. Maybe an explicit wordsep can fix
that, or maybe rename it to something else, but the token/rule
distinction of :words is very useful, because it's more usual for
languages to behave like C and Perl 6, instead of:
ex/* this calls exit */it();
which is rarer, and can be treated with separate token rules than ws.
Audrey
signature.asc
Description: OpenPGP digital signature
Re: A shorter long dot
Austin Hastings wrote: Or, to put it another way: what hard problem is it that you guys are actively avoiding, that you've spent a week talking about making substantial changes to the language in order to facilitate lining up method names? That's a very good point too. Initially it's just a cute idea for filling in the 2-character method invocation gap, as well as making $x.+method and $x.:method line up, but it's probably not worth people's time in arguing this any further... Consider my suggestion retracted, and sorry for the disturbance in the force. :) Thanks, Audrey signature.asc Description: OpenPGP digital signature
Re: =$fh vs *$fh
Larry Wall wrote:
On the other hand, - makes a pretty pathetic fish operator. So for
the sake of argument, let's keep it = for the moment. But ignoring the
tail leads us to the head end of the fish. What do we do about $ARGS?
We could say this:
=$fh : *$fh :: = : *
Now if you analyze * as a unary * plus a null list, it's obviously
stupid to be interpolating 0 arguments at this point, so pragmatically
speaking something else is meant by this utterance, and we could make
it mean read all the lines of $ARGV easily enough.
On the other hand, maybe * plus a null list, namely *(), has a higher
purpose, where it can mean *$/, which is very very very useful. To wit:
grammar Java;
rule statement {
| block
{ Block.new(*()) } # Java::Block.new(block = $block)
| if \( $cond := expr \) statement
[ else $else_statement := statement ]?
{ If.new(*()) }
| for \(
init ;
$cont := expr? ;
$next := expr
\)
statement
{ For.new(*()) }
| ...
}
I think *() above is more visually distinct than *$/.
(Presumably the @ forms would be for rvalue use only--at least till MJD
gets ahold of them--but I don't think that's terribly important one way
or the other in a huffman fight.)
Lvalue @$fh can be fun too indeed, but I guess it depends on how the $fh
is constructed. :-)
Another option is to just give up on the meme. We just invented the
Whatever token *, so maybe in an iterator context Whatever means $ARGS.
Then we get =* as reading a line from $ARGS, and @* perhaps as reading
all the lines, or @(*) if you're worried about the twigilhood of *.
I think I like this alternative best. The meme never really felt
comfortable to me, as the empty string-list magic may be too much magic.
If we do say that $fh.as(Array) pulls all the lines from the
iterator destructively (though lazily), then it logically follows
that $fh.as(Scalar) pulls one line. Which means instead of
say(=$fh, =$fh, =$fh); # print three lines
you'd just say
say($$fh, $$fh, $$fh); # print three lines
One problem is that while repeated @$fh conceptually returns the same
thing, $$fh here would iterate instead of merely dereference, which
makes it carry its own state. If = means something like each(%kv)
in Perl 5, and we get [EMAIL PROTECTED] as well for iterating over elements,
then
it makes more sense for that purpose for =$fh as well.
Thanks,
Audrey
signature.asc
Description: OpenPGP digital signature
=$fh vs *$fh
During my S03 cleanup today, I noticed that because *$fh and **$fh
interpolates into the current argument list, it's always the same as
=$fh under list context. So I wrote this paragraph:
[Conjectural: File handles interpolates its lines into positional
arguments (e.g. to Cstatement_control:for), so we can make C=$fh
always return the next item, regardless of the context:
for *$fh - $line { ... }; # read one line at a time
for **$fh - $line { ... }; # read up all lines first
say(=$fh, =$fh, =$fh); # print three lines
]
However, this will mark a departure from the context-sensitive use of =$fh:
say =$fh; # prints everything
=$fh ~~ /.../; # reads just the first line
So, I wonder if the = operator can always just mean return the next
thing, and leave the Perl5-esque context-sensitiveness to the
readline() function. I've written (scalar FH) many times in Perl 5
code, and I wonder if a reliably-scalar-context iterator can be a win
here... Thoughts?
Thanks,
Audrey
signature.asc
Description: OpenPGP digital signature
Re: Capture Object: why no verb?
Dave Whipp wrote: Also, I'm a bit confused By the idea that the invocant is obtained by a scalar dereference, because I know that arrays and hashes can be invocants, too. E.g. @a.pop. So, If I do: my $args = \(@a:); my $b = $$args; # @a as a scalar my @c = @$args; # empty list my @d := $$args; # bound to @a That is totally correct. Scalar here really means any one thing, any Array is but one kind of one-thing. Is there any way that a deref can determine that the invocant stored in the capture was placed there using the '@' sigil? Perhpas this leads to the question of whether there is ever a reason for code to distinguish between @ invocants and $ invocants. I'm guessing that the answer must be no. No. If you really want to flatten at list context the content of invocant, then @$$args will do what you want, though it's a bit heavy. :) Audrey signature.asc Description: OpenPGP digital signature
The parse composer
[EMAIL PROTECTED] wrote:
+=item *
+
+Just as Crx has variants, so does the Crule declarator.
+In particular, there are two special variants for use in grammars:
+Ctoken and Cparse.
After a brief discussion on #perl6 with pmichaud and Juerd, it seems
that a verb parse at the same space as sub/method/rule feels
quite confusing:
grammar Foo {
parse moose {...}; # calling parse?
}
my $elk = parse {...}; # calling parse?
We feel that the token:w form is short enough and better reflect the
similarity:
grammar Foo {
token moose :w {...}
}
my $elk = token:w {...};
If further huffmanization is highly desired, how about allowing adverbs
at the beginning of token/rule forms?
grammar Foo {
token:w moose {...};
rule:P5 foo {...};
}
That would make it stand out, without further consuming the reserved
word space.
Thanks,
Audrey
signature.asc
Description: OpenPGP digital signature
Re: [svn:perl6-synopsis] r8883 - doc/trunk/design/syn
Patrick R. Michaud wrote: Two other ideas (from a short walk)... how about something along the lines of phrase or sequence? Parsec use the word lexeme to mean exactly the same thing... Audrey signature.asc Description: OpenPGP digital signature
Re: Capture Object: why no verb?
Dave Whipp wrote:
Perhaps I'm not fully groking the abstraction of the capture-object, but
it seems to me that there should be a slot in it for the method. For
dispatch, all three things are needed (invocant, method, args); so if
you're going to put two of them in one object, then maybe the third
thing belongs, too.
Hm, Perl 6 actually has two different ways of putting Capture to some
Code object... Following yesterday's P6AST draft I'll call them Call and
Apply respectively:
moose($obj: 1, 2); # this is Call
moose.($obj: 1, 2); # this is Apply
elk(named = 'arg'); # this is Call
elk.(named = 'arg'); # this is Apply
The difference is whether the Code is an object (Apply), or a message
name (Call). As the same argument list can be reused in both cases, it
seems the method part is better left out from the abstraction. That
allows:
my $cap = \(Hello, World);
outs(*$cap); # Sub Call (may optimize to Apply if outs is lexical)
$fh.say(*$cap); # Method Call
$output(*$cap); # Apply
This also makes multiple Captures easily composable:
say(*$cap, *$cap, *$cap); # HelloWorldHelloWorldHelloWorld
P6C
Of course, if we go all Smalltalkish, we can say that Apply is merely
sending the postcircumfix:( ) message to the Code object, so that we
can treat _everything_ as a closure by defining:
# Below demonstrates a (IMHO) bad idea
sub postcircumfix:( ) ($inv: \$cap) { say Foo! }
1.(); # Foo! - method call falling back to sub call
But this defeats common closure-based optimizations, and penalizes
functional programming style for no apparent gain, so I think the
method-full form and method-less form are still better separated in the AST.
/P6C
Audrey
signature.asc
Description: OpenPGP digital signature
Capturing the Captures.
As promised yesterday, today gaal and I entered a gobby Q/A session, producing the first document under the Perl6::FAQ tree, on the newly coined Capture objects (previously known as Arguments) objects: http://svn.openfoundry.org/pugs/docs/Perl6/FAQ/Capture.pod A HTMLized version is also available online: http://pugs.blogs.com/pugs/2006/04/perl6faqcapture.html With gaal's clearly-worded, carefully probing questions, I found myself discovering unforeseen consequences of the new design -- e.g. @y := (1,2,3) is actually an error, and one would need to say [EMAIL PROTECTED] := (1,2,3) instead. Fortunately, the design seems to stand against the scrutiny. So after TimToady reported consent from @Larry on the s:g/Arguments/Capture/ name change, I committed that to the Synopses. As this represents a rather drastic departure from Perl 5's model, I'd very much welcome reviews, comments, as well as more questions -- please feel free to commit directly to the FAQ file, and we'll pick up from there. :-) signature.asc Description: OpenPGP digital signature
Re: [svn:perl6-synopsis] r8573 - doc/trunk/design/syn
TSa wrote: Note that a prominent, typical foo actually reads: self .bar; And a self($_.bar) is pretty much useless. In other words wrongly huffmanized. FWIW, I agree with both points. Some more points: * I think both say(.meth) or .meth.say are more succinct/readable than say .meth for say($_.meth). * say() .meth is a parsefail according to the new rules, but can be quite useful to align things up. I committed r8573 only because of r8563 changed the dot/whitespace interaction, which caused inconsistencies in other parts of the example... The old interaction rules imho is quite easier to explain. Audrey signature.asc Description: OpenPGP digital signature
Re: S06 Splicing clarification
Brad Bowman wrote: and against the spirit of the my $COMPILING::x in earlier versions of S06. Regardless of the not a block status of a q:code, I think that it's lexicals should only be visible within the q:code by default. If this is the intention of the above phrase the it should be made clearer. Indeed the design is intentionally unhygienic; I couldn't find an easy way for default-hygienic to turn into unhygienic (we do need unhygienic macros sometimes), and there's a very easy way to turn default-unhygienic to hygienic ones (just add another pair of curlies). I'm not particularly happy with this; another thought is for q:code to be hygienic by default, but introduce a q:code(:no_scope) or q:code(:leak) or q:code(:unhygienic) or some other flag to remove the implicit scoping. Would that be a saner default? :-) Audrey signature.asc Description: OpenPGP digital signature
Re: A proposition for streamlining Perl 6 development
Yuval Kogman wrote: What I do think is that there is something in the middle of these two big questions, and they are: * How will the Perl 6 compiler be designed (parts, etc) That... was what Pugs Apocrypha was meant to contain, with PA02 being a design overview, and PA03 onward documenting the various parts with their interfaces. But English is not my forte (by far), and the last time you and I worked toward it, it resulted in a jargon-filled document largely inaccessible to a casual participant. So that needs to be fixed. I'll be in Tel Aviv in 5 days (thank $deity), and I'd be very willing to work with you on this before the Hackathon starts. Audrey signature.asc Description: OpenPGP digital signature
Re: A proposition for streamlining Perl 6 development
On 2/8/06, Yuval Kogman [EMAIL PROTECTED] wrote: If Audrey is willing, I think a correct new direction for pugs is to try and separate the parts even more - the prelude is a mess right now, many of it's part are duplicated across the backends, the standard library that is mashed into the prelude, and into pugs core itself, etc. Er, of course I'm willing, that was exactly we've been moving toward in the recent weeks. :-) Though an explicit Standard Library design -- as compared to Perl5's which was grown out gradually by the porters and CPAN folks -- is tricky, and I'm not yet ready for that, lacking a practical understanding of how module interfaces and roles can be applied to this diverse design space. So I will be focusing on Prelude (the part of the language that always gets loaded by default) refactoring as well as providing an OO core calculus that can support this, and take advantage of the target VM's vast library instead of writing them in Perl 6, at least up until 6.2831 (the primary target VM is Perl 5, then Parrot, then JavaScript.) But if you'd like to work on the standard library -- well, you have a commit bit. :-) Audrey
Re: overloading the variable declaration process
On 2/6/06, Darren Duncan [EMAIL PROTECTED] wrote: Speaking briefly, I would like it if Perl 6 provided a way for a class (or role, or meta-class, etc) to declare that all variables declared to be of that type are automatically/implicitly set to a particular value at declaration time, so that they are not undefined if the programmer using them doesn't explicitly set a value. In a somewhat related note, Perl 6 allows this form: my Dog $fido .= new; which may be treated as a special form (as is currently the case with Pugs). However if it's not, it would desugar to: my Dog $fido; $fido = $fido.new; which seem to imply that $fido is set to ::Dog (the dog class) as its initial value. However, that would potentially make this a no-op: my Dog $fido = Dog; which may make sense except that defined($fido) may need to be regulated as true even for the my Dog $fido case. If so, your use case can be satisfied by declaring that ::NumType (the class object) numifies to 0, and ::StrType stringifies to , via the coerceas form. Audrey
\c[NAMED UNICODE CHARACTER]?
Is it possible to have it as part of Synopsis 02? It's mentioned variously in A05, E05 and E07 (where it permits a \c[2026] form, but should be spelled \d[2026] nowadays), but is not currently part of any Synopses. Audrey
Re: Conversion oneliner t-shirt
On 1/27/06, Juerd [EMAIL PROTECTED] wrote: Because of the favourable response to the prototype I wore during the post-euroscon Amsterdam.pm meeting, and because Cafepress finally has black shirts, it is now available for everyone who wants one. http://www.cafepress.com/perl6 After some discussion with Juerd on #perl6, I'll also print some (in black preferably, or in other darker colours) and bring with me to OSDC.il and GPW as giveaway presents. :-) Audrey
Re: Parrot and PGE will save the day (was Re: as if [Was: Selective reuse of storage in bless.] )
On 1/21/06, Rob Kinyon [EMAIL PROTECTED] wrote: I'm making a few assumptions here: 1) Since PGE isn't part of Perl6 (because it's written in PIR), it can be used as the parser/lexer/etc. for any language, not just Perl6. Rules, like regexes, are essentially language neutral. So that's true. 2) Since PGE can be lexically-scoped, one can change the entire grammar within a given block, including how variables are referenced, subroutines are called, etc. The grammar only governs the surface syntax. It does not automagically control semantics (e.g. whether .arguments are available, tying, blessing, et cetera). Moreover, writing a Perl 5 parser in PGE alone is... Very difficult. It can be done (eg. PPI), but taking it and emit PIR is a nontrivial task that would not magically happen. 3) Since everything is, at the heart, just a PMC, so long as the appropriate PIR is emitted, it doesn't matter how the userside code is written so long as the right parser/lexer/whatever is used to translate it to PIR. Again, that'd be handwaving, as Perl5-PIR compiler is currently not championed by anybody. The slightly less ambitious Perl5-PMCs project (Ponie) is also in need of a champion at this moment, and it does not guarantee sane interoperation with other PIR targetting compilers in itself, though we are certainly working on it. So, if all three assumptions hold, then your monolithic Perl5 script can easily inline any Parrot-targeted language you want, simply by doing the following: 1) Use Ponie. 2) Within a block, import the appropriate PGE module(s) to redefine the grammar to P6 and do what you need to do. No translator needed. The amount of effort of writing all this is no less heavy than that of a Perl5-to-Perl6 translator. :-) Also it makes sense to have multiple migration paths (runtime-level, bytecode-rewriting-level, source recompilation level), because different people are interested in different subprojects. The P5-to-P6 translator also could work when targetting the JavaScript runtime, or the CLR runtime, or generating native code via LLVM or D; in those places Ponie does not help at all. Audrey
Selective reuse of storage in bless.
Stevan Little wrote:
I realize one of Stevan's objections is But if you use a Hash, does your
object automatically support the .keys method and .kv and so on? to
which I
reply No, of course not. That's silly. It just uses the Hash for
*storage*.
Is that your objection to bless()?
Yes, that is my objection, because while the alternate storage approach
discussed above is actually a very interesting feature, it does not fit
with the p5 vision of bless.
With p5, you /can/ get to the underlying data structure. This is a break
which will hamper the backwards compatibility effort I think.
It is possible to have one's cake and eat it too. Consider:
Foo.bless($x)
where $x contains an Bar object. We can check if Foo is a subtype to
Bar -- for example, Foo.bless({some = 'hash'}) would check whether Foo
conforms to the Hash interface.
If so, then we safely reuse the underlying representation for storage:
class Foo does Hash { has $.a; has $.b }
my %args = (a = 1, b = 2);
my $obj = Foo.bless(%args);
%args.{'a'} = 999;
say $obj.a; # 999
say $obj.{'a'}; # 999
If not, we explode $x into named arguments and dispatch to .CREATE to
make an p6opaque representation. Hash and Array are thus turned to
pairs; a Scalar would have to contain an arglist or a pair, otherwise
it'd fail the named-only prototype check. To wit:
class Bar { has $.a; has $.b }
my %args = (:a1, :b2);
my $obj = Bar.bless(%args);
%args.{'a'} = 999;
say $obj.a; # 1, not 999
say $obj.{'a'}; # Error -- no such method: postcircumfix:{ }
Note that A12 used to say that all Objects does Hash, and %$obj even
returns private attributes when used inside the class scope.
Fortunately, S12 doesn't mention anything like that, so I think the
treatment above is safe.
Audrey
signature.asc
Description: OpenPGP digital signature
Re: as if [Was: Selective reuse of storage in bless.]
On 1/21/06, Larry Wall [EMAIL PROTECTED] wrote:
But maybe all this is already possible in the current setup, if
role ObjectFakeHash does Hash {...}
role Object does ObjectFakeHash {...}
class Hash does Hash {...}
Yes, I think that's the way to go, as well as :coerceas for explicit
class-based (instead of role-based) conversions.
Audrey
Re: Class methods vs. Instance methods
On 1/19/06, Matt Fowles [EMAIL PROTECTED] wrote: Could you provide a concrete example of the advantage of this approach please? Failing that can you try and expand on your gut feeling a bit? May or may not be of use, but Larry's view sounds a bit like reconcilling the (again considered irreconcilable) gap between nominal and structural subtyping: http://cakoose.com/wiki/type_system_terminology#13 Where the empty class object is the degenerate case of the smallest possible structural type, so it can be fulfilled by anything more structurally rich as long as they share the same nominal constraint. Audrey
Re: Class methods vs. Instance methods
Rob Kinyon wrote:
Any practical programming language with structural subtyping will
probably let you create and use aliases for type names (so you don't
have to write the full form everywhere). However, the underlying type
system will only consider the structure of the type when doing its
job.
What's wrong with Perl doing things that way? duck-typing with names
... sounds like a plan to me ...
The thing is that people using .does(Name) and .isa(Name) is probably
expecting a nominal answer, not a structural one.
Although I do think Visual Basic's explicit duck-subtypes makes a lot of
sense:
my subset Duck where {
has $.half_life;
can doom:();
can quake:(-- Wolfenstein);
};
then you can apply it as a ducktype with names:
my Duck $donald = some_function();
$donald.quake; # assured to return a Wolfenstein object
It's already part of S12, by the way.
Audrey
signature.asc
Description: OpenPGP digital signature
Indeterminate forms for the Num type.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Assuming num uses the underlying floating point semantic (which may turn 0/0 into NaN without raising exception), what should the default Num do on these forms? 0/0 0*Inf Inf/Inf Inf-Inf 0**0 Inf**0 1**Inf Several options: - - Use whatever the underlying num semantics available - - Always fail - - Always die - - Specify them to return some definite value. At this moment, Pugs defines them ad-hocly to: 0/0 == die Illegal division by zero 0*Inf == NaN Inf/Inf == NaN Inf-Inf == NaN 0**0 == 1 Inf**0== 1 1**Inf== 1 But I'd like to seek a more definite ruling. Thanks, Audrey -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDzQyitLPdNzw1AaARApaEAKChw0bHNA3M7OBLoeoRpootIjpy0QCfYtvT /vNWF8SkS7MMXWDsZrDCp8I= =vI/b -END PGP SIGNATURE-
Re: Indeterminate forms for the Num type.
Doug McNutt wrote: - - Specify them to return some definite value. Only on a machine that doesn't do it in hardware or in some special perl function that's unlikely. This question arises as different platform answer things differently for the native calculation of eg. 1**Inf. At this moment, Pugs defines them ad-hocly to: 0/0 == die Illegal division by zero --- wrong. 1/0 should not die either. I personally like having 0/0 be NaN and 1/0 be Inf (as in JavaScript), but all of Python/Perl/Ruby/Scheme/OCaml throws exceptions for them... 0*Inf == NaN --- reasonable but don't re-invent the NaN bit pattern Inf/Inf == NaN --- reasonable but don't re-invent the NaN bit pattern Inf-Inf == NaN --- reasonable but don't re-invent the NaN bit pattern The NaN as used in Pugs is already a double-precision NaN bit pattern. :-) 0**0 == 1 --- Not indeterminate. Answer is correct. Inf**0== 1 --- Not indeterminate. Answer is correct. 1**Inf== 1 --- Not indeterminate. Answer is correct. On my machine (Pentium-M, FreeBSD), 1**Inf yields NaN, as demonstrated by this Parrot program: .sub main $N1 = 1/0 print $N1 # inf $N2 = 1 ** $N1 print $N2 # nan .end But putter on #perl6 reports 1 on his amd64. I'd be happy we spec it has to have to return 1 always for boxed Num types, even though it means additional cycles for boxed numeric types. Audrey signature.asc Description: OpenPGP digital signature
Re: Indeterminate forms for the Num type.
Luke Palmer wrote: I believe we've been through this before. We go with a standard, probably IEEE, horridly mathematically unappealing though it may be. It will be easier to implement and it will be more predictable, both because most other language follow standards, too. The good thing about standards is that there are so many to choose from. Which IEEE standard are we following? 754-1985? 854-1987? 754r-2006 (still under discussion)? Also, would you be happy with different treatments of Int/Int versus Num/Num? 0/0 # fail illegal division by zero 0.0/0.0 # NaN That seems to follow from the standard (ruby, ocaml, mzscheme currently does that), but some may also argue for NaN bothways (ghc, js) or an exception bothways (perl5, python). Audrey signature.asc Description: OpenPGP digital signature
Re: Indeterminate forms for the Num type.
Audrey Tang wrote: That seems to follow from the standard (ruby, ocaml, mzscheme currently does that), but some may also argue for NaN bothways (ghc, js) or an exception bothways (perl5, python). Er, wait, ghc also raises an exception for (div 0 0), because it distinguishes integer (div) with fractional (/). However, I think one of P6's idea is that the user should not have to care between 0 and 0.0's behaviours, so maybe it makes sense to do the same thing (be it NaN or exception) both ways. I'm not sure that IEEE 754/854 still applies if we want to merge the behaviours of int/num/complex/bigint/bigrat/bignum under a Num banner. (There is always the worse-is-better option of going with whatever the underlying runtime does, usually determined by hardware/libm.) Audrey signature.asc Description: OpenPGP digital signature
The old $x will not stay shared thing.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm almost sure this had been covered before, but I failed to find a
reference in either the archives or in synopses, so here goes again:
sub f ($x) {
sub g ($y) { $x + $y }; g($x);
}
f(10); # 20?
Currently in Pugs, g is built at BEGIN time when f had not finished
building up its lexical environment, and as such fails to see the
runtime $x. The desugared form is:
our g;
BEGIN { g := sub ($y) { $x + $y } }
However, the following form does work in the Parrot, JavaScript and
Haskell runcore:
sub f ($x) {
my sub g ($y) { $x + $y }; g($x);
}
the reason it works is that g's body is replaced every time upon f's
entry. This is probably the expected behaviour.
What would happen for the our sub g form, where it becomes possible to
call g directly without entering f? This shows Pugs's current behaviour:
sub f ($x) {
our sub g ($y) { $x + $y }; g($x);
}
f(10); # 20 for sure
our g; # gets visibility to g
g(100); # 110 this time?
So my questions are:
* Is the treatment above sane?
* Does it make sense to change the undecorated sub g's behaviour to
match our sub g?
* If we insert a call to g() above without calling f() first, should it
assume an uninitialized $x, or throw an exception (Pugs currently does
the latter)?
I'd be happy to patch S06 when we get a consensus/ruling this time. :-)
Thanks,
Audrey
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (FreeBSD)
iD8DBQFDyz9WtLPdNzw1AaARApSXAKCrjk4dxDPhj7or2qxJBlULVBXgEQCfZxLO
kza0/2Xv3iAGXNaaw73phyw=
=rAZq
-END PGP SIGNATURE-
