Front page | perl.perl5.porters |
Postings from February 2018
On Sun, Feb 18, 2018 at 11:12:01PM +0200, Sawyer X wrote:
> Nicholas, thank you for replying in such detail. Please forgive my
> brevity in return.
That is really not a problem.
> On 02/17/2018 12:00 PM, Nicholas Clark wrote:
> > [...]
> > But the first is that we're seriously proposing to (re-)add a special case.
> >
> > Yes, the implementation is full of them. But we should be striving to remove
> > them, not take the viewpoint that "another one isn't going to make much of a
> > difference".
>
> You are right. I thought I had made the decision on changing the syntax
> back in haste and decided to pause and take more time to reflect on it.
> In retrospective, it might have been done in haste, but it's likely to
> be the best of the two options nonetheless.
For some reason your choice of words made me laugh (in a good way).
Which is a good thing on a cold Monday morning.
I think you're right to reflect on it. I'm not meaning to sound pessemistic,
but it does feel somewhat like "least worst choice". Both "suck", but one
"sucks" more than the other. (I think more nuanced, "both have
disadvantages, but the disadvantages of one run far deeper than than the
other".)
I suspect that a lot of this awkwardness comes from how signatures feel like
they are part of the subroutine's name/declaration/"shape", but as soon as
you have defaults they are (implementation wise) part of its body, because
they define the first section of code in the body.
Maybe I'm over-generalising, or making a false connection, but it seems like
it's the same problem/frustration as the (quite reasonable) desire of
various people to provide a way to introspect signatures - "how many
arguments does this function take?", "what types?", with the expectation
that this can be mapped into a data structure. Which it can. Until it can't.
"90%" of cases will, but as soon as defaults are more complex than
constants it unravells.
And over-over-generalising, that makes me think of
If the builtin's arguments cannot be adequately expressed by a prototype
(such as L<C<system>|/system LIST>), L<C<prototype>|/prototype FUNCTION>
returns L<C<undef>|/undef EXPR>, because the builtin does not really
behave like a Perl function. Otherwise, the string describing the
equivalent prototype is returned.
C<prototype> returns the prototype. Unless it can't.
> Thank you, Nick, Zefram, and Yves.
Thank you for all the time you put into this, and trying to ensure that
we're taking decisions that are the least worst trade-off. (Even though we
don't always get it right. Although hopefully we learn from previous
mistakes and oversights, so that we can make brave new mistakes instead of
just riffs and variations of the ones before.)
And it was more fun than what I was doing on Sunday. (I don't know exactly
how they made the ceilings of our house so hard, but it's the most horrible
thing I've ever had to drill into.)
Nicholas Clark
Thread Previous
|
Thread Next