Re: Sometimes MakeMaker won't make.
Rob Bloodgood wrote: Adam Kennedy wrote: Doesn't makemaker only like you if you have a single .pm file just in the root directory? And otherwise you have to have your lib files actually under lib? lib/Tree/Splay.pm lib/Tree/Splay/Node.pm lib/Tree/Splay/IntRange.pm t/01_basics.t t/02_compat.t Makefile.PL MANIFEST [snip] Well... I don't know if your conjecture is true, but your suggestion worked like a charm. Thanks! (and now I'm on my way to reorganize my other distribution...) To get the directory and file framework which MakeMaker (and its young cousin, Module::Build) likes to play with, you can use any of a number of Perl extensions on CPAN. I'm now maintaining ExtUtils::ModuleMaker; Ricardo Signes maintains Module::Starter. They'll each save you from these kinds of problems in the future. Jim Keenan
Re: [perl #37633] [REQUEST] PIR syntax for if_null and unless_null opcodes
"Allison Randal (via RT)" <[EMAIL PROTECTED]> wrote: One thing that would be nice is a bit of PIR syntactic sugar for if_null and unless_null opcodes. Maybe something like: if null $P5 goto LABEL unless null $P5 goto LABEL Done, enjoy. Thanks, Jonathan
Re: Sometimes MakeMaker won't make.
Adam Kennedy wrote: > Doesn't makemaker only like you if you have a single .pm file just in > the root directory? > > And otherwise you have to have your lib files actually under lib? > > lib/Tree/Splay.pm > lib/Tree/Splay/Node.pm > lib/Tree/Splay/IntRange.pm > t/01_basics.t > t/02_compat.t > Makefile.PL > MANIFEST > > - > > use ExtUtils::MakeMaker; > > WriteMakefile( > NAME=> 'Tree::Splay', > VERSION_FROM=> 'lib/Tree/Splay.pm' > ); > > Try that... Well... I don't know if your conjecture is true, but your suggestion worked like a charm. Thanks! (and now I'm on my way to reorganize my other distribution...) L8r, Rob
[perl #37633] [REQUEST] PIR syntax for if_null and unless_null opcodes
# New Ticket Created by Allison Randal # Please include the string: [perl #37633] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=37633 > One thing that would be nice is a bit of PIR syntactic sugar for if_null and unless_null opcodes. Maybe something like: if null $P5 goto LABEL unless null $P5 goto LABEL Even something like: if_null $P5 goto LABEL unless_null $P5 goto LABEL would be a significant improvement over a PASM control statement in the middle of PIR code. It's not much different, really, but after coding PIR for a while, this just feels wrong: if_null $P5, LABEL unless_null $P5, LABEL Allison
Re: Perl6 perlplexities [was: "Re: $1 change issues..."]
Larry Wall skribis 2005-11-07 13:20 (-0800):
> Okay, I won't shout (not even on PerlMonks :-), but named parameters
> default to optional, so you'd have to write that as
> sub convert (:$from!, :$to!, :$thing!) { ... }
> in the current scheme of things.
Ah, thanks.
I hadn't noticed this change, but I like it.
I've updated the PM node :)
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Octal in p6rules (and strings)
On Mon, Nov 07, 2005 at 02:47:05PM -0600, Patrick R. Michaud wrote: : > : But for the :w issue, we can always solve it with the colon: : > : : > : \d:065 = A digit (cut) followed by "065" : > : > That doesn't extend to \d:woot, of course... : : It doesn't? I mean, isn't that a digit followed by "woot"? No, it's a digit followed by ":woot". Adverbs aren't currently restricted to being at the front of a sequence. I think a backtracking colon can't have an alphanumeric right after it or it's taken as an adverb. We *could* restrict adverbs to the front. Would have to think about the ramifications of that though... Larry
Re: Sometimes MakeMaker won't make.
-BEGIN PGP SIGNED MESSAGE- Moin Rob, On Monday 07 November 2005 23:22, Rob Bloodgood wrote: > I've had this problem for awhile with a distribution I've been working > on where sometimes, after invoking Makefile.PL, typing 'make' creates a > blib folder with all of the .exists files in the right places, but > doesn't copy the actual module files to it. > > This was driving me crazy. I don't have a solution. In desperation I > removed everything from the folder that wasn't bundled with 'make > tardist', cleaned it, and ran Makefile.PL again... and no love. but > then suddenly thru nothing I could figure out, it started working > again. > > Does this sound like a pretty half-assed problem? I thought so too. I > figured it's my fault, don't bug other people for my mistakes. > > Well, last week I went to go write a little experimental module for > myself, Tree::Splay (Hi Schwern!). I created Do you have timestamp/clock problems? IS your filesystem on an NFS mounted volume? Best wishes, Tels - -- Signed on Tue Nov 8 00:03:29 2005 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. "Duke Nukem Forever will come out before Doom 3." - George Broussard, 2002 (http://tinyurl.com/6m8nh) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iQEVAwUBQ2/dZXcLPEOTuEwVAQFt7Af9Feyfi0hA6zQlcrEZndhBGmrIp0JSdCFB r3iopBFIr7/IM5dYuJIEfMAkQ7EOrpxWgr79TLNMjD1RNOWw5vkhRM1GZ0P8bJTq MLzPEvTt1VBkRYa6zwZMLuIwtCsxHEY0ADkqBnh5qwmIDmgzstM4EpkwaYaNIEIl vtsF2fK/gasbTJDDkdA3bZlIZxHI0GhU8ATUTnLXy/RN3a6O9iluECJqJKAh+0cr a0e8NuTXEjIzlN9ylB08cm2Lzc6yDdQB6AXbl7hqQ7IT95wxc/ZBFnoEpIMJSoUp I/EmROAhbA+07tFhwS6pvxbgwXcdlwznzV/P+h+J8jLPPhPBohZZCA== =KEZb -END PGP SIGNATURE-
Re: =>'s container and binding semantics
On Mon, Nov 07, 2005 at 11:20:39PM +0200, Ilmari Vacklin wrote:
: On Mon, Nov 07, 2005 at 12:05:30PM -0800, Larry Wall wrote:
: > On Mon, Nov 07, 2005 at 11:53:26AM -0800, Larry Wall wrote:
: > : Also, if we provide a way to return a pair instead of a value from a
: > : hash (currently done with the new :%hash syntax),
: >
: > Whoops, I forgot I changed that to %hash: (and %hash:{'key'} too).
:
: Playing the devil's advocate; maybe that should be %hash.pairs, or
: %hash.pair:key? I don't like the : there - it's too small, and hidden
: %between the larger syntactical elements.
Leaving aside the visibility argument, which is a valid complaint,
%hash.pairs implies generation of a list of pairs which can't be
subscripted except by treating it as a hash. Whether you put
.pairs (or .kv) before or after the subscript, it ends up being a
special case. So it seems to be more of an adverbial idea, but I
thought
%hash:pair
is rather ugly, and prone to having :pair eat up the following syntax.
We could improve the visibility of the colon like this:
%hash.:
or maybe even
%hash :
On the other hand, the colon notation doesn't give us .kv. But it's
probably not too bad to say
%hash.:[EMAIL PROTECTED]
in that case. I thought a bit about adverbial solutions like:
%hash{:pair @slice}
%hash{:kv @slice}
but it is problematic to extend those to:
%hash<:pair key>
%hash<:kv key>
And it seems to me that we very frequently will want to pass named
arguments that take their names from the keys of the hash:
blurp 1,2,3, %options:
and I wanted to get the named-arg indicator as near as I could to
the actual argument names without destroying the <> quoting.
Larry
Re: Octal in p6rules (and strings)
On Mon, Nov 07, 2005 at 12:37:02PM -0800, Larry Wall wrote: > On Mon, Nov 07, 2005 at 02:18:24PM -0600, Patrick R. Michaud wrote: > : Having a shortcut for seems like a very good idea; it > : certainly makes things a lot simpler for the optimizer. However, > : a reminder that A05 says that angles can be used as a bracketing > : construct as in C<< \x<0a> >>, so we have the situation that > : > : \d065 = ASCII "A" > : \d<065>= ASCII "A" > : \d<>065= A digit, a null, and the digits "065" > > A05 is probably wrong there. I think we've settled on [] for the > standard extension brackets. Oh, exclusively [] ? Excellent! I can rip out a small bit of code... :-) > : But for the :w issue, we can always solve it with the colon: > : > : \d:065 = A digit (cut) followed by "065" > > That doesn't extend to \d:woot, of course... It doesn't? I mean, isn't that a digit followed by "woot"? (Or am I just being dense here...?) Pm
Re: =>'s container and binding semantics
On Mon, Nov 07, 2005 at 12:05:30PM -0800, Larry Wall wrote:
> On Mon, Nov 07, 2005 at 11:53:26AM -0800, Larry Wall wrote:
> : Also, if we provide a way to return a pair instead of a value from a
> : hash (currently done with the new :%hash syntax),
>
> Whoops, I forgot I changed that to %hash: (and %hash:{'key'} too).
Playing the devil's advocate; maybe that should be %hash.pairs, or
%hash.pair:key? I don't like the : there - it's too small, and hidden
%between the larger syntactical elements.
> Larry
--
Ilmari Vacklin
Sometimes MakeMaker won't make.
I've had this problem for awhile with a distribution I've been working on where sometimes, after invoking Makefile.PL, typing 'make' creates a blib folder with all of the .exists files in the right places, but doesn't copy the actual module files to it. This was driving me crazy. I don't have a solution. In desperation I removed everything from the folder that wasn't bundled with 'make tardist', cleaned it, and ran Makefile.PL again... and no love. but then suddenly thru nothing I could figure out, it started working again. Does this sound like a pretty half-assed problem? I thought so too. I figured it's my fault, don't bug other people for my mistakes. Well, last week I went to go write a little experimental module for myself, Tree::Splay (Hi Schwern!). I created Tree/Splay.pm Tree/Splay/Node.pm Tree/Splay/IntRange.pm t/01_basics.t t/02_compat.t Makefile.PL MANIFEST Makefile.PL contains: ===bof=== use ExtUtils::MakeMaker; WriteMakefile( NAME=> 'Tree::Splay', VERSION_FROM=> 'Tree/Splay.pm' ); ===eof=== and when I run Makefile.PL and then make, I get the same damn thing: blib gets created with .exists files, and pm_to_blib is touched, but *nothing* else happens. So I thought to myself, maybe it doesn't like its environment. So I removed *EVERY* *SINGLE* file and subdirectory from the subdir where I was working except what I named above and the *~ backup files that emacs creates. Still no luck. I type make, I get pm_to_blib and blib/* skeleton but my files don't get copied into blib. Since I don't think I'm stupid, but I'm willing to admit ignorance: WTF??? What did I miss here?? TIA! L8r, Rob
Re: Perl6 perlplexities [was: "Re: $1 change issues..."]
On Mon, Nov 07, 2005 at 04:46:06PM -0500, Andrew Rodland wrote: > Sorry, I wasn't clear here, so I hope you don't mind my cutting you off. What > I meant wasn't "signatures are too much complexity" -- they're not; they're > simply doing something useful -- but rather "too much complexity is getting > thrown into signatures" to the point where the gain isn't so much, but the > complexity starts creeping in, and you need a book just for everyday tasks. > Combined with what seems to me like a thoroughly unreadable syntax, function > signatures are starting to look like a brand new version of the regex mess > that p6 ditched in favor of the more consistent, more readable patterns. Well, just to point out that we didn't know a priori that the regexp syntax was a mess until we got extensive experience with it and with what we wanted from it. In the early 1990s, perl and its regular expressions were the coolest stuff ever. :-) I think the same holds for signature syntax. @Larry are doing the best juggling act they can to get it worked out such that once it's "set in stone", the signature syntax will be intuitive, sensible, unobtrusive, etc. There may be complexity, but most times you shouldn't see it unless you want to do something strange and wonderous and magical. The only reason it looks like there's complexity now is because we're pushing and prodding the signature syntax to see what works and what doesn't. (At this point, I'm *really* glad the language design is taking years) Because of this there will be times when all of the guts are exposed, but I don't think that it'll always be that way. By the time perl 6.0.0 rolls around, the guts should be tucked away nicely. my two cents, -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Perl6 perlplexities [was: "Re: $1 change issues..."]
On Monday 07 November 2005 03:51 pm, Juerd wrote: > Andrew Rodland skribis 2005-11-07 13:30 (-0500): > > If you want to get into personal beliefs, I think that function > > signatures are such a complexity quagmire -- and that they're line-noise > > ugly to boot. > > The nice thing about signatures is that they let you write what you > mean. This saves you an entire translation from what you mean to some > Perl code that manipulates @_. This translation is hard, and error > prone, as is the code that comes from it. Sorry, I wasn't clear here, so I hope you don't mind my cutting you off. What I meant wasn't "signatures are too much complexity" -- they're not; they're simply doing something useful -- but rather "too much complexity is getting thrown into signatures" to the point where the gain isn't so much, but the complexity starts creeping in, and you need a book just for everyday tasks. Combined with what seems to me like a thoroughly unreadable syntax, function signatures are starting to look like a brand new version of the regex mess that p6 ditched in favor of the more consistent, more readable patterns. I'm going to stop going on about this one way or another, but I just wanted to make myself clear first. Andrew
Re: Perl6 perlplexities [was: "Re: $1 change issues..."]
> Okay, I won't shout (not even on PerlMonks :-), but named parameters
> default to optional, so you'd have to write that as
>
> sub convert (:$from!, :$to!, :$thing!) { ... }
>
> in the current scheme of things.
Either way, the point is still that the benefits FAR outweigh any
additional complexity. Ruby could benefit from this, too. (While
first-class blocks rock my world, the weird subroutine signature stuff
most certainly doesn't.)
Rob
Re: Perl6 perlplexities [was: "Re: $1 change issues..."]
On Mon, Nov 07, 2005 at 09:51:39PM +0100, Juerd wrote:
: Or let's take this simple example:
:
: sub convert (:$from, :$to, :$thing) { ... }
:
: That isn't quite "my %args = @_;". Yes, that works, but the only real
: way we keep doing it is that the full solution sucks in plain Perl 5:
:
: sub convert {
: croak "..." if (@_ % 2) != 0;
: my %args = @_;
: croak "..." if not exists $args{from};
: croak "..." if not exists $args{to};
: croak "..." if not exists $args{thing};
: my $from = delete $args{from};
: my $to= delete $args{to};
: my $thing = delete $args{thing};
: croak "..." if keys %args;
: ...
: }
:
: before you shout that I'm doing something wrong, yeah, I've been out of
: this game for a while. Which only strengthens my point: it's hard to do
: it right in Perl 5!
Okay, I won't shout (not even on PerlMonks :-), but named parameters
default to optional, so you'd have to write that as
sub convert (:$from!, :$to!, :$thing!) { ... }
in the current scheme of things.
Larry
Re: Perl6 perlplexities [was: "Re: $1 change issues..."]
Andrew Rodland skribis 2005-11-07 13:30 (-0500):
> If you want to get into personal beliefs, I think that function signatures
> are
> such a complexity quagmire -- and that they're line-noise ugly to boot.
The nice thing about signatures is that they let you write what you
mean. This saves you an entire translation from what you mean to some
Perl code that manipulates @_. This translation is hard, and error
prone, as is the code that comes from it.
I think that even without any introduction to the subtleties of
signatures, any newbie with some programming experience will instantly
understand the essence of:
sub my_join ($sep, [EMAIL PROTECTED]) {
foo($sep, @elems);
}
and
method connect ($host, $port = 80) { ... }
While this isn't quite so clear:
sub my_join {
my $sep = shift;
foo($sep, @_);
}
sub connect {
croak "..." if @_ < 1;
croak "..." if @_ > 2;
my ($host, $port) = @_;
$port = 80 if not defined $port;
...
}
Or let's take this simple example:
sub convert (:$from, :$to, :$thing) { ... }
That isn't quite "my %args = @_;". Yes, that works, but the only real
way we keep doing it is that the full solution sucks in plain Perl 5:
sub convert {
croak "..." if (@_ % 2) != 0;
my %args = @_;
croak "..." if not exists $args{from};
croak "..." if not exists $args{to};
croak "..." if not exists $args{thing};
my $from = delete $args{from};
my $to= delete $args{to};
my $thing = delete $args{thing};
croak "..." if keys %args;
...
}
before you shout that I'm doing something wrong, yeah, I've been out of
this game for a while. Which only strengthens my point: it's hard to do
it right in Perl 5!
So, the typical answer is: use a module! Good idea, really, but that
still doesn't fix the problem. There are several modules out there that
handle argument parsing, that in practice you need to know the
subtleties of each of them. And none lets you combine scalar and list
context, because only prototypes can do that. I don't have to explain
why prototypes suck, and I think you can guess why combining them with a
parsing module sucks too.
For fun, one example with Params::Check:
use Params::Check qw(check);
sub convert {
croak "..." if (@_ % 2 ) != 0;
my %args = @_;
check(
{
from => { required => 1, store => \my $from },
to=> { required => 1, store => \my $to },
thing => { required => 1, store => \my $thing },
},
\%args,
1,
);
...
}
And oh boy, would this all have been VERY different if I wanted to
simulate this instead:
sub convert (:$from, :$to, :$thing is rw) { ... }
I think the complexity of signatures is much less than that of doing the
same things without them, with the extra benefit that even beginners
will (almost) instantly understand most of it!
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: =>'s container and binding semantics
Hi,
Larry Wall wrote:
> On Sun, Nov 06, 2005 at 03:10:40PM +0100, Ingo Blechschmidt wrote:
[ => should not automatically bind its .value to the RHS ]
> I think binding directly to .key or .value is different from what =>
> does. So after
>
> $pair = $key => $value;
>
> setting $value doesn't change $value, but after
>
> $pair.value := $value
>
> it does.
Yep, of course.
> We could have an => equivalent that does binding rather than
> copying:
[ :=>, :>, ::>, etc. ]
Personally, I think that these operators are not needed. In my PIL to
JavaScript compiler, I used the equivalent of =:> exactly two times,
and I did not mind declaring &infix:«=:>» myself, as it's such a short
and very readable declaration:
my sub infix:«=:>» ($key, $value is rw) {
my $pair = ($key => $value);
$pair.value := $value;
$pair;
}
> our pairs are containers, not values. Maybe \(key => $value) is
> how you turn => into ::>, since in the case of an arglist you have
> to be able to bind to the original $value.
Makes sense. :)
--Ingo
Re: Octal in p6rules (and strings)
On Mon, Nov 07, 2005 at 02:18:24PM -0600, Patrick R. Michaud wrote: : Ick, \d65 in a pattern looks really odd to me. I'll register my : distaste for this one message, and then I'll have to take a stiff : drink or something before I can bring myself to implement it. :-| I suppose we could even go as far as to make bare \o match <+[0..7]> and bare \x match <+[0..9a..fA..F]>. Unfortunately that doesn't extend to \b... Larry
Re: Octal in p6rules (and strings)
On Mon, Nov 07, 2005 at 02:18:24PM -0600, Patrick R. Michaud wrote: : Having a shortcut for seems like a very good idea; it : certainly makes things a lot simpler for the optimizer. However, : a reminder that A05 says that angles can be used as a bracketing : construct as in C<< \x<0a> >>, so we have the situation that : : \d065 = ASCII "A" : \d<065>= ASCII "A" : \d<>065= A digit, a null, and the digits "065" A05 is probably wrong there. I think we've settled on [] for the standard extension brackets. : But for the :w issue, we can always solve it with the colon: : : \d:065 = A digit (cut) followed by "065" That doesn't extend to \d:woot, of course... : Even with all that, I'm still not sure how I feel about \d065. Yes, you are. :-) Larry
Re: Octal in p6rules (and strings)
On Mon, Nov 07, 2005 at 11:13:21AM -0800, Larry Wall wrote: > On Mon, Nov 07, 2005 at 10:51:59AM -0600, Patrick R. Michaud wrote: > : It doesn't seem to be written anywhere, but I think it's assumed > : that in string literals one would use "\o123", just as we use > : "\x0a". > > That should certainly be permissible even if we don't force it. > And I suspect we should force it. Probably \0123 needs to be > completely illegal, at least for a decade or two, so we can let > our descendents decide what it should mean. Now implemented as such in r9825. > : Should rules work the same -- i.e., use "\o123" to specify a > : character (glyph, byte, whatever) using octal notation? > > I believe so. Also implemented in r9825. > I currently think that, given current trends toward installing whitespace > between tokens, we can reasonably allow \d123 for decimal and require > people to say \d 123 if they mean a digit followed by 123. Ick, \d65 in a pattern looks really odd to me. I'll register my distaste for this one message, and then I'll have to take a stiff drink or something before I can bring myself to implement it. :-| > Of course, > we then have a little problem under :w, which we can solve with \d123. > Maybe <> is short for , and you can write \d<>123. Having a shortcut for seems like a very good idea; it certainly makes things a lot simpler for the optimizer. However, a reminder that A05 says that angles can be used as a bracketing construct as in C<< \x<0a> >>, so we have the situation that \d065 = ASCII "A" \d<065>= ASCII "A" \d<>065= A digit, a null, and the digits "065" But for the :w issue, we can always solve it with the colon: \d:065 = A digit (cut) followed by "065" Even with all that, I'm still not sure how I feel about \d065. Pm
Re: =>'s container and binding semantics
On Mon, Nov 07, 2005 at 11:53:26AM -0800, Larry Wall wrote:
: Also, if we provide a way to return a pair instead of a value from a
: hash (currently done with the new :%hash syntax),
Whoops, I forgot I changed that to %hash: (and %hash:{'key'} too).
Larry
Re: =>'s container and binding semantics
On Sun, Nov 06, 2005 at 03:10:40PM +0100, Ingo Blechschmidt wrote:
: Hi,
:
: my ($key, $value) = ;
: my $pair = ($key => $value);
:
: $pair.key = "new";
: # Should this fail ("cannot modify a constant")?
: # Should this update $pair.key, but leave $key untouched?
: # Should this update $pair.key, implicitly updating $key as well?
#2. => copies $key, or equivalently does COW.
: $pair.value = "new";
: # Should this fail ("cannot modify a constant")?
: # Should this update $pair.value, but leave $value untouched?
: # Should this update $pair.value, implicitly updating $value
: # as well?
Likewise #2, I think.
Also, if we provide a way to return a pair instead of a value from a
hash (currently done with the new :%hash syntax), then we can't
have people trying to modify the key of the hash in place unless there's
some way to notify the hash that it has to re-insert the new key, and
that sounds like a big bother for little gain.
: If setting $pair.value changes $value, should rebinding $pair.value
: cause the binding to get destroyed:
:
: $pair.value := $some_other_var;
: $pair.value = "new";
: # $value unchanged, $some_other_var set to "new"
:
: If setting $pair.value does not change $value, should binding
: $pair.value to $value do what I mean:
:
: $pair.value := $value;
: $pair.value = "new";
: # $value changed
I think binding directly to .key or .value is different from what =>
does. So after
$pair = $key => $value;
setting $value doesn't change $value, but after
$pair.value := $value
it does. We could have an => equivalent that does binding rather than
copying:
$pair = $key :=> $value;
Of course, that *looks* like we're only binding the key side, so we could
go with
$pair = $key :> $value;
or
$pair = $key ::> $value;
Doubtless if we added that, we'd get requests to only bind the key
or the value:
$pair = $key ::> $value;# bind both
$pair = $key :=> $value;# bind the key
$pair = $key =:> $value;# bind the value
These have interesting ramifications when reduced:
$cons = [::>] @list;
$cons = [:=>] @list;
$cons = [=:>] @list;
Probably we'd want to optimize the value-copying variants to not
recopy the tail of the list at each step if possible.
I suppose an argument could be made for => to default to =:>.
In Haskell the correct answer is always ::>, of course, but Haskell
doesn't easily admit to the existence of mutable values. I think
our pairs are containers, not values. Maybe \(key => $value) is
how you turn => into ::>, since in the case of an arglist you have
to be able to bind to the original $value.
Or maybe :> is our named arg syntax and => is always a pair.
Larry
Re: Ways to add behavior
HaloO, Larry Wall wrote: > : ::Takes3Ints ::= :(Int,Int,Int --> Any); > : > : my &foo:(Takes3Ints); > > I'd say that has to be something like: > > my &foo:(Takes3Ints:); > > or maybe one of > > my &foo:(Takes3Ints \!); > my &foo:(\Takes3Ints); > my &foo\(Takes3Ints); > > since Takes3Ints is the implementation and/or arglist type. Sorry, you lost me. Why is there a invocant colon in the first example, and what exactly does the ref indicator mean in all the three different alternatives? > Otherwise how do you distinguish > > my &foo:(Takes3Ints); > my &foo:(Int, Int, Int); You mean the latter &foo as non-code, simple 3-tuple type? Otherwise I would think the & sigil implies the optional default &:( --> Any). But than again I haven't fully grasped your notion of the pure type name before the first colon. > The colon would still be required in an rvalue context. But the extension > of that to subs seems to be: > > my &sub(Sub: \$args) > > Hmm, does that mean that a method actually looks like this? > > my &meth(Method: $self: \$args) I have ranted that I see method invocation as a two step call with a covariant dispatch first and then a normal contravariant call with argument type check, but why the second colon? And why the first on &sub(Sub: \$args)? Just to name the intended code subtype? --
Re: [Pugs] Change in behaviour of reversing lines in a file (golf example)
On Sun, Nov 06, 2005 at 11:31:37PM +1100, Andrew Savige wrote: : On revisiting the old p6 golf example programs of *cough* six : months ago, I noticed they all still worked save one: : : [=<>].reverse.print : : This used to reverse the lines in a file, but now prints the : lines unreversed and with a space in between each line. : : It seems the original behaviour can be restored with: : : (=<>).reverse.print : : Just wanted to confirm that this change in behaviour is a feature : and not a bug. : : Oh, and if anyone can explain this change in behaviour (or point me : to a reference where it's described) that would be appreciated since : I've fallen way off the pace these past months. :-( Looks like a plain old bug to me. Larry
Re: Octal in p6rules (and strings)
On Mon, Nov 07, 2005 at 10:51:59AM -0600, Patrick R. Michaud wrote: : In p6rules, how should specify characters (glyphs, bytes, whatever) : using octal notation? : : Currently S02 says that integer constants in octal are written with : as "0o" prefix (as in 0o123), just as we would use the "0x" prefix : to specify integers using base-16. : : It doesn't seem to be written anywhere, but I think it's assumed : that in string literals one would use "\o123", just as we use : "\x0a". That should certainly be permissible even if we don't force it. And I suspect we should force it. Probably \0123 needs to be completely illegal, at least for a decade or two, so we can let our descendents decide what it should mean. : Should rules work the same -- i.e., use "\o123" to specify a : character (glyph, byte, whatever) using octal notation? I believe so. : And are we officially eliminating the \nnn notation from rules : and string literals? This seems to be implied by Larry's post at : http://www.nntp.perl.org/group/perl.perl6.language/19385 , but : several items in that thread seem to have been dropped without : a final resolution, or at least haven't made it into a design : document. I currently think that, given current trends toward installing whitespace between tokens, we can reasonably allow \d123 for decimal and require people to say \d 123 if they mean a digit followed by 123. Of course, we then have a little problem under :w, which we can solve with \d123. Maybe <> is short for , and you can write \d<>123. Though there's always [\d]123 too, which oddly enough is the same as <+[\d]>123 in this case. I wonder how often people would be fooled into thinking [\d] is a character class... : It's worth noting that both S05 and A05 make use of the traditional : \nnn notation in descriptions, and we probably need to update these : to bring them in line with whatever decision is made. Yes. By the way, found an interesting bug in pugs that might or might not be related: say +'0012' prints 0. Should print 12. If someone with time and a commit bit wants to install a test, I'd be obliged. Larry
Re: Perl6 perlplexities [was: "Re: $1 change issues..."]
On 2005-11-07 1:30 PM, "Andrew Rodland" <[EMAIL PROTECTED]> wrote:
> Especially when that complexity isn't optional. I
> think that's really a common "fear", that Perl 6 is going well beyond that
> point of sensibility.
>
> If you want to get into personal beliefs, I think that function signatures are
> such a complexity quagmire -- and that they're line-noise ugly to boot.
But the ugly and complex bits of function signatures are completely
optional. In the usual case, you can just say
sub foo($x, $y) { do stuff with $x and $y }
Or
method foo($x, $y) { default invocant name used to do stuff with $x and $y }
And not have to worry about it.
Re: Ways to add behavior
On Mon, Nov 07, 2005 at 09:37:04AM -0800, Larry Wall wrote:
: It would be nice to generalize this sufficiently to be able to declare
: polymorphic objects resembling match objects:
:
:my $matchobj(Poly: Key^Int^Notthere --> Any);
:
: Or maybe that should be:
:
:my $matchobj\(Highlander);
:
: :-)
But seriously, I do keep wanting poly objects to keep trees in. For
example, I want to represent XML with the tag attributes in a hash
but the contents in a list:
$obj = q:xml; # (conjectural here-xml syntax)
text2
text2
say ~$obj; # t1
say $obj.xml; #
say $obj{a2}; # y
say $obj[2];# text2
say ~$obj.first('t2') # t2
say $obj.first('t2').xml#
Larry
Octal in p6rules (and strings)
In p6rules, how should specify characters (glyphs, bytes, whatever) using octal notation? Currently S02 says that integer constants in octal are written with as "0o" prefix (as in 0o123), just as we would use the "0x" prefix to specify integers using base-16. It doesn't seem to be written anywhere, but I think it's assumed that in string literals one would use "\o123", just as we use "\x0a". Should rules work the same -- i.e., use "\o123" to specify a character (glyph, byte, whatever) using octal notation? And are we officially eliminating the \nnn notation from rules and string literals? This seems to be implied by Larry's post at http://www.nntp.perl.org/group/perl.perl6.language/19385 , but several items in that thread seem to have been dropped without a final resolution, or at least haven't made it into a design document. It's worth noting that both S05 and A05 make use of the traditional \nnn notation in descriptions, and we probably need to update these to bring them in line with whatever decision is made. Pm
Re: Perl6 perlplexities [was: "Re: $1 change issues..."]
On Monday 07 November 2005 09:26 am, Rob Kinyon wrote: > On 11/7/05, Michele Dondi <[EMAIL PROTECTED]> wrote: > > On Fri, 4 Nov 2005, Rob Kinyon wrote: > > > So, for a bit of extra complexity, I get peace of mind for myself and > > > my users. > > > > The point being, and I'm stressing it once again but no more than once, > > that maybe we're adding two bits of extra complexity, whereas just one > > bit not only would have been enough, but would have bought you even more > > peace of mind. Then again: this is a _feeling_ I got e.g. by reading the > > appearently endless discussions about the specifications of sub > > parameters, which seem to ensue inherent technical difficulties having to > > do with the attempt _conciliate_ too many different paradigms. > > [...] > Though, I do find the complexity reassuring. I like having the > options, even though I will never use them. The alternative is Perl5, > where you can do (almost) anything you could want, except you have you > jump through lots of hoops and you end up with something that works, > but really really slowly. No-one wants that. But it's not such a black-and-white thing. If 1 bit of complexity covers 90% of cases, 10 bits gets you 99%, 100 bits gets you 99.9%, and so on, where do you stop? Where do you say "okay, I think we're doing good enough, let's not add more complexity" ? Especially when that complexity isn't optional. I think that's really a common "fear", that Perl 6 is going well beyond that point of sensibility. If you want to get into personal beliefs, I think that function signatures are such a complexity quagmire -- and that they're line-noise ugly to boot. Andrew
Re: [perl #37577] [PATCH] Fix a couple of minor niggles (-1 -> uint, K&R prototype)
All~ On 11/6/05, Joshua Juran <[EMAIL PROTECTED]> wrote: > On Nov 5, 2005, at 4:27 PM, Joshua Hoblitt via RT wrote: > > >> [EMAIL PROTECTED] - Tue Nov 01 04:52:22 2005]: > >> > >> This patch fixes two classes of issue. > >> > >> * Don't assign -1 to an unsigned variable; use ~0U instead as it > >> makes it clear that the value is intended to be out-of-band (g++ > >> warned about this, and C compilers will increasingly) > >> > >> * Change a K&R prototype in a config test > >> > >> Regards, > >> > >> Nick > > > > I've applied the bit of the patch that removed the K&Rism in > > config/auto/alignptrs/test_c.in as r9803. I don't think that anybody, > > myself included, like the idea of using ~0U as a magic value. Can I > > consider this bug 'resolved'? > > > > Cheers, > > > > -J > > If -1 causes warnings, I'd think it should be replaced. I agree that > ~0U isn't readable. How about defining a named constant? That solves > both problems, and has the additional benefit of making the client code > self-documenting. Another option is to explicitly cast it as follows: uint foo = (uint)(-1); The last set of parens is unecessary, but I like them. This also makes it fairly clear that you are doing something odd. Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -Stan Kelly-Bootle, The Devil's DP Dictionary
Re: Ways to add behavior
On Mon, Nov 07, 2005 at 01:05:16PM +0100, TSa wrote:
: With the introduction of kind capture variables ^T we could complety
: drop the subtype special form. As you pointed out the adding of constraints
: happens with the where clause anyway. Thus we return to the usage of the
: compile time name assignment form
:
: ::Blahh ::= ::Fasel where {...}
:
: where the :: in all cases means working on the MIR (Meta Information
: Repository) which is the world of names (In Russian, Mir (Мир) means
: "peace," and connotes "community." --- cited from Wikipedia).
Except that a type declarator can remove the need for all those extra ::
markers. (Actually, the ::Fasel can be presumably written Fasel if
Fasel is already declared, so the only strangeness is on the left.
We could hack identifier-left-of ::= like we did identifier-left-of =>,
or we could turn ::= into more of a general alias macro idea. But I think
people generally like declarators out to the left for readability.)
: Question: shouldn't there be a natural 1 to 1 relation of ::T and ^T
: or globally ::*T and ^*T where the former is the name and the latter
: the kind represented by T? Of course scoping applies and there are
: anonymous things that can be captured into ^T vars at runtime.
Yes, that's basically how I see it. ::T is the literal form, ^T is the
free form, but both map to package T in some scope or other.
: If the answer is 'yes' as I expect, I wonder if the compiler has to restrict
: the usage of ::= to scopes which don't depend on runtime evaluations like
:
:if $x < 10 { ::*Surprise ::= ::*FunnyType; say 'did it'; }
:
: Or should these be extracted out, making the above mean
:
:::*Surprise ::= ::*FunnyType; # or further out if necessary
:
:if $x < 10 { say 'did it'; }
To me it's similar to
my $x = 1 if $y;
which should probably just be disallowed or warned about under strict.
On the other hand, the declarations in a class file are also contingent
on the class being used, so those declarations are also in a conditional
context. So maybe we should just declare such things to be erroneous.
: >: Question: does a subtype declaration work only on package-like things
: >: which are addressed with a :: sigil? Or does your 'potentially
: >: contravariant' mean that arrow types can be constraint or aliased, as
: >: well?
: >:
: >: subtype TakesInt of Sub where { .sig =:= :(Int --> Any) };
: >:
: >: my TakesInt &foo;
: >:
: >: foo('a string'); # type error
: >
: >Hmm, I would read that as declaring that &foo *returns* a TakesInt,
: >not that &foo *is* a TakesInt. Just as
: >
: >my TakesInt @bar;
: >
: >declares an array of individual TakesInt elements.
:
: This is not too bad because then the & sigil is naturally associated
: with the :( --> ) arrow type syntax and the forms can be mixed only
: to the extent of signature aliasing:
:
: ::Takes3Ints ::= :(Int,Int,Int --> Any);
:
: my &foo:(Takes3Ints);
I'd say that has to be something like:
my &foo:(Takes3Ints:);
or maybe one of
my &foo:(Takes3Ints \!);
my &foo:(\Takes3Ints);
my &foo\(Takes3Ints);
since Takes3Ints is the implementation and/or arglist type.
Otherwise how do you distinguish
my &foo:(Takes3Ints);
my &foo:(Int, Int, Int);
: How does arrow typing apply to the three data sigils $, @ and %?
: Compare:
:
: my $foo:(Int); # non-referential value type
: my $foo:(-->Int); # same? Or perhaps means anonymous ref/link/alias?
: my $foo:(Ref-->Int) # explicit reference? same as 'is ref' trait?
: my $foo:(Item: -->Int) # tied container
:
: Which is the default when the Int is used in the type slot of the
: declaration?
:
:my Int $foo;
That means
my $foo:(-->Int);
: Could this be used to define the key type of hashes?
:
:my %foo:(Blahh-->Any);
:
: And shape of arrays
:
:my @foo:(Int,Int,Int-->Any);
:
: where the Int or subtypes of it are enforced and Any defaulted.
Certainly. I wouldn't mind getting rid of the "shape" property.
: Thus this could just be
:
:my @foo:(!,!,!);
Yeah, though that doesn't mean you can't write @foo[1] and get a :(!,!)
out of it.
: The covariant invocant/container types are of course
:
:my $item :(Item: --> Any);
:my @array:(Array: Int --> Any);
:my %hash :(Hash: Key --> Any);
:
: The & sigils have a free signature and ^ vars obviously have no signature
: other than pure type ;)
Works for me. As with & sigs, we might be able to lose the colon in
a declarative context:
my $item(Item: --> Any);
my @array(Array: Int --> Any);
my %hash(Hash: Key --> Any);
The colon would still be required in an rvalue context. But the extension
of that to subs seems to be:
my &sub(Sub: \$args)
Hmm, does that mean that a method actually looks like this?
my &meth(Method: $self: \$args)
I also wonder about hybrid hash/arrays:
my %harry(HashArray: Key^Int --> Any);
It would be nice to generalize this sufficiently
Re: Perl6 perlplexities [was: "Re: $1 change issues..."]
On 11/7/05, Michele Dondi <[EMAIL PROTECTED]> wrote: > On Fri, 4 Nov 2005, Rob Kinyon wrote: > > > So, for a bit of extra complexity, I get peace of mind for myself and my > > users. > > The point being, and I'm stressing it once again but no more than once, > that maybe we're adding two bits of extra complexity, whereas just one bit > not only would have been enough, but would have bought you even more peace > of mind. Then again: this is a _feeling_ I got e.g. by reading the > appearently endless discussions about the specifications of sub > parameters, which seem to ensue inherent technical difficulties having to > do with the attempt _conciliate_ too many different paradigms. Honestly? I skip about 50% of the discussions on this list. I don't care about most of the syntax discussions and I don't care about sub signatures. Well, I -DO- care, just not enough to wrangle about it. All I care about is "Can I do what I want to do in an easy fashion?" That's why I spent so much time on roles and why I've released Perl6::Roles to CPAN. (Well, that was for DBI-2, but I can claim it was for me, right?) The point is that I will not use a lot of the features in Perl6, just like I didn't use alot of the features in Perl5. I doubt I'll ever use PGE directly (though macros will be nice, once I figure out where I'd use them). Same with most of the subroutine types. Though, I do find the complexity reassuring. I like having the options, even though I will never use them. The alternative is Perl5, where you can do (almost) anything you could want, except you have you jump through lots of hoops and you end up with something that works, but really really slowly. No-one wants that. Rob
Re: CPANTS: has_signature, has_pod_index
Adam Kennedy wrote: * has_pod_index: The POD contains at least one X<> keyword that helps POD indexers. Whether only one is usefull is open for debate, because at least the license (X), your CPAN ID under authors (x), and some generic keyword what your module (X) is about can probably added even for the most minimal module. Can you give an example of how this has any practical impact on anything? Here is the main page for the project. http://pod-indexing.annocpan.org/wiki/index.cgi They talk only about the Perl core doc at this point, probably because adding keywords there is already enough work. AFAIK the core docs are now covered, so individual modules would be next. Yep, a google-like search engine could save the effort of manually tagging with keywords, but I think this idea is more practical and will improve perldoc greatly. I hate to say it, but this indexing thing has seemed to be ass-backwards to me from the beginning. Instead of having one person combine a Pod Parser and Plucene indexer or some other simple process, they expect the 3500 authors to ADD extra content to all their POD? Well, indexing all of CPAN was never in my original goals. My goal is to make the core documentation more usable, and I haven't seen any automated search engine that does that. For example, let's say you want to find the definition of "scalar". Sure, you can use grep and find that there are 77 documents where "scalar" appears a total of 738 times. But which is the good one? (And which section of the document?) You can try to come up with some clever ranking algorithm, but it is not trivial (and it's not so easy to define things like PageRank[tm] in this case). I'd rather have a human indexer label the place, or just a handful of places, that have the most relevant information for that keyword. Cheers, Ivan
Re: Perl6 perlplexities [was: "Re: $1 change issues..."]
On Fri, 4 Nov 2005, Juerd wrote: Whatever, the new system by contrast seems to me to be at least 400% more complex, but it won't buy me 400% more functionality. It will buy you 400% in saving typing, 4000% in less debubbing and 4% in maintainability(==readability). Of course drawing any figure on such loose terms as I did in the first place is not serious and I didn't meant it to be, using them more for illustrational purposes reflecting my own perception. But the point is: are you sure that you have a 40k% gain in readability? That's quite a number!! And the impression I have, that I'm trying to stress once more (but the last time!) is that trying to "stuff everything" in the signature system is not increasing it any more and that a _slightly_ simpler one would do instead. On Fri, 4 Nov 2005, Rob Kinyon wrote: So, for a bit of extra complexity, I get peace of mind for myself and my users. The point being, and I'm stressing it once again but no more than once, that maybe we're adding two bits of extra complexity, whereas just one bit not only would have been enough, but would have bought you even more peace of mind. Then again: this is a _feeling_ I got e.g. by reading the appearently endless discussions about the specifications of sub parameters, which seem to ensue inherent technical difficulties having to do with the attempt _conciliate_ too many different paradigms. Michele -- If memory serves, Prof. Hermann Zapf considered using Palatino for his wedding invitation (but reconsidered and used one of his wife's designs instead --- there's a lesson in that I guess). - William Adams in comp.text.tex, "Re: Simple Wedding Invitations in LaTeX2e"
Re: CPANTS: has_signature, has_pod_index
Adam Kennedy wrote: * has_pod_index: The POD contains at least one X<> keyword that helps POD indexers. Whether only one is usefull is open for debate, because at least the license (X), your CPAN ID under authors (x), and some generic keyword what your module (X) is about can probably added even for the most minimal module. Can you give an example of how this has any practical impact on anything? Here is the main page for the project. http://pod-indexing.annocpan.org/wiki/index.cgi They talk only about the Perl core doc at this point, probably because adding keywords there is already enough work. AFAIK the core docs are now covered, so individual modules would be next. Yep, a google-like search engine could save the effort of manually tagging with keywords, but I think this idea is more practical and will improve perldoc greatly. I hate to say it, but this indexing thing has seemed to be ass-backwards to me from the beginning. Instead of having one person combine a Pod Parser and Plucene indexer or some other simple process, they expect the 3500 authors to ADD extra content to all their POD? Well, indexing all of CPAN was never in my original goals. My goal is to make the core documentation more usable, and I haven't seen any automated search engine that does that. For example, let's say you want to find the definition of "scalar". Sure, you can use grep and find that there are 77 documents where "scalar" appears a total of 738 times. But which is the good one? (And which section of the document?) You can try to come up with some clever ranking algorithm, but it is not trivial (and it's not so easy to define things like PageRank[tm] in this case). I'd rather have a human indexer label the place, or just a handful of places, that have the most relevant information for that keyword. Cheers, Ivan
Re: [perl #37627] [BUG] Memory allocation in try_allocate/map_colors
Nick Glencross (via RT) wrote: In r9815 I believe there to be a rare problem with the memory allocation during register colouring. The code is assuming that a maximum of unit->n_symbols exist, but will step outside this range in rare circumstance. The memory allocation and initially setting the flags is ok, but clearing them stomps memory (I believe). Ah yep. The out-of-range case is coming from PASM registers, that already have a 'color' aka register number. I've fixed this now along with a bigger change in imcc SynReg handling, which I will ci soon. Nick Thanks for investigating that, leo
[perl #37627] [BUG] Memory allocation in try_allocate/map_colors
# New Ticket Created by Nick Glencross # Please include the string: [perl #37627] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=37627 > In r9815 I believe there to be a rare problem with the memory allocation during register colouring. e.g. Running t/pmc/freeze_26.pir under valgrind reveals: ==13864== Thread 1: ==13864== Invalid write of size 1 ==13864==at 0x814EFDC: map_colors (reg_alloc.c:811) ==13864==by 0x814EE1A: try_allocate (reg_alloc.c:757) ==13864==by 0x814DE61: graph_coloring_reg_alloc (reg_alloc.c:186) ==13864==by 0x814DCC7: imc_reg_alloc (reg_alloc.c:141) ==13864==by 0x8147A7A: imc_compile_unit (imc.c:72) ==13864==by 0x8147C35: imc_close_unit (imc.c:141) ==13864==by 0x813F226: yyparse (imcc.y:412) ==13864==by 0x8084705: main (main.c:574) ==13864== Address 0x1CBEA23B is 5 bytes after a block of size 6 alloc'd ==13864==at 0x1B903338: malloc (vg_replace_malloc.c:130) ==13864==by 0x80862DC: mem_sys_allocate (memory.c:43) ==13864==by 0x814ED7A: try_allocate (reg_alloc.c:749) ==13864==by 0x814DE61: graph_coloring_reg_alloc (reg_alloc.c:186) ==13864==by 0x814DCC7: imc_reg_alloc (reg_alloc.c:141) ==13864==by 0x8147A7A: imc_compile_unit (imc.c:72) ==13864==by 0x8147C35: imc_close_unit (imc.c:141) ==13864==by 0x813F226: yyparse (imcc.y:412) ==13864==by 0x8084705: main (main.c:574) The code is assuming that a maximum of unit->n_symbols exist, but will step outside this range in rare circumstance. The memory allocation and initially setting the flags is ok, but clearing them stomps memory (I believe). This can also be confirmed by putting prints into imcc/reg_alloc.c. Putting a prints at the allocation and at the flag clearing, you get: Allocate space for 6 register flags Clear flag on register flag 11 Not good, as 11 > 6. I don't currently understand things well enough to submit a fix. Cheers, Nick
Re: Ways to add behavior
HaloO,
Larry Wall wrote:
: or is 'bound of' proper english?
It doesn't really resonate for a native speaker.
--snip--
: > Plus, as we've defined
: >them above, subtypes are the most generic type you can name in Perl.
--snip--
I wasn't using the term "generic" in a type-theoretic sense. Rather,
I was calling them generic in an operational sense, which you just
demonstrated. You can turn any other type into a "subtype" alias that
adds no additional constraints. Maybe I should have said the "widest"
type instead.
With the introduction of kind capture variables ^T we could complety
drop the subtype special form. As you pointed out the adding of constraints
happens with the where clause anyway. Thus we return to the usage of the
compile time name assignment form
::Blahh ::= ::Fasel where {...}
where the :: in all cases means working on the MIR (Meta Information
Repository) which is the world of names (In Russian, Mir (Мир) means
"peace," and connotes "community." --- cited from Wikipedia).
Question: shouldn't there be a natural 1 to 1 relation of ::T and ^T
or globally ::*T and ^*T where the former is the name and the latter
the kind represented by T? Of course scoping applies and there are
anonymous things that can be captured into ^T vars at runtime.
If the answer is 'yes' as I expect, I wonder if the compiler has to restrict
the usage of ::= to scopes which don't depend on runtime evaluations like
if $x < 10 { ::*Surprise ::= ::*FunnyType; say 'did it'; }
Or should these be extracted out, making the above mean
::*Surprise ::= ::*FunnyType; # or further out if necessary
if $x < 10 { say 'did it'; }
: Question: does a subtype declaration work only on package-like things
: which are addressed with a :: sigil? Or does your 'potentially
: contravariant' mean that arrow types can be constraint or aliased, as
: well?
:
: subtype TakesInt of Sub where { .sig =:= :(Int --> Any) };
:
: my TakesInt &foo;
:
: foo('a string'); # type error
Hmm, I would read that as declaring that &foo *returns* a TakesInt,
not that &foo *is* a TakesInt. Just as
my TakesInt @bar;
declares an array of individual TakesInt elements.
This is not too bad because then the & sigil is naturally associated
with the :( --> ) arrow type syntax and the forms can be mixed only
to the extent of signature aliasing:
::Takes3Ints ::= :(Int,Int,Int --> Any);
my &foo:(Takes3Ints);
How does arrow typing apply to the three data sigils $, @ and %?
Compare:
my $foo:(Int); # non-referential value type
my $foo:(-->Int); # same? Or perhaps means anonymous ref/link/alias?
my $foo:(Ref-->Int) # explicit reference? same as 'is ref' trait?
my $foo:(Item: -->Int) # tied container
Which is the default when the Int is used in the type slot of the
declaration?
my Int $foo;
Could this be used to define the key type of hashes?
my %foo:(Blahh-->Any);
And shape of arrays
my @foo:(Int,Int,Int-->Any);
where the Int or subtypes of it are enforced and Any defaulted.
Thus this could just be
my @foo:(!,!,!);
The covariant invocant/container types are of course
my $item :(Item: --> Any);
my @array:(Array: Int --> Any);
my %hash :(Hash: Key --> Any);
The & sigils have a free signature and ^ vars obviously have no signature
other than pure type ;)
--
$TSa.greeting := "HaloO"; # mind the echo!
Re: Ways to add behavior
HaloO,
Stevan Little wrote:
This is actually the principe behind the Ruby style singleton methods
(the shadow class), it basically creates an anon-class which inherits
from $x's original class, then it rebinds/blesses $x into the anon-
class. It is very simple really :)
Yes, it's the typical case were an implementation is way easier than
the (type) theoretical modelling of such a simple "pointer" reassignment.
Assignment in general is very difficult to model, actually.
As for if this is/should be accessible through .meta, i am not sure
that is a good idea. The reason being is that .meta brings with it the
idea of metaclasses, which then relates to classes, and so now the user
is thinking they are accessing the metaclass of the class of which $x
is an instance.
Indeed, we should drop the association of meta with class. There should
be just meta *information* (MI) which is sort of opaque to the general
public. The .meta method should return a MIO (Meta Info Object, My Internal
Object, or what ever) from the MIR (Meta Info Repository). Note that mio in
italian means 'my' or 'mine' depending on the grammatical slot.
I would suggest instead that we have a method, which is found in Object
which allows instances to add methods to themselves (and only
themselves). In Ruby this is called 'add_singleton_method' or something
like that. I use that same name in the metamodel prototype too.
In the absence of that, what's going on seems more like
$x.META::addmethod($arg);
where META:: is smart enough to dispatch to the proper metaclass without
throwing away the invocant, and then the metaclass decides what to do
based on the instancehood of $x.
Since we have imperative runtime forms of 'does' for role composition
why not the equivalent on the 'has' installer. But I know it reads bad.
$x has &action;
$x has &.action = &action; # code slot form
$x does &action; # &action wrapping role created on the fly?
$x gets &action; # new keyword?
But IIRC, re-opening of classes is now done with 'is also' and 'does also'
for extending and 'is instead' and 'does instead' for replacing
functionality. This reads better imperatively on the instance level:
$x has also &action;
In the prototype style the my form could use a class style declarator
block:
my $point
{
has Num $.x = 0;
has Num $.y = 0;
method magnitude { sqrt( $.x**2 + $.y**2 ) }
}
$a = $point; # kind is implicitly copied, that is $a.kind == $b.kind
$b = $point; # which could also be tested with ^$a == ^$b or $a =^= $b
$a.x = 3; # easy with COW and a pseudo-hash implementation of $point kind
$a.y = 4;
say $a.magnitude; # prints 5
I am not sure I like this for 2 reasons.
1) META:: smells like ::SUPER, and that feels like re-dispatching to
me, which is not really what we need to be doing.
I agree. Adding to an object incrementally slides it out of it's class's
kind to ultimately become its own singleton kind. Hmm, this gives us a
beautifully ugly cast operator syntax
$foo.kind = Bar; # re-bless
$foo.kind(Bar); # same?
Bar.bless($foo); # same?
$foo ^= Bar; # kind assignment available?
if Bar{$foo} # theorytic query
{
$foo.kind = Bar; # success guaranteed, I almost wrote: guaran-tied :)
}
$foo.kind = Bar if Bar{$foo}; # as statement modifier
to make such a transition in a single jump. The ^Bar kinding/blessing
of $foo might not succeed unless ^Bar is prepared to accept ^$foo kinds,
though.
And, I think perlkind is expecting persistence of referential identity of
$foo independent of the success or failure of the re-blessing. I guess there
should be a dedicated exception kind to handle that. So you can sport a very
experimental, explorative programming style.
--
Re: CPANTS: has_signature, has_pod_index
* has_pod_index: The POD contains at least one X<> keyword that helps POD indexers. Whether only one is usefull is open for debate, because at least the license (X), your CPAN ID under authors (x), and some generic keyword what your module (X) is about can probably added even for the most minimal module. Can you give an example of how this has any practical impact on anything? Here is the main page for the project. http://pod-indexing.annocpan.org/wiki/index.cgi They talk only about the Perl core doc at this point, probably because adding keywords there is already enough work. AFAIK the core docs are now covered, so individual modules would be next. Yep, a google-like search engine could save the effort of manually tagging with keywords, but I think this idea is more practical and will improve perldoc greatly. I hate to say it, but this indexing thing has seemed to be ass-backwards to me from the beginning. Instead of having one person combine a Pod Parser and Plucene indexer or some other simple process, they expect the 3500 authors to ADD extra content to all their POD? It seems like an absolutely terrible case of CYJ... making the life of the search engine writer easier by making everyone else change. Having the coverage kwalitee bit was bad enough, but supporting a project like this seems far far worse, as I'm not how you this is supposed to be any better than a natural text search of CPAN would be. In fact, it occurs to me I've just uploaded CPAN::Mini::Extract, and if you tied that to Plucene you could probably _have_ an indexer for such a Google'esk search up and running in a day or so. The signature one I don't mind as much, signatures are at least supported in most places and make some kind of sense at some level :) Adam K
