Re: When can I take given as read?
sub factorial (Int $n is topic) {
return 1 when 0;
return $n * factorial $n;
}
hmm, could we write...
sub foo (Class $self is topic: +$foo, +$bar) {
.method;
}
to avoid having to use ./
?
Cheers,
Carl
Re: When can I take given as read?
Carl Franks [EMAIL PROTECTED] writes:
sub factorial (Int $n is topic) {
return 1 when 0;
return $n * factorial $n;
}
hmm, could we write...
sub foo (Class $self is topic: +$foo, +$bar) {
.method;
}
to avoid having to use ./
?
Yay!
Re: When can I take given as read?
Carl Franks skribis 2005-06-21 8:54 (+0100):
hmm, could we write...
sub foo (Class $self is topic: +$foo, +$bar) {
.method;
}
For such a short method, perhaps just using $_ directly makes more
sense:
sub foo (Class $_: +$foo, +$bar) {
.method;
}
to avoid having to use ./
There are many ways to avoid it.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: AUTLOAD and $_
I think there exists an even simpler way to avoid any mess involved.
Instead of letting AUTOLOAD receive and pass on arguments, and instead
of letting AUTOLOAD call the loaded sub, why not have AUTOLOAD do its
thing, and then have *perl* call the sub?
sub AUTOLOAD ($whatever) { # but no [EMAIL PROTECTED]
my $s = get_subref_for $whatever;
our ::($whatever) := $s;
return $s; # non-subref indicates failure
}
You are of course assuming that every use of AUTOLOAD, for all time,
will result in
a) Calling another function
b) An error
Wouldn't this lead to hacks where people do things like this just to
prevent perl thinking it's a failure?
sub AUTOLOAD ($whatever) { # but no [EMAIL PROTECTED]
my $s = get_subref_for $whatever;
our ::($whatever) := $s;
return sub () { 1 };
}
The ability to get complete control over the params and context of the
function, and maybe run something else AFTER the function call is important.
So I suspect there might be some false economy in this optimisation.
Adam K
Re: AUTLOAD and $_
On 6/21/05, Adam Kennedy [EMAIL PROTECTED] wrote:
You are of course assuming that every use of AUTOLOAD, for all time,
will result in
a) Calling another function
b) An error
Wouldn't this lead to hacks where people do things like this just to
prevent perl thinking it's a failure?
sub AUTOLOAD ($whatever) { # but no [EMAIL PROTECTED]
my $s = get_subref_for $whatever;
our ::($whatever) := $s;
return sub () { 1 };
}
The ability to get complete control over the params and context of the
function, and maybe run something else AFTER the function call is important.
I think people are being pretty closed-minded about closures. If it
comes down to it, you can always get your good old Perl 5 AUTOLOAD
like this:
sub AUTOLOAD ($whatever) { sub ([EMAIL PROTECTED]) {
...
} }
Luke
Re: ./method defunct
On Mon, Jun 20, 2005 at 07:34:57PM -0400, Kurt wrote: On 6/18/05, Juerd wrote: Why exactly is the slash not acceptable for you? Almost everyone has said they like it. I personally find ./method prettier and easier to type than any of the alternatives. I don't like it because I think method calls should look like method calls, and the slash separating the dot and name makes it look like something else entirely. On 6/19/05, Juerd wrote: David Storrs skribis 2005-06-19 13:45 (-0400): All that said, I still agree with John... './' does not look like method call syntax to me. That's good, because it's different from all other method syntax anyway, because it does not have any left hand side -- not even implied. I don't think it's good. A method call should look like a method call. What are the salient characteristics of looks like a method call? Is it no intervening characters between the . and the name of the method? Frankly, I don't understand the objection to using a keyword for $?SELF, such as `self`. Um ... isn't $?SELF a keyword? :-) Most other object-oriented languages use such a keyword, if not exactly the same one, so it will be a familiar concept. Certainly more readily understood for a newcomer than `./method`. I think the difference in how readily understood it is will be infinitesimally small. What's confusing about ./method is shorthand for $?SELF.method? As a bonus, `self` is easily searchable within the documentation, whereas `./` is not. I'll grant you that. But, as punctuation rich as perl is, we should provide a tool (p6doc?) to help with the searching and encourage people to use it. I missed responding to the thread the last time this subject came up, but the more I see this syntax the less I like it, so I wanted to add another voice to the dissention. However, if it remains official, I expect I'll simply be naming my invocants, as chromatic has suggested. I expect that soon after perl6 is released (heck, maybe before it's released) we'll get tools that will translate perl6 to perl6 while performing some syntactic manipulation. For instance, it could explicitize code (replacing ./method with $?SELf.method and .foo with $_.foo and so on) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: ./method defunct
What does this have to do with perl6-internals? F-up to p6l. Matthew Zimmerman skribis 2005-06-21 11:27 (-0400): $self-_fraction * $self-concentration + $s2-_fraction * $s2-concentration You can still write it like that, if you declare a name ($self) for the invocant. Added to Perl is a shortcut, not a replacement. ./:fraction * ./concentration + $s2.:fraction * $s2.concentration That looks silly indeed, and is a good reason for not using ./foo HERE. It's not a good reason to not have ./foo at all. and it gives me the willies. Then don't use it. You don't have to use it. If I have a complicated mathematical expression If you have anything that is complicated, a verbose version should always be considered, if only to avoid getting lost in punctuation. This is not specific to ./foo in any way. with method calls in it (which happens a lot for me), the '/' part of './' in particular gives me lots of visual problems. It is visually much more suited for action than functional use: ./foo($bar, $baz); # beautiful print 5 + ./foo($bar); # ugly at the top of my code if I have to, but I want to make one last gasp at getting $Larry / @Larry to reconsider this. I find o. absolutily horrifying. But then, that's apparently how you think of ./, so we have to trust Larry's decision on this. I don't think further discussing this is really fruitful, as it has already been discussed more than is good for us. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ./method defunct
Jonathan Scott Duff skribis 2005-06-21 10:00 (-0500): I expect that soon after perl6 is released (heck, maybe before it's released) we'll get tools that will translate perl6 to perl6 while performing some syntactic manipulation. For instance, it could explicitize code (replacing ./method with $?SELf.method and .foo with $_.foo and so on) Deparse. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: AUTLOAD and $_
Adam Kennedy skribis 2005-06-21 12:10 (+1000):
You are of course assuming that every use of AUTOLOAD, for all time,
will result in
a) Calling another function
b) An error
That is more or less what it's for. Do note that this other function
that is called can be entirely statementless, thus a no-op.
Wouldn't this lead to hacks where people do things like this just to
prevent perl thinking it's a failure?
There is nothing we can do to prevent dumb programmers from doing dumb
things, except dropping lots of features and operators. But if we wanted
that, adding lexicals and closures to PHP would probably be easier.
sub AUTOLOAD ($whatever) { # but no [EMAIL PROTECTED]
my $s = get_subref_for $whatever;
our ::($whatever) := $s;
return sub () { 1 };
Then the subref will not be executed, and the bug will very quickly be
discovered. I don't see any problem with this.
There are also people who don't understand that TIE* methods should
return objects, because they are constructors. Has this ever been a
great problem?
If there is a fixed interface that makes sense and is documented, people
not following it are either really dumb or very clever.
The ability to get complete control over the params and context of the
function, and maybe run something else AFTER the function call is important.
I disagree. In that case you should be using a wrapper or a macro. A
wrapper you can simply return, but I find it very bad style to install
foo and then run foo plus something else. And if you don't install foo
(with foo := ...), you can do whatever you want anyway, by putting
whatever you want in the closure.
So I suspect there might be some false economy in this optimisation.
It's not an optimization. It's necessary, unless there is a way to
receive arguments in unknown context, which is a bit of complexity and
complication we can very easily avoid needing.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: AUTLOAD and $_
On Tue, 2005-06-21 at 13:35 +, Luke Palmer wrote: I think people are being pretty closed-minded about closures. I'm pretty closed-minded about writing code that does nothing to prevent the language from doing the wrong thing by default. I already have a fantastic way to write code that does nothing: I don't write it. Maybe I don't really want AUTOLOAD, though. Juerd's MISSINGSUB (or whatever the name is) has some merit, especially from a better name for what I want to do perspective. -- c
Re: ./method defunct
Juerd wrote: What does this have to do with perl6-internals? F-up to p6l. Sorry! Typing faster than my brain is working. Resent to the right list. If I have a complicated mathematical expression If you have anything that is complicated, a verbose version should always be considered, if only to avoid getting lost in punctuation. This is not specific to ./foo in any way. If I'm calling a method on $?SELF five times in a statement and you're only calling one once, wouldn't such an operator be more important to me than to you? I'm not arguing that having a short way to call a method on the current invocant-- be it operator or keyword-- is a bad thing. It's a great feature, and why I'm delurking to comment on this. If 'o.' really doesn't work, it doesn't work. We could pick a different operator. I'm just saying that the particular choice of './' doesn't work for me (and evidently a number of other people). It is visually much more suited for action than functional use: ./foo($bar, $baz); # beautiful print 5 + ./foo($bar); # ugly Right here, in my mind, is an argument against it. I'd end up using the operator in some places and not others, because in some contexts it'd be ugly and others beautiful. Thus further reducing the visual consistency of the code. I haven't yet given up on the idea that there's a shortened operator that would be more universally readable. at the top of my code if I have to, but I want to make one last gasp at getting $Larry / @Larry to reconsider this. I find o. absolutily horrifying. But then, that's apparently how you think of ./, so we have to trust Larry's decision on this. I don't think further discussing this is really fruitful, as it has already been discussed more than is good for us. Fair point. I mean no offense, nor do I wish to beat a dead horse. I just want to make sure it's dead, instead of merely resting. -- Matt Matthew Zimmerman Interdisciplinary Biophysics, University of Virginia http://www.people.virginia.edu/~mdz4c/
Re: ./method defunct
[Sorry, sent this to the wrong list by mistake.]
Matthew Zimmerman wrote:
Juerd wrote:
Kurt skribis 2005-06-20 19:46 (-0400):
On 6/20/05, Juerd wrote:
Or you can just get your self with a simple (module that does)
macro self () { '$?SELF' }
And you could do the same for `./`.
Certainly.
However, there has proven to be much demand for something like ./method,
and in such cases, having it by default is probably the best thing.
I personally don't think it's either necessary or too much. I care about
.method using $_, and many other people care about having short syntax
for self.method too. ./method was something that would work for me, so I
shared that idea, and it was generally accepted.
Apart from the personal joy of seeing something I invented become part
of the official language, I don't really care if ./method is eventually
part of Perl 6 or not. I have always named my invocants, and don't mind
continue to do so. On the other hand, if there is a shorthand, I will
use it, because regardless of whether you think it's pretty or ugly, and
regardless of whether you think it looks enough like a method call,
having a short two character operator for this is in fact very
convenient.
Could we revisit the idea of using a shorter keyword for $?SELF, like
'o'? I know that $Larry said the idea was probably not going to work:
http://tinyurl.com/7baz6
but I'm curious if the reasoning that killed it then still holds now,
now that './' has emerged as a replacement.
Count me among the './' dissenters, too. The virtual explosion of new
operators in Perl 6 has not concerned me too much, as I don't envision
myself using many of them, but the operation that './' does is something
I do very frequently. I'm just imaging a lot of my Perl 5 code like:
if ( $self-unit_id == $s2-unit_id ) {
$self-add_component(
$self-_fraction * $self-concentration +
$s2-_fraction * $s2-concentration
);
$self-update;
}
replaced with:
if ( $.unit_id = $s2.unit_id ) {
./add_component(
./:fraction * ./concentration +
$s2.:fraction * $s2.concentration
);
./update;
}
and it gives me the willies. If I have a complicated mathematical
expression with method calls in it (which happens a lot for me), the '/'
part of './' in particular gives me lots of visual problems.
I'll put
macro o () { '$?SELF' }
at the top of my code if I have to, but I want to make one last gasp at
getting $Larry / @Larry to reconsider this.
--
Matt
Matthew Zimmerman
Interdisciplinary Biophysics, University of Virginia
http://www.people.virginia.edu/~mdz4c/
Re: AUTLOAD and $_
chromatic skribis 2005-06-21 9:23 (-0700): I already have a fantastic way to write code that does nothing: I don't write it. Just add braces around the thing you don't write. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: AUTLOAD and $_
On Mon, Jun 20, 2005 at 07:09:42PM -0500, Rod Adams wrote: : S10 talks about how it is AUTOSUB vs AUTOMETH (and others), but AUTOLOAD : is still around. S10 doesn't mention it, but I think it's been said that : AUTOLOAD only gets called as a last resort. Really, the only point of keeping AUTOLOAD around is to make it easier to translate Perl 5 to Perl 6. AUTOSUB and friends have the spiffy reference-returning semantics everyone wants. I'd like the translator to be able to turn goto foo into foo.tailcall or some such, and otherwise leave AUTOLOAD alone. Larry
Re: AUTLOAD and $_
Larry Wall wrote: On Mon, Jun 20, 2005 at 07:09:42PM -0500, Rod Adams wrote: : S10 talks about how it is AUTOSUB vs AUTOMETH (and others), but AUTOLOAD : is still around. S10 doesn't mention it, but I think it's been said that : AUTOLOAD only gets called as a last resort. Really, the only point of keeping AUTOLOAD around is to make it easier to translate Perl 5 to Perl 6. AUTOSUB and friends have the spiffy reference-returning semantics everyone wants. I'd like the translator to be able to turn goto foo into foo.tailcall or some such, and otherwise leave AUTOLOAD alone. Should we then perhaps rename it to: DEPRECATED_PERL5_AUTOLOAD ? -- Rod Adams
