Re: Named parameters vs. slurpy hash syntax: brittle call syntax!
On Thu, 2004-05-06 at 02:36, Dov Wasserman wrote:
After the New And Improved logError() routine is rolled out, it seems to me
that this log statement should generate a compile-time error, since the
named Int parameter prio is given a non-integer argument HIGH. At best,
this should be a run-time error. Either way, this confusion undermines a key
Perl strength: ability of the user to upgrade code (without breaking it).
I strongly disagree. this fact has nothing to do with Perl itself, but
with how you decide to use it. you said Int +$prio because you
*wanted* code to break when prio is not an integer.
we have to cope with new (and greater) strenghts in Perl6, and one of
these is: it's fine for Perl to have a type system as long as it's
optional (cit. A6).
if you upgrade your code to do type-checking, it obviously fails when
type constraints are violated. but you don't have to. you could have
said:
sub logError($msg, +$prio = 4, *%errorInfo) {
# ...
my Str $prio_desc = getPrioDescription($prio) // $prio;
print $prio_desc: $s.\n;
}
or even:
my Str $prio_desc = $prio;
if $prio.isa(Int) {
$prio_desc = getPrioDescription($prio);
}
cheers,
Aldo
Re: Named parameters vs. slurpy hash syntax: brittle call syntax!
Aldo Calpini [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Thu, 2004-05-06 at 02:36, Dov Wasserman wrote:
After the New And Improved logError() routine is rolled out, it seems to
me
that this log statement should generate a compile-time error, since the
named Int parameter prio is given a non-integer argument HIGH. At
best,
this should be a run-time error. Either way, this confusion undermines a
key
Perl strength: ability of the user to upgrade code (without breaking
it).
I strongly disagree. this fact has nothing to do with Perl itself, but
with how you decide to use it. you said Int +$prio because you
*wanted* code to break when prio is not an integer.
I think my statement above was confusing. The should in this log
statement should generate a compile-time error meant if my understanding
of the Apocalypses is correct, this is how Perl 6 *will* behave. The
example was intended to illustrate a case where the method designer never
expected users to invoke the method with a Pair whose key is the string
prio. As far as the designer is concerned, he added a new optional
parameter to the API (namely Int +$prio = 4) that should not and could
not break any existing calls.
Specifying the parameter as type Int (as opposed to being typeless) was not
intended to break any existing code, since no existing code could possibly
be specifying the brand-new parameter named prio. Rather, it is a
reasonable way for the designer to ensure that all newly written calls
explicitly supplying the prio parameter give it an expected Int-typed value.
Aldo Calpini [EMAIL PROTECTED] further wrote:
we have to cope with new (and greater) strengths in Perl6, and one of
these is: it's fine for Perl to have a type system as long as it's
optional (cit. A6).
if you upgrade your code to do type-checking, it obviously fails when
type constraints are violated. But you don't have to. You could have
said:
sub logError($msg, +$prio = 4, *%errorInfo) {
# ...
my Str $prio_desc = getPrioDescription($prio) // $prio;
print $prio_desc: $s.\n;
}
I agree: optional type-checking is a great strength of Perl 6. However, I
don't want to overly complicate my problematic example; type-checking is not
the real problem, it's semantic consistency. I just used types to illustrate
the most dramatic unintended change possible: previously correct code that
will no longer even compile after the additional of a new optional parameter
to a subroutine.
The method designer could indeed add defaulting logic like // $prio as
you indicate above. However, this is only possible if he anticipates that
callers might try to pass non-integer prio values to the method. Since the
parameter is intended to accept an Int, I don't think a method writer should
admit other values. In this admittedly contrived example it might be
possible, but in general when you want an Int (say to internally look up an
element by index), you cannot accept an alterative.
Other legitimate objections to the example notwithstanding, the main point
is this: there should be a very clear language-enforced distinction between:
(A) a method invocation passing a parameter by name
(B) a method invocation passing a Pair object to a positional Pair
parameter
(C) a method invocation passing a Pair object to the slurpy hash
Since my understanding of the need for and use of the slurpy hash is still
limited, I just contrasted case (A) to case (C), but IMHO the concept
applies accross all the categories.
Just my 2¢ (or to be Perl 6 syntax-correct, my ¥2 ;-).
-Dov
Re: Named parameters vs. slurpy hash syntax: brittle call syntax!
On Thu, 2004-05-06 at 02:36, Dov Wasserman wrote:
To distinguish these two cases, what if we used the := binding operator to
bind an argument to a named parameter:
logError($err_msg, prio := 3);
but how would this look like to a subroutine that is not defined to
accept a named parameter called prio? eg. if you decide to reimplement
logError to be just:
sub logError { # implicit ([EMAIL PROTECTED])
# ...
}
using a Pair, you still have someting (a Pair object) that you can
inspect, and eventually decide wether to treat as a named argument or
not. but when you use prio := 3, what do the subroutine get? only 3
in that position? or a Pair anyway? or it doesn't get the 3 at all?
cheers,
Aldo
Re: Named parameters vs. slurpy hash syntax: brittle call syntax!
On Wed, 2004-05-05 at 22:36, Dov Wasserman wrote:
sub logError($msg, Int +$prio = 4, *%errorInfo) {
[...]
logError(Database error, module = DB.pm, line = 263, prio = HIGH);
After the New And Improved logError() routine is rolled out, it seems to me
that this log statement should generate a compile-time error, since the
named Int parameter prio is given a non-integer argument HIGH. At best,
this should be a run-time error.
Ok, stopping there... I'm not sure I know why that would be the case.
It's certainly valid Perl 6 (as far as I know) to say:
my Int $foo = bar;
though at run-time you might ASK for an exception on string-to-number
conversion on things that don't look like strings (as -w gives you in
Perl 5), but I'm not seeing anything in the Apocalypses that says so.
Perhaps if you'd said something like:
sub logError($msg, Int +$prio is strict::Number = 4, *%errInfo) {...}
or something of that sort, I could buy it, but a) there's no way to make
this a compile-time error that I know of and b) why would you want to?
Do you want to say that:
logError($msg, prio=CGI.param(priority))
is an error at compile time because CGI.param is defined as returning a
Str, even though it might well be a numeric value in that string?
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Named parameters vs. slurpy hash syntax: brittle call syntax!
Aldo Calpini [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
if you decide to reimplement logError to be just:
sub logError {# implicit ([EMAIL PROTECTED])
# ...
}
using a Pair, you still have someting (a Pair object) that you can
inspect, and eventually decide wether to treat as a named argument or
not. but when you use prio := 3, what do the subroutine get? only 3
in that position? or a Pair anyway? or it doesn't get the 3 at all?
This cuts to the heart of the meaning of named parameters vs. positionals.
IMO, if you specify a parameter by name as part of a function invocation
[function here meaning any type of sub, method, multi, etc.], the method
dispatch must resolve only to functions with that parameter name declared
in their signature.
In the example you give, invoking logError() with any number of positional
parameters would resolve to the subroutine defined above. But calling
logError(prio := 3) should be a compile-time error, unless another
logError function was defined with a parameter named prio, whether
named-only or positional (since positionals can always be referred to by
name).
When a caller passes a parameter by name to a function, that gives the
compiler more information about which function is intended. I would say it
is (or should be) similar to how Java resolves method calls: the declared
types of the arguments determine at compile-time which method signature is
meant. All other overloaded variants are ignored. Then at run-time, the most
specific overridden method definition with that signature is invoked.
The Perl 6 equivalent for named parameters would be: determine at
compile-time the set of all matching functions of the invoked name declaring
all the parameters named in the invocation. If there are none, you get a
compile-time error like: Could not find any function named 'logError' with
a parameter named 'prio'. If there is more than one candidate (based on
issues like optional parameters and argument types), the best one is
chosen at run-time according to the principles in A12. Of course, there are
other considerations for dispatch; I'm just referring to how parameter names
should work.
Whether you can overload based on nothing more than parameter names remains
an open issue. I'd guess it's like return type, where Larry is leaning
towards allowing override between otherwise-equal definitions.
The drawback to this approach that I can see is that all parameter names are
now part of the function's public API. This does run contrary to the
C-derived languages, but I'm not sure how bad that really is. On one hand it
does break encapsulation, but on the other, it does make clear the intended
meaning of each parameter. So maybe instead of breaking the function's
encapsulation, we can think of it as simply pushing up the parameter names
from private scope into the public scope where they really belong.
Of course, let's not loose sight of the big picture: most functions will
likely not declare named-only parameters. And conversely, the user is always
welcome to pass any or all positional parameters by name as they wish.
However, if the function designer wishes to require that a given parameter
be named, then the language should ensure that a caller meant to pass in an
argument to that parameter, and not any other similar data. Function
designers are always able to get the flexibility you describe above by
declaring a more forgiving signature, or none at all. You can have it either
way you like, just not both ways at once. TMTOWTDI, just not at the same
time!
BTW, please excuse my verbose responses. Now that I've started a new job,
I'll be sure to be briefer in the future ;-)
Regards,
-Dov
Re: Named parameters vs. slurpy hash syntax: brittle call syntax!
Dov Wasserman wrote: My concern is that given an argument supplied as a pair (foo = bar), it is not clear which type of parameter is meant to be supplied. If there is no such named parameter, we know that the argument was intended for the slurpy hash. However, what if the method designer later adds an optional parameter, often to be implemented as a named-only parameter +$foo? ... I have thought a bit about possible fixes, and while there are many possible, I think the best approach would be to separate the related but distinct concepts of supplying an argument to a named parameter from the general Perl 6 notion of a Pair. The problem is, if we supply a different syntax for named parameters, sooner or later somebody's going to want to have the equivalent of a slurpy hash for them. And then we'll have exactly the same ambiguity, except we'll have added even more syntax to a language that's already large and complex. Perl 6 will supply type checking to catch this sort of error, and module versioning to make it easy to work around. Beyond that, module designers who use slurpy hashes will simply have to keep in mind that they need to validate any named parameters they add in later versions. -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: New Group proposed: subs (was Re: named parameters)
"Kyle R . Burton" [EMAIL PROTECTED] writes: use self = 'self'; use self = 'this'; Of course, if you _really_ want to avoid religious wars, you would need a non-selfish pragma name in the first place. -- Johan
Re: New Group proposed: subs (was Re: named parameters)
On Fri, Aug 04, 2000 at 01:36:02AM -0400, Uri Guttman wrote: it looks like typechecking and named params should fork off into a subs subgroup. all of you with an itch to write an rfc, here is your chance. Anyone want to put their hand up as a chair of such a sublist? Damian's got the closest related RFC in the works (named params), but I think he's fairly busy already :) Though if he wants it, that's OK too. K. -- Kirrily Robert -- [EMAIL PROTECTED] -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
Re: New Group proposed: subs (was Re: named parameters)
Damian Conway wrote: One of my many RFCs will include a proposal for a $SELF variable along those lines. Before it's too late - please, don't impose either '$self' or '$this', but make this a per-module choice. I deal with people of both these religions... Hildo
Re: New Group proposed: subs (was Re: named parameters)
Before it's too late - please, don't impose either '$self' or '$this', but make this a per-module choice. I deal with people of both these religions... What about '$me'? It ties in nicely with 'my' (although perhaps for the wrong reasons), it's half as much typing as 'self' or 'this' and we get to annoy both sets of religious zealots at once. :-)= A
Re: New Group proposed: subs (was Re: named parameters)
What about '$me'? It ties in nicely with 'my' (although perhaps for the wrong reasons), it's half as much typing as 'self' or 'this' and we get to annoy both sets of religious zealots at once. :-)= You took the words right out of my...err...fingers! Although, of course, it will be $ME in line with the usual practice of SHOUTING OUT MAGIC VARIABLES. Damian
Re: New Group proposed: subs (was Re: named parameters)
One of my many RFCs will include a proposal for a $SELF variable along those lines. Why not allow for the choice of the name of self, perhaps through a pragma? use self = 'self'; use self = 'this'; or something along those lines -- since it's currently up to the devleoper anyway. Somethign about a capitolized SELF is unappealing to my eyes. k -- -- No one can make you feel inferior without your consent. -- Eleanor Roosevelt [EMAIL PROTECTED]http://www.voicenet.com/~mortis --
Re: New Group proposed: subs (was Re: named parameters)
One of my many RFCs will include a proposal for a $SELF variable along
those lines.
Why not allow for the choice of the name of self, perhaps through a pragma?
use self = 'self';
use self = 'this';
or something along those lines -- since it's currently up to the devleoper
anyway. Somethign about a capitolized SELF is unappealing to my eyes.
$ME will be like other magic variables, so you can always write:
sub self {$ME}
sub this {$ME}
sub I{$ME}
sub one {$ME}
sub obj {$ME}
sub TheObjectThatThisMethodWasInvokedOn { $ME }
# and later
sub shout {
self-set_name(uc this-get_name);
}
Of course, these particular subroutines might be a good (and easy)
target for inlining optimization.
Damian
Re: named parameters
At 04:37 AM 8/4/00 -0600, Tom Christiansen wrote: Point taken. But part of the goal was moving a lot of stuff out of CORE and making Perl faster. New features are great, but we should figure out whether or not they're truly CORE-worthy. Sticking it in a pragma like strict helps to solve this issue, but as always TMTOWTDI. I find the notion that Perl will become appreciably faster simply by having fewer default features to be unlikely. If we go the double-indirect opcode function route, cutting down on the number of opcodes may well help, as will careful grouping of the opcode functions so opcodes that execute in sequence have their function pointers close-by. This'll reduce cache misses, which is a good thing. It also reduces the number of opcodes the optimizer (and the people writing the optimizer) need to deal with, which isn't a bad thing either. (Though, granted, I really doubt anyone'll spend any significant amount of mental effort on the localtime op) Finally, it may make things slightly easier for folks writing JIT/compiler/translators for perl bytecode. If we yank the 'odd' ops out into separate functions, and the doodad writers provide an interface to the non-op functions, it means they don't have to worry about writing code to do localtime however we do it, they can just call our function. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: named parameters
Internals added to cc: On Fri, 04 Aug 2000, Nathan Wiger wrote: Point taken. But part of the goal was moving a lot of stuff out of CORE and making Perl faster. New features are great, but we should figure out whether or not they're truly CORE-worthy. Sticking it in a pragma like strict helps to solve this issue, but as always TMTOWTDI. BTW, I use CORE to mean "perl" and not "perl.tar.gz". Hmmm, is that the generic "we"? (It seems to me that whether something is CORE-worthy is really a decision for the internals team. Whether something should be a valid, meaningful construct in Perl, regardless of the implementation, is the focus of the language team. Perhaps a better job of making this distinction will keep the language list from its current bloat, as skud pointed out. The language list keeps migrating from "why" to "how".) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: named parameters
On Thu, Aug 03, 2000 at 09:39:30AM -1000, Tim Jenness wrote:
Reading through the docs for perl prototypes I see that there is a
reference to "named parameters" being a possibility in future versions of
perl.
Does anyone have a more concrete example of what was intended there?
sub marine ($sailor, $captain) {
$captain-say("One ping only");
}
--
Pray to God, but keep rowing to shore.
-- Russian Proverb
Re: named parameters
Fair enough. If we were going to do it I would like to see it extend to:
sub test ( $x, @y:[N], %z, $fh:isa(IO::Handle) ) {
}
Is there an RFC for this yet? If not, I think there needs to be. I think
this would be really cool.
Because it has opportunity for bloat, I would suggest it should be in a
pragma:
use strict 'prototypes';
-Nate
Re: named parameters
Fair enough. If we were going to do it I would like to see it extend to:
sub test ( $x, @y:[N], %z, $fh:isa(IO::Handle) ) {
}
Is there an RFC for this yet? If not, I think there needs to be. I think
this would be really cool.
I'll have a proposal out later today or tomorrow.
But others ought to consider putting one in too.
Damian
