Argument aliasing for subs

[Peter Behroozi]

Hello All,

Has anyone considered a syntax for allowing subroutines to have many
different names for the same argument? For example, in CGI.pm, many
methods support the "-override" parameter but can also accept the alias
of "-force":

$cgi->hidden(-name => "a", -override => 1); #same as
$cgi->hidden(-name => "a", -force => 1);

As far as I can guess, we could use the binding operator to make it work
something like this**:

sub hidden (str $name; int $force, int $override:=$force) { ... }

or maybe even

sub hidden (str $name; int $override:=int $force) { ... }

I have doubts about that last one, since I suspect that people will want
to know what

$force = "dp/dt";
sub work ($distance, $push:=$force) { ... }

is supposed to do, but these are only suggestions. Anyone else want to
shed light on the matter?

Thanks,

Peter Behroozi

**Of course, the real CGI::hidden() also has the "-default" named
argument, but I left that out for clarity.

[mosul...@crtinc.com]

From: Peter Behroozi behr...@www.pls.uni.edu

> Has anyone considered a syntax for allowing
> subroutines to have many different names for
> the same argument? For example, in CGI.pm, many
> methods support the "-override" parameter but
> can also accept the alias of "-force":

Yes. See the thread starting at
http://archive.develooper.com/perl6-l...@perl.org/msg09551.html . The
end result was that Damian liked the idea and leans towards a syntax like
this:

sub load_data (
$filename_tainted is named('filename'),
$version_input is named('version','ver') //= 1)
{...}

-Miko

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

[Damian Conway]

Peter Behroozi wrote:

> Has anyone considered a syntax for allowing subroutines to have many
> different names for the same argument?

If it were allowed, it would probably be done via properties instead:

sub hidden (str $name, int $force, int $override is aka($force)) { ... }

Damian

[mosul...@crtinc.com]

From: Damian Conway dam...@conway.org

> If it were allowed, it would probably be done
> via properties instead:
>
> sub hidden (str $name, int $force, int $override is aka($force))
> { ... }

Would the following be simpler...?

sub hidden (str $name, int $force is aka($override))
{ ... }

Damian's statement says to me that there is an argument named $force, and
another argument named $override which is also known as $force... that
sounds conflicting. The revised statement simply says that there's an
argument named $force and it is also known as $override.

BTW, the aka thing is cool. It could be complementary to "is named":

# can't use force_tainted as argument:
sub hidden (int $force_tainted is named($force))

# can use force_tainted as argument:
sub hidden (int $force_tainted is aka($force))

[Peter Behroozi]

From: Damian Conway dam...@conway.org
> If it were allowed, it would probably be done
> via properties instead:
>
> sub hidden (str $name, int $force, int $override is aka($force))
> { ... }

How does this method affect the non-parameter-based calling scheme? It
looks like it is possible to use three arguments in the call to
hidden(). While this doesn't matter for this case, it might if another
named argument was tacked on to the end, like this:

sub hidden (str $name, int $force, int $override is aka($force),
int $pretty_print);

print hidden('name',1,1); #<-- What does this do?

I think that the slight modification of Damian's original solution is
the best:

sub hidden (str $name, int $force is aka('override')) { ... }

Then there is no question that "override" is Just Another Name for
"force" (eliminating weird things like "$force is aka(@override)"), the
problem of argument order in normal sub calls goes away, and there is a
happy minimum of extra syntax.

By the way, thanks for pointing out the original discussion; I haven't
been on the list long enough to have known that it existed.

Peter Behroozi

[Damian Conway]

mosul...@crtinc.com wrote:

>> sub hidden (str $name, int $force, int $override is aka($force))
>> { ... }
>
>
> Would the following be simpler...?
>
> sub hidden (str $name, int $force is aka($override))
> { ... }

Yeah, that's what I meant.

Sorry. I've travelled 14,000 miles and given 93 hours of
presentations in the last 18 days. [Note to self: no more
posting whilst semi-conscious!!!]

%-)

> BTW, the aka thing is cool. It could be complementary to "is named":
>
> # can't use force_tainted as argument:
> sub hidden (int $force_tainted is named($force))
>
> # can use force_tainted as argument:
> sub hidden (int $force_tainted is aka($force))

Yes, that was the idea. :-)

Damian

[Erik Steven Harrison]

> sub hidden (str $name, int $force is aka($override))
> { ... }

I know that the property syntax is pseudo established,
but I'm beggining to become a bit jaded about all the
built in properties were building. What about good ol'
aliases?

sub hidden (str $name, int $force := $override)
{ . . .}

While less verbose, it's actually more legible to me,
in that the prototype (we still calling it that?)
get's less visual clutter.

In a related note, even if the 'is aka($am, $are,
$also_known_as) = 'Electric Mayhem')' syntax get's
establsihed will the alising trick still work? Or are
we stepping on the Perl 6 rule against leaking lexical
scopes?

-Erik

Is your boss reading your email? ....Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com

[Erik Steven Harrison]

Somewhere, in another thread . . .
Dr. Claw wrote . . .

>> sub hidden (str $name, int $force is aka($override))
>> { ... }
>

>Yeah, that's what I meant.

Is it just me or is the 'is' property syntax a little
too intuitive? Seems like everywhere I turn, the
proposed syntax to solve a problem is to apply a
property. And is the is/but distinction still around?
Since but's proposal I've not seen any use of it, and
the distinction between a compile time and run time
property was somewhat hazy to me anyway, so I can't be
sure that it's dead or just of rare use.

[Peter Behroozi]

On Thu, 2002-09-05 at 04:31, Damian Conway wrote:
> sub hidden (str $name, int $force is aka($override)) {...}

Hang on a moment! In your original answer to this question, you used
the "is named('alias')" syntax, but now you are suggesting using the
sigil in the syntax. So, should it really be

int $force is aka($override)

or

int $force is aka('override')

?

I much prefer the latter because: a) it unquestionably marks 'override'
as a label for $force, b) the subroutine author is likely to use either
$force or $override and not both, c) it gives meaning to things like
"$force is aka(@override)" because aliases would not have to be known at
compile-time.

Then again, if you have good reasons for the other syntax, I would be
more than happy to hear those as well.

Peter Behroozi

[Erik Steven Harrison]

--

On Thu, 05 Sep 2002 09:31:45
Damian Conway wrote:

>Erik Steven Harrison wrote:
>
>> I know that the property syntax is pseudo established,
>> but I'm beggining to become a bit jaded about all the
>> built in properties were building. What about good ol'
>> aliases?
>>

>> sub hidden (str $name, int $force := $override) {...}
>
>I'm not keen on it because it will be hard to explain
>(or detect) the difference between that and:
>
> sub hidden (str $name, int $force //= $override) {...}
>

Just found this hidden in my inbox. I didn't think anyone was paying attention ;-).

I think that the difference can be swept under the table in a handwavy sort of manner by pointing out that these subroutine declarations shouldn't be pointing to globals or widely scoped lexicals like that. But this all brings me back to the question of lexical leaking. Are $name and $force lexical to the sub? I know that we are trying to avoid lexical scopes leaking into each other, but I honestly can't figure out how that rules and these argument declarations interact. Someone care to explain?

>What I most like about the C<is> syntax is (like methods in
>OO Perl), it associates a meaningful *name* with each
>deviation from standard behaviour.

This is the argument that would win me over to the property syntax. Self documenting code is an admirable goal. But I wonder about our overuse of 'is'. The performance issues of a hash that lives with every variable aside, it all looks the same to me. And I like different things to look different. In a related note, I'm always confused by whether or not we look at the value of the variable or it's name. See below . . .

>
>I find:

>
> sub hidden (str $name, int $force is aka($override)) {...}
>

>*much* more readable, since I can read it in English.

Yeah . . . except I want at least single quotes around that darn $override. Required singles even. Having it be context sensitive to the type of property is WAY to subtle for me. And if $override is a reference I'd like that to DWIM (though I understand that I may be the only person for which that behavior is intuitive). And what happens with double quotes - a symref? Ack!

If $force is aka(@override) is going to be a compile time error, then why can't we just $force is aka(override) and just carry the typing over. And if it's not a compile time error then what in Knuth's name does it . . . . oh never mind - my head just exploaded.

-Erik

>
>Damian
>
PS - Ha! My name above Damian's :-)

[Erik Steven Harrison]

reposted because my mailer is evil

[Erik Steven Harrison]

--

On Thu, 05 Sep 2002 09:26:08

Damian Conway wrote:
>Erik Steven Harrison wrote:
>
>

>> Is it just me or is the 'is' property syntax a little
>> too intuitive? Seems like everywhere I turn, the
>> proposed syntax to solve a problem is to apply a
>> property.
>

>That's because most of the problems we're discussing are solved
>by changing the semantics of a variable, subroutine, or class
>in some way, and C<is> properties are the way to do that in Perl 6.

>
>
> > And is the is/but distinction still around?
>

>Oh, yes.

Thanks goodness.

>
>
>> Since but's proposal I've not seen any use of it, and
>> the distinction between a compile time and run time
>> property was somewhat hazy to me anyway, so I can't be
>> sure that it's dead or just of rare use.
>

>Of rare use (nice turn of phrase, BTW).

Thanks.

But still, what counts as a runtime property, other than true or
false, as in the delightful '0 but true'? What other kind of runtime
labels can I slap on a value?

-Erik

[Brent Dax]

Erik Steven Harrison:
# But still, what counts as a runtime property, other than true or
# false, as in the delightful '0 but true'? What other kind of runtime
# labels can I slap on a value?

These occur to me:

$foo=0 but string("zero");
$bar='foobar' but num(1);
$baz=1 but string("one") but tainted;

FWIW, though, I think we can probably get away with 'is' only and
tagging of properties:

#XXX are classes properties? Will they look something like
this?
class string is property('run') {
method INIT($targ: $strval) {
$targ.prop{string}=$strval;
}

method operator:_($targ:) {
return $targ.prop{string};
}
}

class aka is property('compile') {
method INIT($me: $targ: *@names) {
# $foo.prop{name} is the FIRST name given to
that, i.e., the first
# variable it was bound to.
my $targname=$targ.prop{name}.substr(1,
$targ.prop{name}.length-1);

# $targ.prop{scope} is the stash of the FIRST
name given to it.
my $scope = $targ.prop{scope};

# $scope.num is a hash mapping names to
positions.
my $num = $scope.num{$targname};

for @names -> $name {
$scope.num{$name} = $num;
}
}
}

class named is property('compile') {
method INIT($me: $targ: *@names) {
my $targname=$targ.prop{name}.substr(1,
$targ.prop{name}.length-1);

my $scope = $targ.prop{scope};
my $num = $scope.num{$targname};

$scope.num.delete($targname);

for @names -> $name {
$scope.num{$name} = $num;
}
}
}

--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

"In other words, it's the 'Blow up this Entire Planet and Possibly One
or Two Others We Noticed on our Way Out Here' operator."
--Damian Conway

[Steve Canfield]

Damian Conway wrote:
>>And is the is/but distinction still around?
>
>Oh, yes.

Could someone please reference where this decision was made. I do not find
any information describing the distinction.

Steve

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com

[Me]

> Damian Conway wrote:
> >>And is the is/but distinction still around?
> >
> >Oh, yes.
>
> Could someone please reference where this decision was
> made. I do not find any information describing the distinction.

The following May 2001 post was related. Poke around the
thread it was in, especially posts by Larry or Damian:

http://archive.develooper.com/perl6-l...@perl.org/msg07604.html

----

Btw, I've created a tiny url for using google groups to search
for posts by Larry or Damian in perl 6 lists since early May
2002 (google doesn't have archives prior to then :<).

http://tinyurl.com/1ce0

(Some posts similar to those shown will have been filtered
out; you can fix that by going to the last page and clicking
the 'repeat the search with the omitted results included' link).

--
ralph

[Damian Conway]

Peter Behroozi wrote:

>> sub hidden (str $name, int $force is aka($override)) {...}
>
>
> Hang on a moment! In your original answer to this question, you used
> the "is named('alias')" syntax, but now you are suggesting using the
> sigil in the syntax.

Yes, but for a *different* property.

The idea of the C<is named> property is that it *changes* the external key by
which you specify the corresponding parameter when using named parameters.
That is:

sub foo ($bar is named('baz')) {
print $bar; # Okay
print $baz; # Error (not a real param)
}

foo(bar=>1); # Error (not known by this name externally)
foo(baz=>1); # Okay

Whereas the <is aka> property *adds* an alias for the corresponding parameter,
when using named parameters. That is:

sub foo ($bar is aka($baz)) {
print $bar; # Okay
print $baz; # Okay (Just another name for $bar)
}

foo(bar=>1); # Okay
foo(baz=>1); # Okay (Just another key meaning bar=>1 )

> So, should it really be
>
> int $force is aka($override)

Yes.

> or
>
> int $force is aka('override')

No, not the way I intended it.

> I much prefer the latter because: a) it unquestionably marks 'override'
> as a label for $force,

It's not meant to be. That's what C<is named> would be for.

> b) the subroutine author is likely to use either
> $force or $override and not both,

Possibly. But if it's truly an alias, they should be able to use both.

> c) it gives meaning to things like "$force is aka(@override)"

True. Though it would be more useful in reverse:

sub foo (@bar is aka($baz)) {
# now @bar is an array
# and $baz is an array ref
}

> Then again, if you have good reasons for the other syntax, I would be
> more than happy to hear those as well.

Then I hope this made you happy. ;-)

Damian

[Trey Harris]

In a message dated Sun, 8 Sep 2002, Steve Canfield writes:

> Would it be accurate to say that "is" sets properties of variables, whereas
> "but" sets properties of values? If so, what would this output:
>
> my $var is true;
> $var=0;
> if ($var) {print "true"}
> else {print "false"}
>
> I would expect it to output "false".

Why? I believe that, whatever you set $var to, you have marked the
variable as constantly true in booleans.

Where this gets weird is that someone might write:

sub foo {
my $result is true;
# (do stuff setting result)
if $success {
return $result;
} else {
return undef;
}
}

Thinking that the initial "is true" will cause the test

if foo() ....

will always be true if the sub succeeded, even if $result was zero. But I
don't think that's how it works, since the C<return> will pass the
*value*, which has not been tagged with "but true", not the variable,
which has been tagged with "is true". So the test will fail when $result
was zero. (Unless there's something going on where the "is true" property
confers a property to the value, which I suppose is possible, but weird.)

My guess is that

return $foo but true;

will become a common piece of Perl 6 idiom.

Trey

[Steve Canfield]

Would it be accurate to say that "is" sets properties of variables, whereas
"but" sets properties of values? If so, what would this output:

my $var is true;
$var=0;
if ($var) {print "true"}
else {print "false"}

I would expect it to output "false".

_________________________________________________________________

[Steve Canfield]

>From: Trey Harris <tr...@sage.org>
>To: Steve Canfield <canfie...@hotmail.com>

> > I would expect it to output "false".
>

>Why? I believe that, whatever you set $var to, you have marked the
>variable as constantly true in booleans.

Because in my experience variables are not true or false. They reference
values that are true or false. That is why I want to understand if "is"
sets properties of variables or values.

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

[Uri Guttman]

>>>>> "SC" == Steve Canfield <canfie...@hotmail.com> writes:

SC> Would it be accurate to say that "is" sets properties of variables,
SC> whereas "but" sets properties of values? If so, what would this output:

SC> my $var is true;

that is not a variable property so it should be a compile time error.

SC> $var=0;
SC> if ($var) {print "true"}
SC> else {print "false"}

SC> I would expect it to output "false".

it won't even compile so i don't expect output. :)

this wasn't clear enough when it was discuss. you can't set data
properties on a variable and vice versa. 'is' sets variable props and
'but' sets data props. runtime stuff will usually check data props
(maybe readonly which is a variable prop would be checked then
too). compile time stuff will deal with variable props.
OO will be a different story as all the my Dog $spot threads have
shown. until that apocalypse i won't venture how OO will deal with props.

uri

--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

[Damian Conway]

Erik Steven Harrison wrote:

> Just found this hidden in my inbox.
> I didn't think anyone was paying attention ;-).

Oh, we *always* pay attention. We just don't always respond. ;-)

>>What I most like about the C<is> syntax is (like methods in
>>OO Perl), it associates a meaningful *name* with each
>>deviation from standard behaviour.
>
> This is the argument that would win me over to the property syntax.
> Self documenting code is an admirable goal. But I wonder about our
> overuse of 'is'.

Think of it as punctuation. As a necessary alternative to the poor
overworked colon.

> The performance issues of a hash that lives with every variable aside,

They're not really relevant with C<is>, since it's compile-time in effect.

> it all looks the same to me. And I like different things to look different.

A fair point. My counterargument is that you're looking at the wrong bit.
C<is aka(...)>, C<is named(...)>, C<is constant>, etc all look very similar,
structurally. But so do C<$obj.foo()>, C<$obj.bar()>, and C<$obj.baz()>.
Yet we cope quite well with the OO syntax, because we look at the different
method names, not the shared dot introducer.

Properties have a great deal in common with methods, and so it really
should be surprising that they're invoked in a structurally similar manner.
Think s/<dot>/is/.

>>I find:
>>
>> sub hidden (str $name, int $force is aka($override)) {...}
>>
>>*much* more readable, since I can read it in English.
>
> Yeah . . . except I want at least single quotes around that darn $override.
> Required singles even. Having it be context sensitive to the type of property
> is WAY to subtle for me. And if $override is a reference I'd like that to DWIM (
> though I understand that I may be the only person for which that behavior is intuitive).
> And what happens with double quotes - a symref? Ack!

Then why don't you want single quotes around the C<$name> and C<$force>?
After all, they're not being evaluated there either.

The C<is aka> would be a form of auxiliary declaration, so it's quite as
reasonable not to put annoying quotes around it. It just means that the
parameter list of the property would be declared with one of Larry's
postulated C<is parsed(/<Perl.variable>/)> properties.

> If $force is aka(@override) is going to be a compile time error, then why can't we
> just $force is aka(override) and just carry the typing over.

So you can't stand a bare declarative variable, but you'd accept a bareword??? ;-)

The rason I'd do it the way I've suggested is precisely so that if someone's flawed
mental model causes them to write:

$force is aka(@override)

that *logical* bug in their thinking is detected and flagged.

> And if it's not a compile time error then what in Knuth's name

Now, now, no need to invoke deities! ;-)

> oh never mind - my head just exploded.

Hang in there. If these "mixed number" C<aka>s were allowed then I'd suggest
the semantics be that they indicate that *either* a scalar or array is
acceptable in the corresponding argument slot. The scalar variant of the
parameter would be bound to a scalar argument, or to a reference to an array
argument. The array variant of the parameter would be bound to an array
argument, or it's zeroth element bound to a scalar argument.

> -Erik
>
>>Damian
>
> PS - Ha! My name above Damian's :-)

Letting me get the last word, eh? Very kind of you. ;-)

Damian

[Damian Conway]

Erik Steven Harrison wrote:

> But still, what counts as a runtime property, other than true or

> false, as in the delightful '0 but true'? What other kind of runtime

> labels can I slap on a value?

Here's ten to start with...

for <> but tainted(0) {...} # note that external data is
# from a trusted source

return 255 but undef; # i.e. system() returns
# "undefined 255" on failure

return $cached_for{$arg} but Cached
//= compute_for($arg); # memoize return value
# but mark when from cache

$result = heuristic($data) but Estimated
unless %known{$data}; # indicate when value is a guess

my $temp is Units('Celsius') # indicate units of variable
= 273 but Units('Kelvin'); # indicate units of value
# (maybe autoconverted?)

return $val but Error(-1..+2); # indicate error bars

$data = $text but Encrypted($public_key);
# unusable without private key

$days = 29 but From(My.line); # record source of
# improbable value

$days = 29 but Reason("Leap year");
# so-called "active comment"...
# documents why improbable value
# used but can also be retrieved
# programmatically

$name = "Damian" but We_better_call_ya("Bruce");
# indicate correct Australian
# pronunciation ;-)

Damian

[Steve Canfield]

>From: Uri Guttman <u...@stemsystems.com>

>that is not a variable property so it should be
>a compile time error.

I was under the impression that compile time properties, like runtime
properties, can be arbitrarily invented and/or assigned. If that is
correct, why would "my $var is true", meaningless though it is,
result in a compile time error? If my perception was incorrect, what
was the logic behind the decision that compile time properties must
be part of a predefined set, but runtime may be arbitrarily defined?
Or is there another explanation that I'm missing? I think my
paradigm is shifting without a clutch.

Steve

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx

[Damian Conway]

Steve Canfield wrote:

> I was under the impression that compile time properties, like runtime
> properties, can be arbitrarily invented and/or assigned.

Yes, but not purely lower-case ones. They're reserved for Perl 6 itself.
(i.e. only Larry can invent/assign them ;-)

> If that is
> correct, why would "my $var is true", meaningless though it is,
> result in a compile time error?

Because it's lower-case, but not a standard built-in property.

> If my perception was incorrect, what
> was the logic behind the decision that compile time properties must
> be part of a predefined set,

There is no such requirement. Indeed, there will almost certainly
be possible to define an <is True> property yourself (note the
capitalization). And it could quite easily cause any value assigned
to it to be ascribed C<but true>.

Damian

[Erik Steven Harrison]

--

On Sun, 08 Sep 2002 22:24:11
Damian Conway wrote:

>
>Think of it as punctuation. As a necessary alternative to the poor
>overworked colon.
>

Or the poor overworked dot?

>
>
>> it all looks the same to me. And I like different things to look different.
>
>A fair point. My counterargument is that you're looking at the wrong bit.

A fair counterargument (a new programming game -
badmitton!)

At this point I originally had a long reply stating my
feelings. In the course of writing it and trying to
anticiplate Damian's counter counter counter arguments
the reply grew and grew until I realized I had changed
sides. But I'll assemble what thoughts were worth
salvaging into a different post and see where they go,
and get Damian off of the CC list :-).

>Hang in there. If these "mixed number" C<aka>s were allowed then I'd suggest
>the semantics be that they indicate that *either* a scalar or array is
>acceptable in the corresponding argument slot. The scalar variant of the
>parameter would be bound to a scalar argument, or to a reference to an array
>argument. The array variant of the parameter would be bound to an array
>argument, or it's zeroth element bound to a scalar argument.

I think that my problem here lies that I want to treat
a property as either a lvalue or a subroutine call,
and my brain keeps screaming "Watch out for variable
interpolation!". I've been bitten by that enough in my
early module writing days that the fear comes quickly.
What I need (and I hope I'm not alone, or with too
much company) is to know exactly what the is does
here. What kind argument is it taking? Value, name, or
reference? Once I pin that down, the whole thing
should be clear.

>
>
>> -Erik
>>
>>>Damian
>>
>> PS - Ha! My name above Damian's :-)
>
>Letting me get the last word, eh? Very kind of you. ;-)

Touche ('cept with an accent on the e there). Maybe were fencing, not playing badmitton.

-Erik

>
>Damian