Re: Still about subroutines...
On Thu, Sep 16, 2004 at 01:44:03PM -0500, Jonathan Scott Duff wrote: : On Thu, Sep 16, 2004 at 10:07:29AM -0700, Larry Wall wrote: : > I like $-, $+, and $? the best. Probably should save $- and $+ for something : > complimentary, which leaves $?. It's visually distinctive, and recently : > came available. :-) : : Speaking of which ... why is it that $?foo and became $<> : and <> respectively? Mostly because I got tired of seeing too many question marks meaning too many things in too many rules. And because the original notion was that the question mark in $?foo indicated a hypothetical variable, which turned out to be mostly orthogonal to whether a variable was stored in $0, so the C ended up indicating nothing questionable. And because it's really kind of bogus to use variable notation for things that aren't really variables anyway. And because it worked out to be the same notation for the C<$0«foo»> syntax and the C<$«foo»> shorthand syntax on the lookup end of things. And because I didn't want the capturing form of rules to be longer than the non-capturing form (ignoring the issue of Texas quotes). And I wanted to make it so that any angle rule could turn into a capture rule. Even if we allowed C to prefix any other assertion like C, it's just more visual noise, unlike brackets which kind of cancel each other out visually and make a nice "pill". So just as [] turn into () to capture into an array, <> turn into «» to capture into a hash, where we already use «» notation for constant keys. Plus I figured we might have some other good use for $?foo some day. Other than that, no good reason, just a gut feeling. Larry
Re: Still about subroutines...
On Thu, Sep 16, 2004 at 01:40:47PM -0600, Luke Palmer wrote: : Larry Wall writes: : > I like $-, $+, and $? the best. Probably should save $- and $+ for something : > complimentary, which leaves $?. It's visually distinctive, and recently : > came available. :-) : : Hmm, $& is pretty good, and it's associated with subs mnemonically, just : as $= is associated with lines (but a little more visually in that : case). Except that only one of these variables' meanings is actually associated with subs. And I kind of like to read the C as "which". So if we actually make use of our sigils, we get possibilities like this: $?file Which file am I in? $?line Which line am I at? $?package Which package am I in? @?package Which packages am I in? $?moduleWhich module am I in? @?moduleWhich modules am I in? $?class Which class am I in? @?class Which classes am I in? $?role Which role am I in? @?role Which roles am I in? $?grammar Which grammar am I in? @?grammar Which grammars am I in? &?sub Which sub am I in? @?sub Which subs am I in? $?sub Which sub name am I in? &?block Which block am I in? @?block Which blocks am I in? $?block Which block label am I in? Some of those may be sillier than others. But the fact that these all contain a C is a good visual indication that they're all potentially generic in meaning when you use them in a macro. I kinda like that. : I just wonder whether people will get confused between these: : : $&sub : &$sub The real killer is &&sub. Larry
Re: Still about subroutines...
Larry Wall writes: > I like $-, $+, and $? the best. Probably should save $- and $+ for something > complimentary, which leaves $?. It's visually distinctive, and recently > came available. :-) Hmm, $& is pretty good, and it's associated with subs mnemonically, just as $= is associated with lines (but a little more visually in that case). I just wonder whether people will get confused between these: $&sub &$sub Though the latter ought to be written: $sub() Nowadays. Luke
Re: Still about subroutines...
- Original Message - From: Juerd <[EMAIL PROTECTED]> Date: Thursday, September 16, 2004 2:55 pm Subject: Re: Still about subroutines... > Jonathan Scott Duff skribis 2004-09-16 13:44 (-0500): > > Speaking of which ... why is it that $?foo and became > $<>> and <> respectively? > > perlcheat is one page. I hope that when Perl 6 is around, I can > summarize all uses of << and >> on one page. The second page will > be for > the rest of the syntax :) Don't forget to leave a whole page each for * and : too. :) - Joe
Re: Still about subroutines...
Jonathan Scott Duff skribis 2004-09-16 13:44 (-0500): > Speaking of which ... why is it that $?foo and became $<> > and <> respectively? perlcheat is one page. I hope that when Perl 6 is around, I can summarize all uses of << and >> on one page. The second page will be for the rest of the syntax :) Juerd
Re: Still about subroutines...
On Thu, Sep 16, 2004 at 10:07:29AM -0700, Larry Wall wrote: > I like $-, $+, and $? the best. Probably should save $- and $+ for something > complimentary, which leaves $?. It's visually distinctive, and recently > came available. :-) Speaking of which ... why is it that $?foo and became $<> and <> respectively? And FWIW, I kinda like $& even with the over-done & :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Still about subroutines...
On Thu, Sep 16, 2004 at 10:02:18AM -0600, Luke Palmer wrote:
: The new alternative is MY.sub. I suppose that could return the current
: actual sub, so if you're using a pointy sub you have to say MY.block or
: something. But it's one of those two.
Or something resembling them. I'm still pining for sigils on MY values.
Plus the method notation is problematic: people will wonder why
sub ($x) {
MY.sub($x - 1);
}
doesn't work, not realizing that they'd have to say
MY.sub()($x - 1);
So we're probably going to end up with another secondary sigil, since
it's a weird magical metanamespace. I was going to combine with the
$=DATA magical pod stream namespace, but there's a subtle difference
between a file-scoped metavariable that is the same everywhere in
the file and a lexically scoped metavariable that varies everywhere
in the file. So we probably need a different "ssigil". Here are the
candidates, leaving out brackets and already-used ssigils. (And Unicode).
$`line
$~line
[EMAIL PROTECTED]
$#line
$&line
$-line
$+line
$\line
$|line
$;line
$'line
$"line
$,line
$?line
$/line
I like $-, $+, and $? the best. Probably should save $- and $+ for something
complimentary, which leaves $?. It's visually distinctive, and recently
came available. :-)
So maybe $?sub is the name of the current sub, while &?sub is a reference
to the current sub. Maybe $?block is the label on the current block, while
&?block is a ref to the closure?
Larry
Re: Still about subroutines...
Michele Dondi writes:
> Speaking of subs, and especially recursive ones which have been
> mentioned en passant earlier, I have another question "of mine": I
> know that in the vast majority of cases this won't be useful in any
> way, but in the body of a (possibly anonymous) sub/block, will there
> be some sort of identifier to refer to itself? I mean, in such a way
> to be able create anonymous recursive functions. In Perl5 it's doable
> by means of some trickery that involves an assignment, anyway.
It used to be &_. But that's changing now to be aliased to the slurpy
block if one exists, and to the target sub of a wrapper.
The new alternative is MY.sub. I suppose that could return the current
actual sub, so if you're using a pointy sub you have to say MY.block or
something. But it's one of those two.
> Thinking of it better lexicals will be in package MY, right, so a possibly
> not too out of question choice may be MY::_self (with underscore to avoid
> unwanted collisions with user stuff). Something like (hopefully):
>
> print sub -> $n {
> # Admittedly stupid example!
> return $n if $n<=1;
> MY::_self($n-1) + MY::_self($n-2);
> }.(10);
You have a redundancy there: "sub" and -> both mean the same thing, so
use one or the other. If you use "sub", the argument list has to be
parenthesized.
Luke
Still about subroutines...
Speaking of subs, and especially recursive ones which have been mentioned
en passant earlier, I have another question "of mine": I know that in the
vast majority of cases this won't be useful in any way, but in the body of
a (possibly anonymous) sub/block, will there be some sort of identifier to
refer to itself? I mean, in such a way to be able create anonymous
recursive functions. In Perl5 it's doable by means of some trickery that
involves an assignment, anyway.
Thinking of it better lexicals will be in package MY, right, so a possibly
not too out of question choice may be MY::_self (with underscore to avoid
unwanted collisions with user stuff). Something like (hopefully):
print sub -> $n {
# Admittedly stupid example!
return $n if $n<=1;
MY::_self($n-1) + MY::_self($n-2);
}.(10);
Michele
--
> I do have backups, just not recent ones.
I think my wife is now pregnant.
She has a supply of birth control pills and she does use them,
just not recently. ;)
- Jim Lisson in alt.windows98, slightly edited
Re: S5: grammar compositions
On Wed, 2004-09-15 at 12:47 -0700, [EMAIL PROTECTED] wrote: > Grammar roles? > > Larry Hmm, actually a few questions on the topic: S5 doesn't specify whether grammars can have attributes. Can they? Can they have methods, or at least local subs, to call from the code within the rules? Can grammars inherit from classes/roles (to pull methods into their namespace, for code within the rules)? Can classes inherit from grammars? (to pull their rules into their namespace) Miro
Re: [S3, S4, S5]: =~ becomes ~~
> Okay, it ought to be there soon. I added it in the "New operators" > section, since it's pretty different from =~. That'd also be appropriate, but I didn't see an explicit mention anywhere... > Arguably the ~~ table should go in S3 instead of S4. It most likely should, since ~~ is an operator, despite the origin of the tables... -- Schwäche zeigen heißt verlieren; härte heißt regieren. - "Glas und Tränen", Megaherz
Re: How would I do this in Perl6? #1
On Tue, 14 Sep 2004, Larry Wall wrote:
> : So what I would like to do is (i) C the list of templates to a list
> : of curried closures in which the first parameter is fixed to each given
> : template, (ii) C this list by means of right pipe binop
> : ( C<< ==> >> ) with a "starting value" (leftmost) of, say, @input.
>
> It probably depends on just how we implement infix:==>. Looking for
> a righthand argument that is curried to have all of its arguments
> except for a list is one way to look at it. But all our currying so
> far is explicit, and ==> in some sense wants to auto-curry its right
> side to return some function with a missing list, even if it isn't
> written that way, which means it's perhaps acting more like a macro
> than a first-class function. But just because the actual binary ==>
Well, then maybe ==> is not the right infix operator. Mathematically one
has the binary associative operation of "composition". Will Perl6 provide
such an operator? It seems that ==> (or <== for a more "traditional"
approach) could not be the right one since *in this context* it would pass
its right argument to its left one, and not the output of the former as
wanted ()...
Also, mathematically, if one has a function of, say, two variables,
f : A x B -> C
it's common to indicate the function obtained by fixing one, say the
first, of them by
f(a,-) : B -> C
So similarly Perl may support a similar syntax by means of suitable
"placeholder variables" (obviously in a different sense than the already
existing one!)
> arguments of each ==> autocurry their own righthand arguments. I suspect
> there's a way to write it, since we defined the splat list as just a
> funky named parameter. Probably something like
>
> my $result =
> (@input ==>
> reduce &operator:==>,
> map { &*pack.assuming(:template($_)) }, @templates
> );
So it seems that currying will be allowed only on named parameters, won't
it?!?
Well, I guess this won't matter much here, but I've the *impression* that
Perl6 rich parameter passing mechanism will be *too* powerful (to be
flexible enough).
> Mind you, I wouldn't write such code anywhere I expected anyone with
> less than a PhD to stumble across, even if I ain't got one myself.
Well I do *not* have a PhD myself, but it seems I have an inclination for
functional languages-like constructs.
And maybe I'm simply a strange guy, but a solution along the lines of that
quoted above would be the most clear satisfying for me, for it makes
obvious what is done in turn: (i) the list of templates is mapped to a
list of functions, (ii) this list is reduce()d by means of composition of
functions, (iii) the resulting function is evalutated on @input. And
there's been no need to introduce or use intermediate variables (apart
the "default one", $_).
Michele
--
> [are there] Any areas of mathematical knowledge or skills that we lost?
Yes, but I don't remember what they are.
- Kevin Foltinek on sci.math [edited]
Re: How would I do this in Perl6? #1
On Thu, 16 Sep 2004, Michele Dondi wrote: > On Tue, 14 Sep 2004, Matt Diephouse wrote: > > > Or in Perl 5, which has to use 2 subs to have the same interface (code ^^^ ^^^ > Huh?!? [code snipped] Oops! Sorry, I hadn't noticed that! To be honest I have not checked what the interface you proposed actually was. The way I've written it is how I'd do it *in any case*. But then the point is *not* writing a sub to do that, for it is a priori obvious that the are tons of WTDI: I'd be rather interested in the possibility of doing it *the way I proposed* in the OP, which I find conceptually appealing. Michele -- 'Most any OS will also support either read(2) or some equivalent. Most support read(2) directly: Win32 does, though it also has its own set of functions, in the classic Microsoft fashion of not doing a thing well once when you can do it badly five times. - Ben Morrow in clpmisc, "Re: Perl's read() vs. sysread()"
Re: How would I do this in Perl6? #1
On Tue, 14 Sep 2004, Matt Diephouse wrote:
> Or in Perl 5, which has to use 2 subs to have the same interface (code
^
^
Huh?!?
#!/usr/bin/perl -l
use strict;
use warnings;
sub extp ($@) {
my $t=shift;
@$t ? return @_ :
pack shift @$t, extp $t, @_;
}
sub extup ($@) {
my $t=shift;
@$t ? return @_ :
unpack shift @$t, (extup $t, @_);
}
print for extup [qw/L* w u/],
extp [qw/u w L*/], 1..5;
__END__
--
> 4 words: it-was-a-joke!
4 words: he-has-no-clue!!
- Uri Guttman on clpmisc (slightly edited)
