Re: new mailing list: perl6-general?
Hi, I think, that David's version is matches with my opinion. I don't think, that beginners would be a better name for it, but maybe more practical, as it's a more evident name. Bye, Andras David Storrs wrote: On Jun 15, 2005, at 3:33 PM, Patrick R. Michaud wrote: And here they are... this is just a draft -- feel free to flame/edit/ tear it apart liberally. These are also written assuming we don't create a perl6-general list (but it shouldn't be hard to adapt them should one be created). Well, I'd suggest the following. (Anything not mentioned stays as you wrote it.) perl6-language This is the theory of list. Discussion of the design of the perl6 language, and its desired (or unwanted) feature list. If you have patches and/or suggestions for improving the Perl 6 design documents (Apocalypses, Synopses, etc.), send them here. perl6-howto This is the practice of list. Come here to ask How do I..., What does XYZ mean?, or Why doesn't this work? Novices are especially welcome. (Note: I envision this list being much like beginners@perl.org, but I never liked that name because it seems like it would drive away those who have a question but do not consider themselves beginners. On the other hand, maybe it's more important to explicitly welcome novices. I could go either way: maybe the above list should be 'perl6-beginners')
Re: new mailing list: perl6-general?
Hi, Hi, I think, that David's version is matches with my opinion. I don't think, that beginners would be a better name for it, but maybe more practical, as it's a more evident name. Hmmm, I think beginner is a little negative. What about professional Perl5 programmers, who wish to learn Perl6? Wouldn't like the name :-)) How about 'perl6-usage', 'perl6-programming' or... hmmm, simply 'perl6'? - Fagzal
Re: new mailing list: perl6-general?
Hi, Fagyal Csongor wrote: I think, that David's version is matches with my opinion. I don't think, that beginners would be a better name for it, but maybe more practical, as it's a more evident name. Hmmm, I think beginner is a little negative. What about professional Perl5 programmers, who wish to learn Perl6? Wouldn't like the name :-)) How about 'perl6-usage', 'perl6-programming' or... hmmm, simply 'perl6'? I like perl6-programming, as it means, that it's ok to post there general programming questions (related to perl6), too. And maybe my original proposal, perl6-general is OK, too. Bye, Andras
sub my_zip (...?) {}
Currently in Pugs *zip has no signature -- it simply rewrites its arguments into the listfix (i.e. Y) function. That is bad because it can't be introspected, and you can't define something like that yourself. It also makes it uncompilable to Parrot as I don't control the runloop there. :) Also, currently the following code does not flatten @a and @b together, which I'm not exactly sure is correct or not: zip(@a, @b); What should zip's function signature be, if I want to do something like zip() that handles semicolon lists? Thanks, /Autrijus/ pgpxEdADkr8Zi.pgp Description: PGP signature
Re: sub my_zip (...?) {}
On Thu, Jun 16, 2005 at 05:40:31PM +0800, Autrijus Tang wrote:
: Currently in Pugs *zip has no signature -- it simply rewrites its
: arguments into the listfix (i.e. Y) function.
:
: That is bad because it can't be introspected, and you can't define
: something like that yourself. It also makes it uncompilable to Parrot
: as I don't control the runloop there. :)
I think something like
sub zip (Pipe [EMAIL PROTECTED]) {...}
is probably sufficient.
The semicolon operator no longer builds a list of lists, but a list
of pipes, which are specially marked Lazies that know they came from
pipe operators (including semicolons as a kind of pipe operator).
When bound to an ordinary splat array (or in fact any splat array whose
type isn't Pipe), the Pipes flatten as if they were comma separated.
When bound to an array of type Pipe, each pipe stays discrete.
: Also, currently the following code does not flatten @a and @b together,
: which I'm not exactly sure is correct or not:
:
: zip(@a, @b);
That should flatten into a single slice/pipe, so zip should probably
have the option of complaining about it somehow. On the other hand,
you don't want warnings for the default on any such binding, since
subscripts use the same binding, and we'll often have subscripts with
a single slice.
We also have this construct to allow indirect semicolon lists:
zip( [;] @lists )
(The [;] reduction operator takes the place of semi in S09.)
This does imply that we can pipe into a subscript somehow. If we
choose something like () for our placeholder meaning pipe into this
location, then
@[EMAIL PROTECTED]; @b; @c]
is the same as
@foo[()] == @a == @b == @c
or
@c ==
@foo[()] == @a == @b
or
@c ==
(@b ==
@foo[()] == @a
)
or
@c ==
(@b ==
(@a ==
@foo[()]
)
)
though perhaps there's some ambiguity problems with using a single ()
as the target of multiple ==. Note that every list has an implied ()
at the end, which is the default target of pipe operators. That says
to me that we probably make a rule that == binds to the leftmost ()
it sees (if it sees one), so we can differentiate
@a ==
@foo[$x].print()
from
@a ==
@foo[()].print
And in the absence of an explicit (), the rightmost implicit () is
the target, so
@a ==
@foo[$x].print
should feed the pipe to the print, not the subscript, even though
$x is officially part of a one-element slice with an implicit ()
at the end. I think this is closest to what people will expect.
Larry
Ignoring parameters
Say I have a class method in FooClass, callable as FooClass.greet():
method greet(Class $class: ) {
say Hello, FooClass!;
}
AFAIK, this is the only signature that would work for making greet a
class method; but note that I'm not using $class, and I'd expect the
compiler to issue a warning in such a case.
The same problem exists with methods in classes fulfilling a role,
but which want to ignore a parameter in a required method.
What do you say about this proposed syntax?
method greet(Class undef: ) { ... }
# the interface calls for a floor as 1st arg
method bereaucracy(Int undef, Int $office_number) { ... }
I'm not sure how this works for named fields, but for positional ones
it should do well, and is similar to ($a, undef, $c) = LIST syntax.
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: sub my_zip (...?) {}
[Sent off-group by mistake. On #perl6 the impression was that now Pipe is becoming a Role for things that can lazily be read from; and thus any filehandle or lazy list fulfills them. Larry, please help us understand if this is the case.] On Thu, Jun 16, 2005 at 08:53:41AM -0700, Larry Wall wrote: The semicolon operator no longer builds a list of lists, but a list of pipes, which are specially marked Lazies that know they came from pipe operators (including semicolons as a kind of pipe operator). When bound to an ordinary splat array (or in fact any splat array whose type isn't Pipe), the Pipes flatten as if they were comma separated. When bound to an array of type Pipe, each pipe stays discrete. I thought the class Pipe was reserved for what the result of open-foo| is in Perl 5? That's what we call it in Prelude.pm at least; if it needs to be renamed maybe IPC could work. -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: sub my_zip (...?) {}
Larry Wall writes: This does imply that we can pipe into a subscript somehow. Why? Or rather, why is that desirable? If we choose something like () for our placeholder meaning pipe into this location, then @[EMAIL PROTECTED]; @b; @c] is the same as @foo[()] == @a == @b == @c That placeholder just looks to me like it's asking for people to be confused by action at a distance. Under what circumstances does using the latter, with n pipes, give an advantage over the former, with n semicolons? Especially given: though perhaps there's some ambiguity problems with using a single () as the target of multiple ==. Note that every list has an implied () at the end, which is the default target of pipe operators. That says to me that we probably make a rule that == binds to the leftmost () it sees (if it sees one) ... And in the absence of an explicit (), the rightmost implicit () is the target That seems to be a lot of rule to remember for some relatively obscure feature, and it's giving a non-intuitive amount of meaning to the innocent-looking empty list (). I think this is closest to what people will expect. Hmmm. I'm not convinced that many people would expect being able to pipe into subscripts at all. Except that you've almost certainly thought about this more than I have, and you are rather good at this language design lark -- so I'm also not convinced by my own criticism of this feature ... Smylers
Re: sub my_zip (...?) {}
On Thu, Jun 16, 2005 at 07:24:42PM +0300, Gaal Yahas wrote:
: [Sent off-group by mistake. On #perl6 the impression was that now Pipe
: is becoming a Role for things that can lazily be read from; and thus any
: filehandle or lazy list fulfills them. Larry, please help us understand
: if this is the case.]
That's perhaps an overgeneralization. I don't care if there's a
special Pipe type or role, as long as there's some declaration for
binding that can determine the *syntactic* intent of the caller
to do something with multi-dimensional lazy lists, which implies
there's some kind of mark to convey that syntactic intent. If it is
a role, it's probably only applied to lazy containers implicitly by
the calling code. In fact, the actual data structure to be bound
to the slurpy is probably a Lazy of Lazys, but we want to avoid
two problems here by marking that structure as special. We don't
want to accidentally bind a Lazy of Lazys to the slurpy array merely
because the next parameter of the list accidentally happens to be one.
The intent to use semicolon or pipes has to be there syntactically to
get the special multidimensional mark. In @[EMAIL PROTECTED], @bar is always
a one-dimensional slice, even if it happens to be lazy. You must
specify @foo[[;[EMAIL PROTECTED] or @foo[()] == @bar to get the special mark.
On the receiving end, we want to avoid the problem of feeding
multidimensional lists to parameters that are expecting flat lists.
So the default is that all the pipes into an ordinary slurpy flatten,
as if all the semicolon boundaries were actually commas. But for
those relatively rare cases where we do want to pay attention to the
semicolon boundaries, we want an explicit declaration that says not
to flatten those semicolon boundaries. That's what I was aiming at
with the Pipe declaration.
: On Thu, Jun 16, 2005 at 08:53:41AM -0700, Larry Wall wrote:
: The semicolon operator no longer builds a list of lists, but a list
: of pipes, which are specially marked Lazies that know they came from
: pipe operators (including semicolons as a kind of pipe operator).
: When bound to an ordinary splat array (or in fact any splat array whose
: type isn't Pipe), the Pipes flatten as if they were comma separated.
: When bound to an array of type Pipe, each pipe stays discrete.
:
: I thought the class Pipe was reserved for what the result of open-foo|
: is in Perl 5? That's what we call it in Prelude.pm at least; if it needs
: to be renamed maybe IPC could work.
I'm not stuck on using the word Pipe--it fact, if it's going to be
an implicit mark, it should maybe be Huffman coded to something
longer, MultidimensionalSliceComponent or some such... :-)
On the other hand, system pipes could be called SysPipe, and it would
be nice to think of these inner things as pipes, since that's what
we're calling == and ==.
But maybe declaring the type of the elements of the slurpy is the wrong
approach anyway. Maybe it's the container type:
sub zip ([EMAIL PROTECTED] is MultiDim) {...}
or maybe even just a shape:
sub zip ([EMAIL PROTECTED] is shape(*;Lazy) {...}
What I'm trying to do here is to make the meaning of semicolon and
pipes context-dependent, so that those contexts that want to care
about the boundaries can care, and those contexts that don't want to
care don't have to.
On the flip side, I'd like to avoid inflicting another mandatory
abstraction on the naive users, so I'm not really interesting in
advertising a Pipe role for general use. Most new users won't realize
that they're dealing with a dwimmy semicolon--they'll just cargo cult
the notion that zip() takes a semicolon list.
This does leave open the question of exactly which built-in list
contexts do pay attention to pipe lists. Obviously, subscripts do.
A list of values in parens doesn't. I think array and hash composers
probably should pay attention, just because they look like subscripts.
And because it's useful for readability to cut down the nesting of
brackets by one level. However, they should probably warn if the
only semicolon is at the end, on the assumption that it's accidental.
On the other hand, we were using semicolon to differentiate hash
composers from blocks, so that's a bit of an issue.
Larry
Re: Ignoring parameters
On 6/16/05, Gaal Yahas [EMAIL PROTECTED] wrote:
Say I have a class method in FooClass, callable as FooClass.greet():
method greet(Class $class: ) {
say Hello, FooClass!;
}
Aside from the fact that I don't think this is the right way to
specify class methods...
AFAIK, this is the only signature that would work for making greet a
class method; but note that I'm not using $class, and I'd expect the
compiler to issue a warning in such a case.
I don't think that the compiler should issue a warning in the case of
unused parameters. Since the names of parameters mean something more
than just how the method refers to them--they specify the names of
named parameters--it could be useful to accept a parameter that is not
used, in anticipation of them eventually being used. The unused
parameter warning has never caught an error that undeclared
variable hasn't for me (as long as I name things well), and usually
is just a cue to bring out my UNUSED fingers.
The same problem exists with methods in classes fulfilling a role,
but which want to ignore a parameter in a required method.
What do you say about this proposed syntax?
method greet(Class undef: ) { ... }
Or we could finally take an idea from C++, one that I don't think is
so unreasonable:
method greet(Class:) {...}
Since there is no :: on the front of Class, it can't be mistaken for a
parameter. That does bring up the question of what happens if you
want to specify an indirect type as the type of a parameter. Maybe we
just disallow that...
Luke
scalar dereferencing.
my $x = 3; my $y = \$x; say $y + 10; $y++; say $y; say $x; Currently in Pugs they print: 13 4 3 Is this sane? What is the scalar reference's semantics in face of a stringification and numification? I assume that array/hash references simply pass on to the things they references to resolve stringify and numify, according to S02, but I had not been able to find mentioning about scalar refs Thanks, /Autrijus/ pgpcaOqaTwRFT.pgp Description: PGP signature
Re: Ignoring parameters
On Thu, Jun 16, 2005 at 01:26:31PM -0600, Luke Palmer wrote:
Say I have a class method in FooClass, callable as FooClass.greet():
method greet(Class $class: ) {
say Hello, FooClass!;
}
Aside from the fact that I don't think this is the right way to
specify class methods...
What do you think is the right way to specify them?
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: sub my_zip (...?) {}
Larry Wall wrote: You must specify @foo[[;[EMAIL PROTECTED] or @foo[()] == @bar to get the special mark. I'm uncomfortable with the specific syntax of @a[()] because generated code might sometimes want to generate an empty list, and special-casing that sort of thing is always a pain (and fragile). An empty list of subscripts should return an empty slice. What this mark is really trying to say is The definition of the indices is coming from elsewhere. I'm wondering if these semtantics would make it appropriate to use the yada operator here: @foo[...] == @bar; Dave.
Re: Ignoring parameters
Gaal Yahas wrote:
On Thu, Jun 16, 2005 at 01:26:31PM -0600, Luke Palmer wrote:
Say I have a class method in FooClass, callable as FooClass.greet():
method greet(Class $class: ) {
say Hello, FooClass!;
}
Aside from the fact that I don't think this is the right way to
specify class methods...
What do you think is the right way to specify them?
I certainly can't speak for Luke, but I think the right way to specify class
methods is:
method greet(FooClass ::class:) {
say Hello, FooClass!;
}
And I think that subs and methods *should* complain about all unused
non-optional parameters *except* invocants.
Damian
Re: sub my_zip (...?) {}
On Thu, Jun 16, 2005 at 01:05:22PM -0700, Dave Whipp wrote: : Larry Wall wrote: : You must : specify @foo[[;[EMAIL PROTECTED] or @foo[()] == @bar to get the special mark. : : I'm uncomfortable with the specific syntax of @a[()] because generated : code might sometimes want to generate an empty list, and special-casing : that sort of thing is always a pain (and fragile). An empty list of : subscripts should return an empty slice. If you don't actually pipe to it, a null list is exactly what it would be interpreted as, so I don't think it's a very big problem. And outside of generated code, () is always intentional. If there's a potential problem, it's with expecting @a == foo().bar() to feed bar() rather than foo(). So maybe that would have to be written @a == foo().bar(()) or @a == foo(()).bar() Or maybe as you say we just need a special term, though I don't think ... is it. : What this mark is really trying to say is The definition of the indices : is coming from elsewhere. I'm wondering if these semtantics would make : it appropriate to use the yada operator here: : :@foo[...] == @bar; That's cute, but I think that might be overloading the ... token a bit too much, and it's also rather likely to be confused with the postfix ... operator within subscripts. These would be too close, visually speaking: @foo[...] @foo[0...] I suppose a case could be made for @[EMAIL PROTECTED] or some such, since it's an inside out iterator. But () is prettier. Alternately we could go with the unix pipe character: @foo[|] Or maybe a splat @foo[*] Or go with the parens with something in them to indicate the positive absence of something. @foo[(*)] Anyone else want to have a go at this bikeshed? Larry
Re: Ignoring parameters
On 6/16/05, Damian Conway [EMAIL PROTECTED] wrote:
And I think that subs and methods *should* complain about all unused
non-optional parameters *except* invocants.
This brings up something I've been thinking about. I sometimes write a
method in Perl 5 that does something or other and then calls the superclass
method of the same name, passing all arguments. Or sometimes I pull off an
argument or two that only make sense to my method, leaving the rest for the
superclass method. This is all easy when args are just items in the @_
array.
Here are some Perl 5 examples:
# Do something then proceed with call as usual
sub foo
{
$_[0]-do_something_new(123, 'abc');
shift-SUPER::foo(@_);
}
# Pull off some args, do something, then proceed with call as usual
sub foo
{
my($self, %args) = @_;
$self-do_something_else(val = delete $args{'xyz'});
$self-SUPER::foo(%args);
}
Note that in both cases my foo() method doesn't know or care what
SUPER::foo()'s arguments are.
Now in Perl 6 I'll want to use fancy named parameters and so on, but I don't
want to lose the abilities described above. How would those examples look
in native Perl 6 code? (i.e., Without forcing all methods to have a
single slurpy [EMAIL PROTECTED] argument, emulating the Perl 5 mechanisms.)
-John
Re: Ignoring parameters
On Fri, Jun 17, 2005 at 07:05:11AM +1000, Damian Conway wrote:
Gaal Yahas wrote:
On Thu, Jun 16, 2005 at 01:26:31PM -0600, Luke Palmer wrote:
Say I have a class method in FooClass, callable as FooClass.greet():
method greet(Class $class: ) {
say Hello, FooClass!;
}
Aside from the fact that I don't think this is the right way to
specify class methods...
What do you think is the right way to specify them?
I certainly can't speak for Luke, but I think the right way to specify
class methods is:
method greet(FooClass ::class:) {
say Hello, FooClass!;
}
In the interest of keeping the design documents up-to-date, A12 says:
To declare an ordinary class method, such as a constructor, you say
something like:
method new (Class $class: [EMAIL PROTECTED]) { ... }
Such a method may only be called with an invocant that isa CClass,
that is, an object of type CClass, or derived from type CClass.
S12 says:
Class methods are just methods that can take a class as their invocant.
Somehow I read these as though the original poster was correct --
i.e., one creates a class method for FooClass as either
method greet(Class $class:) { say Hello!; }
or
method greet(FooClass $class:) { say Hello!; }
Are the design documents out of date in this regard? If so, can
someone provide a patch, if not, can someone confirm that the design
documents are correct? (I just happened to be looking at class methods
this past week, which is why I was a little surprised by Luke and
Damian's answers... :-)
Pm
Re: Ignoring parameters
Patrick wrote:
Somehow I read these as though the original poster was correct --
i.e., one creates a class method for FooClass as either
method greet(Class $class:) { say Hello!; }
Yes. That will work, but it's not the recommended solution.
or
method greet(FooClass $class:) { say Hello!; }
No. That needs to be:
method greet(FooClass ::class:) { say Hello!; }
(as implied by takes a class as its invocant in S12).
^
Are the design documents out of date in this regard? If so, can
someone provide a patch, if not, can someone confirm that the design
documents are correct? (I just happened to be looking at class methods
this past week, which is why I was a little surprised by Luke and
Damian's answers... :-)
Both documents are correct, but S12 is correcter (as you would expect).
Damian
nested subs
So, I was about to write the following test for Pugs:
sub factorial (Int $n) {
my sub factn (Int $acc, $i) {
return $acc if $i $n;
factn( $acc * $i, $i+1);
}
factn(1, 1);
}
When I thought to check the apocalypses and exegeses and, what do you know, I
couldn't find any evidence that nested named functions like this were legal.
So, are they legal?
And yes, I know there are other ways of doing this, but I like the lack of
sigils on the function when you do it this way.
Re: nested subs
On 6/16/05, Piers Cawley [EMAIL PROTECTED] wrote:
So, I was about to write the following test for Pugs:
sub factorial (Int $n) {
my sub factn (Int $acc, $i) {
return $acc if $i $n;
factn( $acc * $i, $i+1);
}
factn(1, 1);
}
When I thought to check the apocalypses and exegeses and, what do you know, I
couldn't find any evidence that nested named functions like this were legal.
So, are they legal?
Yep. And they work just as if you had used an anonymous sub there--it
closes over lexicals and everything.
Luke
Re: nested subs
Luke Palmer [EMAIL PROTECTED] writes:
On 6/16/05, Piers Cawley [EMAIL PROTECTED] wrote:
So, I was about to write the following test for Pugs:
sub factorial (Int $n) {
my sub factn (Int $acc, $i) {
return $acc if $i $n;
factn( $acc * $i, $i+1);
}
factn(1, 1);
}
When I thought to check the apocalypses and exegeses and, what do you know, I
couldn't find any evidence that nested named functions like this were legal.
So, are they legal?
Yep. And they work just as if you had used an anonymous sub there--it
closes over lexicals and everything.
I should bloody well hope so too.
Re: sub my_zip (...?) {}
On 6/16/05, Larry Wall [EMAIL PROTECTED] wrote: Or maybe a splat @foo[*] Or go with the parens with something in them to indicate the positive absence of something. @foo[(*)] Anyone else want to have a go at this bikeshed? You know, before I read this part of the message, I was thinking precisely that. Nullary splat should do it, so that @foo[*] will work. Unary splat would of course get our favor if it can be interpreted that way, but in cases like: @foo[*] bar(*) It is unambiguous, and you can always say (*) to disambiguate. I like the look of that too. Luke
When can I take given as read?
Suppose I have a simple, single argument recursive function:
sub factorial (Int $n) {
return 1 if $n == 0;
return $n * factorial $n;
}
Can I write that as:
sub factorial (Int $n:) {
return 1 when 0;
return $n * factorial $n;
}
NB. Yes, I know it's a pathological example.
Re: reduce metaoperator on an empty list
On Thursday 09 June 2005 12:21, John Macdonald wrote:
On Thu, Jun 09, 2005 at 06:41:55PM +0200, TSa (Thomas Sandla
wrote:
Edward Cherlin wrote:
That means that we have to straighten out the functions
that can return either a Boolean or an item of the
argument type. Comparison functions = = = != should
return only Booleans,
I'm not sure but Perl6 could do better or at least trickier
;) Let's assume that = = when chained return an
accumulated boolean and the least or greatest value where
the condition was true. E.g.
0 2 3 returns 0 but true
1 2 1 returns 1 but false
4 5 2 returns 2 but false
Then the reduce versions [] and [=] naturally come out as
min and strict min respectively.
Is it correct that [min] won't parse unless min is declared
as an infix op, which looks a bit strange?
if 3 min 4 { ... }
That's how it was done in APL. In fact, that's how every dyadic
(two-argument) function was done in APL. It looks strange at
first, but the syntax is simpler.
I eat my peas with honey.
I've done it all my life.
It makes them taste real funny,
But it keeps them on the knife.
The natural method of implementation would imply that the
final is returned:
0 2 3 returns 3 but true
1 2 1 returns 1 but false
4 5 2 returns 2 but false
The application of each stage of the chain has to remember
the right hand value (for the next stage of the comparison)
as well as the accumulated boolean result. When the boolean
result is true, that has and = returning the max, and and
= returning the min - the opposite of what you asked above.
In J one can do ()/ 0 1 1, evaluated as
0(11)
00
0
Then, since 00 is 0, and 01 is 1, 0 is a left identity of
(restricted to Booleans), and /'' is defined to be 0.
I don't suppose anybody here cares, but it turns out that Boolean
scans have a variety of uses, such as running parity, locating
transitions, and Gray Code to binary conversion, and Boolean
identity elements have their uses within these schemes.
--
Edward Cherlin
Generalist activist--Linux, languages, literacy and more
A knot! Oh, do let me help to undo it!
--Alice in Wonderland
http://cherlin.blogspot.com
