Re: Defaulting params
> I think you're right that this is a valid distinction, I'm just not > sure if it's not a little too subtle and that the two different > notations won't cause confusion. Well, I had been hoping to appeal to the mathematical mindset of the list, but there is a second reason for = in addition to / /=: it's simpler to understand. I just think that the potential Perl hackers will understand = right away but will have to spin a lot of cycles to get / /=, and will meanwhile be wondering why not just =. I'm hoping to point out that = is both logically precise AND more marketable. -Miko
Re: Defaulting params
On Thu, 2002-04-11 at 00:47, Damian Conway wrote:
> sub load_data ($filename) { load_data($filename, 1) }
>
> sub load_data ($filename, $version) {...}
Interesting. This brings goto to mind. Above, I could just assume that
inlining will happen, but what about goto? Obviously:
sub load_data($filename) { goto &load_data }
would be ambiguous, and would throw away the (now lexical) $filename.
I can't see any way to usefully preserve the old new meaning of goto. Is
this a good thing?
Re: Defaulting params
On Wed, Apr 10, 2002 at 10:45:55PM -0600, Luke Palmer wrote:
> Indeed, and with the //= thing, you can let parameters in the middle
> default.
Except that I haven't heard anyone say that given
sub foo ($a//=1, $b//=2, $c//=3) {...}
foo(5,,6); # that this would work.
Will it?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Unary dot
On Thu, 2002-04-11 at 00:42, Luke Palmer wrote:
> > Ah, but I think the mnemonic value of the '.' more than earns its keep
> > here. C is doing a slightly different job
> > anyway. And instance variables are *not* the same as 'normal'
> > variables, they hang off a different symbol table (or syte, to use
> > Damian's oh so clever term from Perl 5+i) and I'm all for things that
> > are different *looking* different.
> >
>
> Well, I certainly don't like the aesthetic value of them. They are ugly
> as Perl 4. But, I have been caught in C++ making all my private variables
> _named _like _this, so I suppose it's analogous. But I don't like being
> forced to do it that way.
>
> What if you just want a simple struct-like thing? That's when it becomes
> really ugly and dislikable. Erm... wait a minute, how would you do that?
>
> $foo = new Foo;
> $foo..instancevar = 7;
> I doubt that's it.
>
> $foo.instancevar = 7;
This should not be allowed. External code should not access instance
variables. We did discuss the idea that accessors would be created
automatically, and coincidentally, you're using the correct syntax for
that above, but certainly there should be the ability to override the
default accessor and to declare an instance variable as accessor-less.
In Perl5 C<$object{instancevar} = 7> is just frowned on. In Perl6, I
thought we had agreed that it would flat out be impossible.
Re: Defaulting params
On Thu, 2002-04-11 at 09:36, Jonathan Scott Duff wrote:
> On Wed, Apr 10, 2002 at 10:45:55PM -0600, Luke Palmer wrote:
> > Indeed, and with the //= thing, you can let parameters in the middle
> > default.
>
> Except that I haven't heard anyone say that given
>
> sub foo ($a//=1, $b//=2, $c//=3) {...}
> foo(5,,6); # that this would work.
>
> Will it?
1, in the above, you could use
foo(5,undef,6);
2, the above is insanely ugly, so I'm now on the "= bandwagon" ;-)
Sure, //= makes sense and should be preserved, but why not allow = too,
since it has an equally obvious meaning, which is far more commonly
desired?
Also, another though:
sub foo($a = 1, $b, $c) { ... }
In C++ at least, I think this is an error. However, it seems to me that
in Perl it could be interpreted to be equivalent to:
sub foo($a = 1, $b = undef, $c = undef) { ... }
Which, again, allows us to clean up the common case.
Re: Defaulting params
[Apologies to Aaron Sherman, who gets this twice due to my
dunderheadedness]
Aaron Sherman <[EMAIL PROTECTED]> writes:
[...]
> Also, another though:
>
> sub foo($a = 1, $b, $c) { ... }
>
> In C++ at least, I think this is an error. However, it seems to me that
> in Perl it could be interpreted to be equivalent to:
>
> sub foo($a = 1, $b = undef, $c = undef) { ... }
>
> Which, again, allows us to clean up the common case.
Not really. The problem (and the reason C++ doesn't allow this) is
that
sub foo($a=1, $b, $c=3) { ... }
is ambiguous: While foo(2) sets $a=1, $b=2, $c=3, it's impossible to
say what foo(4,5) should do.
Hence the C++ rule: all optional matches at the end.
One could also imagine a rule saying all optional matches occur
right-to-left, no matter where they are; this would be very confusing,
though. It's also a bad idea, software-engineering-wise. Say I start
off with
sub bar($a, $b=2, $c, $d=4) { ... }
So bar(11,12,13) matches 11,12,13 -> $a,$b,$c, and bar(1,3) matches
1,3 -> $a,$c. All seems well, until I decide that since anyway $c is
usually 3, I should change the signature and make $c optional too:
sub bar($a, $b=2, $c=3, $d=4) { ... }
Now bar(11,12,13) continues to match 11,12,13 -> $a,$b,$c, but
bar(1,3) matches 1,3 -> $a,$b! So the semantics of old code changes,
silently.
The only ways I can see for optional arguments are:
* all at the end
* at most one
* named arguments
Note that the first 2 *can* be done together (but I'm not sure that
would be a good idea, either). And we already have 3, kinda, by
passing a hash of arguments.
--
Ariel Scolnicov|http://3w.compugen.co.il/~ariels
Compugen Ltd. |[EMAIL PROTECTED]
72 Pinhas Rosen St.|Tel: +972-3-7658117 "fast, good, and cheap;
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555 pick any two!"
Re: Defaulting params
>sub foo($a=1, $b, $c=3) { ... }
>
> is ambiguous: While foo(2) sets $a=1, $b=2, $c=3, it's impossible to
> say what foo(4,5) should do.
foo(2) means that $a = 2, $b defaults to undef, $c defaults to 3
foo(4,5) means $a = 4, $b = 5, and $c defaults to 3.
-Miko
Re: Unary dot
Aaron Sherman writes:
: On Thu, 2002-04-11 at 00:42, Luke Palmer wrote:
: > > Ah, but I think the mnemonic value of the '.' more than earns its keep
: > > here. C is doing a slightly different job
: > > anyway. And instance variables are *not* the same as 'normal'
: > > variables, they hang off a different symbol table (or syte, to use
: > > Damian's oh so clever term from Perl 5+i) and I'm all for things that
: > > are different *looking* different.
: > >
: >
: > Well, I certainly don't like the aesthetic value of them. They are ugly
: > as Perl 4. But, I have been caught in C++ making all my private variables
: > _named _like _this, so I suppose it's analogous. But I don't like being
: > forced to do it that way.
: >
: > What if you just want a simple struct-like thing? That's when it becomes
: > really ugly and dislikable. Erm... wait a minute, how would you do that?
: >
: > $foo = new Foo;
: > $foo..instancevar = 7;
: > I doubt that's it.
: >
: > $foo.instancevar = 7;
:
: This should not be allowed.
Well, that depends on what you mean by "this". :-)
That is, in fact, calling an accessor function, and if it's not allowed,
it's because the attribute is marked private, not because we're against
people thinking of it as a struct.
: External code should not access instance
: variables. We did discuss the idea that accessors would be created
: automatically, and coincidentally, you're using the correct syntax for
: that above, but certainly there should be the ability to override the
: default accessor and to declare an instance variable as accessor-less.
By default attributes are private, which means the corresponding
accessor name is also private. There's no need to override the
automatic accessor merely to make something accessor-less to the
general public.
: In Perl5 C<$object{instancevar} = 7> is just frowned on. In Perl6, I
: thought we had agreed that it would flat out be impossible.
Who agreed to that? First of all, it's perfectly possible that (for a
non-hash) that syntax is isomorphic to
$object.instancevar = 7;
since I've already said that any object can be used as if it were a
hash. Plus we'll have lvalue methods in some fashion or other. Not by
default, of course. It's up to the class to decide how much it wants
to break encapsulation.
Larry
Re: Defaulting params
On Thu, 2002-04-11 at 09:59, Ariel Scolnicov wrote:
> [Apologies to Aaron Sherman, who gets this twice due to my
> dunderheadedness]
No problem. I usually reply to the person and CC the list because some
folks have filters that will make discussions easier if I'm replying to
them vs. sending just to the list. Everyone else can just shut up and
use procmail to filter common message IDs ;-)
> Aaron Sherman <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > Also, another thought:
> >
> > sub foo($a = 1, $b, $c) { ... }
> >
> > In C++ at least, I think this is an error. However, it seems to me that
> > in Perl it could be interpreted to be equivalent to:
> >
> > sub foo($a = 1, $b = undef, $c = undef) { ... }
> >
> > Which, again, allows us to clean up the common case.
>
> Not really. The problem (and the reason C++ doesn't allow this) is
> that
>
>sub foo($a=1, $b, $c=3) { ... }
>
> is ambiguous: While foo(2) sets $a=1, $b=2, $c=3, it's impossible to
> say what foo(4,5) should do.
Nope. Someone else has already pointed out what they expect the behavior
to be in this case (and I concur), but let me state the rules explicitly
(as I would imagine them):
1. The first default marks the beginning of optional parameters.
2. An optional parameter with no default will automatically default to
undef.
That's it. Simple as pie, and always non-ambiguous.
> One could also imagine a rule saying all optional matches occur
> right-to-left, no matter where they are; this would be very confusing,
> though. It's also a bad idea, software-engineering-wise. Say I start
> off with
>
>sub bar($a, $b=2, $c, $d=4) { ... }
>
> So bar(11,12,13) matches 11,12,13 -> $a,$b,$c, and bar(1,3) matches
> 1,3 -> $a,$c. All seems well, until I decide that since anyway $c is
> usually 3, I should change the signature and make $c optional too:
Yikes! I would never do that. Let me re-state my example:
sub foo($a = 1, $b, $c) { ... }
would be the same as
sub foo($a = 1, $b = undef, $c = undef) { ... }
So your example would silently become:
sub bar($a, $b = 2, $c = undef, $d = 4) { ... }
This is much easier to understand. Here are some permutations:
bar(1) => bar(1,2,undef,4);
bar(1,3) => bar(1,3,undef,4);
bar(1,3,8) => bar(1,3,8,4);
bar(1,undef,3) => bar(1,undef,3,4);
The only thing that gets a little tricky is named pairs:
bar(d=>1) => error: a not defined
bar(a=>1, d=>8) => bar(1,2,undef,8);
Makes sense, no?
Re: Unary dot
On Thu, 2002-04-11 at 11:49, Larry Wall wrote:
> Aaron Sherman writes:
> : This should not be allowed.
>
> Well, that depends on what you mean by "this". :-)
[...]
> : In Perl5 C<$object{instancevar} = 7> is just frowned on. In Perl6, I
> : thought we had agreed that it would flat out be impossible.
>
> Who agreed to that? First of all, it's perfectly possible that (for a
> non-hash) that syntax is isomorphic to
>
> $object.instancevar = 7;
We're in violent agreement ;)
What I was saying was that C<$.x> ne C<$obj.x>. One is directly
accessing an instance variable and one is an accessor (which may in fact
be optimized by the compiler in some cases, but the control still lies
in the hands of the class author). Further, I was refering to a previous
thread (no ref handy) where it was stated that instance variables would
be private and accessors would be created automatically (which you
reiterate and clarify in your response here).
I agree that there may be code that looks an awful lot like hash access,
and in practice some of those usages may even BE simple hash access
after compiler optimization. The key difference is that that is all
under the control of the class author (or rather the class author has
the right/ability to give up control). When the author wishes for
something that looks like instance variable access to become a remote
procedure call or have some taint checking performed, this too should be
their choice (and hopefully would not have to involve any Cing or
the like, but would instead fall neatly out of the way accessors work).
I think you have agreed with the above, but I was stating it too quicky
in my original post, and it came out like a statement that the syntax of
instance variable access would never be allowed again, when I was only
refering to the semantic.
Re: I'll show you mine...
At 7:25 AM -0700 4/11/02, Randal L. Schwartz wrote: > > "Dan" == Dan Sugalski <[EMAIL PROTECTED]> writes: > >Dan> (Or maybe attributed string eval, like: > >Dan> $foo = eval.Parrotset I0, 12 >Dan> sub I0, I0, 5 >Dan> EOP > >That would make more sense to me (for whatever that's worth) as > >$foo = Parrot.eval < set I0, 12 > sub I0, I0, 5 > EOP > >Or am I missing something? I was thinking we'd be throwing an attribute on string eval telling it which parser rules to use (hence the .Parrot on the end, which is probably the wrong syntax) rather than having each set of parser rules be a separate class with an eval method. The syntax probably should've been "eval is Parrot" or something like that. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Defaulting params
On Thu, 2002-04-11 at 11:55, Aaron Sherman wrote:
> 1. The first default marks the beginning of optional parameters.
> 2. An optional parameter with no default will automatically default to
> undef.
Interestingly, I just said something that I did not mean to, but it
opens up an interesting avenue. As I understand it, right now we have:
sub foo ($a;$b, $c) { ... }
Which indicates taht $b and $c are optional.
If we go with the above defaulting rules, we could dump the semi-colon
(to be re-used for something else?) in favor of:
sub foo ($a, $b=undef, $c) { ... }
Slightly longer, but a unifying syntax between defaulting and optional
parameters!
Speaking of defaults, has anyone talked about C++'s instance variable
defaults? I don't like thier system, but the case of:
const myobj foo(1,2,3); // C++
Is a tough one. As I understand it, in Perl that's:
my $foo = myobj.new(1,2,3) but const;
Or is that
my $foo is myobj(1,2,3) but const;
Either way, is the constructor allowed to manipulate the embryonic $foo?
For those who don't know, in C++ this is resolved by the following
syntax:
class myobj {
...
int a,b,c;
myobj(int aa, int bb, int cc) :
a(aa), b(bb), c(cc) const {}
...
};
Notice that the constructor itself does nothing to this "const instance"
that is being contstructed by the instance variable defaults.
It's a fine syntactical line, and I don't like how much the compiler has
to think about what C really means. But, I have to admit I'm at a
loss for other ways to allow safe compilation of const instantiations.
Re: Defaulting params
> class myobj {
> ...
> int a,b,c;
> myobj(int aa, int bb, int cc) :
> a(aa), b(bb), c(cc) const {}
> ...
> };
Ummm no. Straight from Bjarne: "You can't have a const constructor." You
just do what you did without the const. A const myobj is essentially
equivalent (with the exception of not being allowed to call methods not
marked 'const', except the constructor) to:
class myobj {
const ...
const int a,b,c;
` myobj(int aa, int bb, int cc) :
a(aa),b(bb),c(cc) { }
};
So you're initializing the const variables just like you would instance
consts. The constructor can't alter them, but the initializer (thing
before the constructor) can.
But, this isn't a C++ list, so on to Perl. I should certainly hope you can
have instance constants. They can be quite useful, though optimization
doesn't work as well for them.
Oh, and just so you know, I'm basically a C++ linguist. I have practically
memorized Bjarne's The C++ Programming Language. And by that, I maintain
that C++ is the _best_ compiled language. Or at least in my opinion.
Luke
Re: Defaulting params
On Thu, 2002-04-11 at 12:44, Luke Palmer wrote:
> > class myobj {
> > ...
> > int a,b,c;
> > myobj(int aa, int bb, int cc) :
> > a(aa), b(bb), c(cc) const {}
> > ...
> > };
>
> Ummm no. Straight from Bjarne: "You can't have a const constructor." You
> just do what you did without the const. A const myobj is essentially
> equivalent (with the exception of not being allowed to call methods not
> marked 'const', except the constructor) to:
I'm not much of a C++ fan, as you can tell. What he said, but my point
stands in a somewhat modified capacity
Do we have a way to do this, or do we not do it, or do we adopt a silly
C++-like style?
Re: Defaulting params
Aaron Sherman <[EMAIL PROTECTED]> writes:
> On Thu, 2002-04-11 at 00:47, Damian Conway wrote:
>
>> sub load_data ($filename) { load_data($filename, 1) }
>>
>> sub load_data ($filename, $version) {...}
>
> Interesting. This brings goto to mind. Above, I could just assume
> that inlining will happen, but what about goto? Obviously:
>
> sub load_data($filename) { goto &load_data }
>
> would be ambiguous, and would throw away the (now lexical)
> $filename.
>
> I can't see any way to usefully preserve the old new meaning of
> goto. Is this a good thing?
If we're getting continuations then, where we're going we won't need
goto.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Defaulting params
Miko O'Sullivan writes: : > I think you're right that this is a valid distinction, I'm just not : > sure if it's not a little too subtle and that the two different : > notations won't cause confusion. : : Well, I had been hoping to appeal to the mathematical mindset of the list, : but there is a second reason for = in addition to / /=: it's simpler to : understand. I just think that the potential Perl hackers will understand = : right away but will have to spin a lot of cycles to get / /=, and will : meanwhile be wondering why not just =. I'm hoping to point out that = is : both logically precise AND more marketable. Leaving marketability aside for the moment, I don't buy the argument that it's a feature for the user to be able to pass an undef past the default. The primary purpose of the default is to guarantee the semantics of the function, not to make life easier for the caller. If that also happens, it's a nice side effect. Larry
Re: Defaulting params
On Thu, 2002-04-11 at 14:34, Larry Wall wrote:
> Miko O'Sullivan writes:
> : Well, I had been hoping to appeal to the mathematical mindset of the list,
> : but there is a second reason for = in addition to / /=: it's simpler to
> : understand. I just think that the potential Perl hackers will understand =
> : right away but will have to spin a lot of cycles to get / /=, and will
> : meanwhile be wondering why not just =. I'm hoping to point out that = is
> : both logically precise AND more marketable.
>
> Leaving marketability aside for the moment, I don't buy the argument
> that it's a feature for the user to be able to pass an undef past the
> default. The primary purpose of the default is to guarantee the
> semantics of the function, not to make life easier for the caller.
> If that also happens, it's a nice side effect.
Hmmm... I have to disagree with you there.
Consider this bit of Perl5 which I've done in various forms:
sub nukeuser {
my $user = shift;
my $pwf = shift;
$pwf = '/etc/passwd' unless defined $pwf;
my $backup = @_ ? shift @_ : "$pwf.bak";
my $do_backup = defined($backup);
...
}
Notice that we have two different types of defaulting here. The second
argument is the file to work on, and we set it to a reasonable default
if it is undefined for whatever reason. However, the third argument is
sensitive to undef vs no parameter. In the case of not getting a third
arguement, a reasonable default is set. If an argument is given, but it
is undef, no backup will be performed.
We're not just makeing life easier for the caller. What we're doing is
extracting as much information from the arguments as possible (just as
many Perl functions do). With //=, there's simply some data thrown away.
In Perl6, this might be:
sub nukeuser ($user, $pwf //= 'passwd', $backup = "$pwf.bak") {
my $do_backup = defined $backup;
...
}
[I don't know if you can use a parameter to default another parameter.
It would be nice, but I can see why you wouldn't.]
Without an "=" operator here, you would need to add another argument to
flag doing backups or not (not really the Perl Tao) or you would have to
do the argument processing manually, which sort of defeats the whole
point.
Re: Unary dot
> "David" == David Whipp <[EMAIL PROTECTED]> writes: David> If every object has a C method (C?), then you could David> always call class-methods as class.m2(). Wouldn't that be .class.m2(), or did I miss something in the flurry? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Defaulting params
At 04:03 PM 4/11/2002 -0400, Aaron Sherman wrote:
>On Thu, 2002-04-11 at 14:34, Larry Wall wrote:
> > Miko O'Sullivan writes:
>
> > : Well, I had been hoping to appeal to the mathematical mindset of the
> list,
> > : but there is a second reason for = in addition to / /=: it's simpler to
> > : understand. I just think that the potential Perl hackers will
> understand =
> > : right away but will have to spin a lot of cycles to get / /=, and will
> > : meanwhile be wondering why not just =. I'm hoping to point out that = is
> > : both logically precise AND more marketable.
> >
> > Leaving marketability aside for the moment, I don't buy the argument
> > that it's a feature for the user to be able to pass an undef past the
> > default. The primary purpose of the default is to guarantee the
> > semantics of the function, not to make life easier for the caller.
> > If that also happens, it's a nice side effect.
>
>Hmmm... I have to disagree with you there.
>
>Consider this bit of Perl5 which I've done in various forms:
>
> sub nukeuser {
> my $user = shift;
> my $pwf = shift;
> $pwf = '/etc/passwd' unless defined $pwf;
> my $backup = @_ ? shift @_ : "$pwf.bak";
> my $do_backup = defined($backup);
> ...
> }
>
>Notice that we have two different types of defaulting here. The second
>argument is the file to work on, and we set it to a reasonable default
>if it is undefined for whatever reason. However, the third argument is
>sensitive to undef vs no parameter. In the case of not getting a third
>arguement, a reasonable default is set. If an argument is given, but it
>is undef, no backup will be performed.
So we have undef and reallyundef? :)
>We're not just makeing life easier for the caller. What we're doing is
>extracting as much information from the arguments as possible (just as
>many Perl functions do). With //=, there's simply some data thrown away.
>
>In Perl6, this might be:
>
> sub nukeuser ($user, $pwf //= 'passwd', $backup = "$pwf.bak") {
> my $do_backup = defined $backup;
> ...
> }
>
>[I don't know if you can use a parameter to default another parameter.
>It would be nice, but I can see why you wouldn't.]
>
>Without an "=" operator here, you would need to add another argument to
>flag doing backups or not (not really the Perl Tao) or you would have to
>do the argument processing manually, which sort of defeats the whole
>point.
I would typically handle this with overloading the function instead.
Its definitely easier for the reader to understand that way, in my opinion.
Else your function prototypes become a language of their own.
I wish we would stick to simple semantics, allow overloading, allow
a single operator for a default argument, and follow the C++ style of
ambiguity resolution.
-Melvin
Re: I'll show you mine...
> "Dan" == Dan Sugalski <[EMAIL PROTECTED]> writes: Dan> (Or maybe attributed string eval, like: Dan> $foo = eval.Parrotsub I0, I0, 5 Dan>EOP That would make more sense to me (for whatever that's worth) as $foo = Parrot.eval < http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
