Mailing List Archive: Perl: porters

autosay

Index | Next | Previous | View Threaded

tchrist at perl

Feb 27, 2012, 5:23 AM

Post #1 of 14 (154 views)
Permalink

autosay

Is there some reason why say() wasn't made a weak
keywork the way lock is? That way, if the user already
had a function by that name, we would not override their
version, but if they didn't, then they'd get Perl's.

In particular, this "error" message:

$ perl -e 'say "hello there"'
String found where operator expected at -e line 1, near "say "hello there""
(Do you need to predeclare say?)
syntax error at -e line 1, near "say "hello there""
Execution of -e aborted due to compilation errors.
Exit 255

Seems really stupid. Since it knows what to do, why doesn't
it just do it?

--tom

perl.p5p at rjbs

Feb 27, 2012, 6:10 AM

Post #2 of 14 (150 views)
Permalink

Re: autosay [In reply to]

* Tom Christiansen <tchrist [at] perl> [2012-02-27T08:23:33]
> Is there some reason why say() wasn't made a weak
> keywork the way lock is? That way, if the user already
> had a function by that name, we would not override their
> version, but if they didn't, then they'd get Perl's.

I've wondered that myself, but I don't think I've ever asked.

I had a *very* brief look and found these hints:

| feature.pm is for new syntax, not for every kind of change in perl.
| The features given, say and state are all keywords that can't be parsed
| as functions. You can't backport them as modules to older perls
| (unless you use source filters). That's not the case of reftype() and
| friends. With reasonable prototypes they can completely behave as
| functions. Weak keywords is the way to go.
-- http://markmail.org/thread/kcnnaqy4b6jay72x

So weak keywords were intended for things that could be functions, and
backported?

| I thought this was the sort of thing that would have been used with
| the feature pragma to pull in. The whole purpose of adding it was to
| avoid the issues of weak keywords with say and other new features for
| Perl 5.10.
-- http://markmail.org/message/5thn7y3wqp7dqefh

So weak keywords have issues we wanted to avoid?

Both are just tiny fragments of larger conversations, and there's a
bunch of context I don't have or remember. What one *could* do would be
to find the commit that adds 'say' (or 'feature.pm') and look for
threads around that time... but right now I have to run out the door!

--
rjbs

Attachments:

signature.asc (0.48 KB)

h.m.brand at xs4all

Feb 27, 2012, 6:15 AM

Post #3 of 14 (150 views)
Permalink

Re: autosay [In reply to]

On Mon, 27 Feb 2012 06:23:33 -0700, Tom Christiansen <tchrist [at] perl>
wrote:

> Is there some reason why say() wasn't made a weak
> keywork the way lock is? That way, if the user already
> had a function by that name, we would not override their
> version, but if they didn't, then they'd get Perl's.
>
> In particular, this "error" message:
>
> $ perl -e 'say "hello there"'
> String found where operator expected at -e line 1, near "say "hello there""
> (Do you need to predeclare say?)
> syntax error at -e line 1, near "say "hello there""
> Execution of -e aborted due to compilation errors.
> Exit 255
>
> Seems really stupid. Since it knows what to do, why doesn't
> it just do it?

auto-weak keywords were "abandoned" when the weak operator "err" (or
"dor" was banned. I still miss it. "err" was a keyword, not a function,
but maybe the same rules apply. Needing features never appealed to me.

Personally I see more value in the return of "err" (or "dor") then in
making say a weak keyword, but all our priorities differ.

With still too many old(er) perls around to target, I seldom use say.

--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

ikegami at adaelis

Feb 27, 2012, 1:11 PM

Post #4 of 14 (144 views)
Permalink

Re: autosay [In reply to]

On Mon, Feb 27, 2012 at 8:23 AM, Tom Christiansen <tchrist [at] perl> wrote:

> Is there some reason why say() wasn't made a weak
> keywork the way lock is?

Maybe because that wouldn't prevent the keyword from breaking the following?

say("foo");
sub say { }

public at khwilliamson

Feb 27, 2012, 1:26 PM

Post #5 of 14 (146 views)
Permalink

Re: autosay [In reply to]

On 02/27/2012 02:11 PM, Eric Brine wrote:
> On Mon, Feb 27, 2012 at 8:23 AM, Tom Christiansen <tchrist [at] perl
> <mailto:tchrist [at] perl>> wrote:
>
> Is there some reason why say() wasn't made a weak
> keywork the way lock is?
>
>
> Maybe because that wouldn't prevent the keyword from breaking the following?
>
> say("foo");
> sub say { }
>

I asked this question a while back, and someone, perhaps rgs, gave me a
satisfactory IMO reason.

paul at pjcj

Feb 27, 2012, 2:11 PM

Post #6 of 14 (145 views)
Permalink

Re: autosay [In reply to]

On Mon, Feb 27, 2012 at 02:26:48PM -0700, Karl Williamson wrote:
> On 02/27/2012 02:11 PM, Eric Brine wrote:
> >On Mon, Feb 27, 2012 at 8:23 AM, Tom Christiansen <tchrist [at] perl
> ><mailto:tchrist [at] perl>> wrote:
> >
> > Is there some reason why say() wasn't made a weak
> > keywork the way lock is?
> >
> >
> >Maybe because that wouldn't prevent the keyword from breaking the following?
> >
> >say("foo");
> >sub say { }
> >
>
> I asked this question a while back, and someone, perhaps rgs, gave
> me a satisfactory IMO reason.

I've wondered for a little while now whether it wouldn't be useful to
have some sort of document describing design decisions.

Some design decisions are reached only after much debate. Years later,
people who were not involved in those discussions may not understand why
they were taken. We've seen a fair bit of this recently.

The text could probably be copied from mail messages, or perhaps it
could just be the final message from the pumpking. Or, perhaps better
still, it could be the reference to the git commit where the design is
explained.

Perhaps we have already decided we don't want such a document.

Why did we do that?

--
Paul Johnson - paul [at] pjcj
http://www.pjcj.net

rgs at consttype

Feb 28, 2012, 1:25 AM

Post #7 of 14 (143 views)
Permalink

Re: autosay [In reply to]

On 27 February 2012 14:23, Tom Christiansen <tchrist [at] perl> wrote:
> Is there some reason why say() wasn't made a weak
> keywork the way lock is? �That way, if the user already
> had a function by that name, we would not override their
> version, but if they didn't, then they'd get Perl's.

Weak keywords introduce a lot of small maintenance issues.
Imagine you have a program that contains
use Foo ; say "I've used Foo";
and later, when you upgrade Foo, or run your program with another
version of Foo, it starts exporting a say() function. Your program
will silently and mysteriously break.

> In particular, this "error" message:
>
> � �$ perl -e 'say "hello there"'
> � �String found where operator expected at -e line 1, near "say "hello there""
> � � � � � �(Do you need to predeclare say?)
> � �syntax error at -e line 1, near "say "hello there""
> � �Execution of -e aborted due to compilation errors.
> � �Exit 255
>
> Seems really stupid. �Since it knows what to do, why doesn't
> it just do it?

Error messages can be improved. The bit "do you need to predeclare %s"
can usefully be replaced by a sentence about the feature you need to
enable keyword %s.

jvromans at squirrel

Feb 28, 2012, 4:48 AM

Post #8 of 14 (143 views)
Permalink

Re: autosay [In reply to]

Rafael Garcia-Suarez <rgs [at] consttype> writes:

> Imagine you have a program that contains
> use Foo ; say "I've used Foo";
> and later, when you upgrade Foo, or run your program with another
> version of Foo, it starts exporting a say() function. Your program
> will silently and mysteriously break.

Silently and mysteriously...

% perl -E 'use Foo; say "Hi there"'
Hi there
% perl -e 'use Foo; say "Hi there"'
>> Hi there <<

-- Johan

jvromans at squirrel

Feb 28, 2012, 4:57 AM

Post #9 of 14 (144 views)
Permalink

Re: autosay [In reply to]

Rafael Garcia-Suarez <rgs [at] consttype> writes:

> Weak keywords introduce a lot of small maintenance issues.

While this may be true, the current approach, the feature mechanism,
seems to turn into a bigger maintenance issue.

-- Johan

tchrist at perl

Feb 28, 2012, 7:11 AM

Post #10 of 14 (144 views)
Permalink

Re: autosay [In reply to]

> I've wondered for a little while now whether it wouldn't be useful to
> have some sort of document describing design decisions.

> Some design decisions are reached only after much debate. Years later,
> people who were not involved in those discussions may not understand why
> they were taken. We've seen a fair bit of this recently.

> The text could probably be copied from mail messages, or perhaps it
> could just be the final message from the pumpking. Or, perhaps better
> still, it could be the reference to the git commit where the design is
> explained.

> Perhaps we have already decided we don't want such a document.

> Why did we do that?

Well, if we did decide we didn't want to have a document explaining
why we deciced things, then that decision would be certain not to
have been recorded there, now wouldn't it? :)

--tom

tchrist at perl

Feb 28, 2012, 7:15 AM

Post #11 of 14 (145 views)
Permalink

Re: autosay [In reply to]

Rafael Garcia-Suarez <rgs [at] consttype> wrote
on Tue, 28 Feb 2012 10:25:31 +0100:

> Weak keywords introduce a lot of small maintenance issues.
> Imagine you have a program that contains
> use Foo ; say "I've used Foo";
> and later, when you upgrade Foo, or run your program with another
> version of Foo, it starts exporting a say() function. Your program
> will silently and mysteriously break.

Thanks. I didn't remember the reasons, is all.

> Error messages can be improved. The bit "do you need to predeclare %s"
> can usefully be replaced by a sentence about the feature you need to
> enable keyword %s.

I found the message suboptimal at best. I figure it should be
changed to read something about the feature. But then I wondered
what harm could be done by autoincluding it in that case. This
wouldn't trigger it:

say("foo");
sub say { ... }

But this would, because this is currently a syntax error:

say "foo" ;
sub say { ... }

Is there really no middle way to stear clear through here?

The problem seems to be that of of somebody saying

use Whatever;
say("foo");
sub say { ... }

When Whatever does not export say(), then the call gets
compiled to the current package, which later gets a definition.

But if later Whatever does indeed export say(), then the
function gets compiled to use the exported version, and then
later if warnings are running, there's a compile-time warning
about the function getting redefined.

Maybe it's too hard to do, or maybe too risky, but I still feel
like there is a logical do-what-I-mean opportunity that we're
missing out on here. Maybe that would fall into the category
of too much strange action at a distance. I dunno.

--tom

pagaltzis at gmx

Feb 29, 2012, 4:00 AM

Post #12 of 14 (144 views)
Permalink

Re: autosay [In reply to]

* Tom Christiansen <tchrist [at] perl> [2012-02-28 16:25]:
> Maybe it's too hard to do, or maybe too risky, but I still feel like
> there is a logical do-what-I-mean opportunity that we're missing out
> on here.

I agree. Error messages are a programming language usability issue,
and while Perl generally does very well on that count, there are a few
of them that could really stand to be more useful. This is one of those.

(By far the worst offender is “Global symbol "$foo" requires explicit
package name”, which is baffling if you don’t already know what it is
actually telling you to do. We should really think of something to do
about that one.)

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

eda at waniasset

Mar 1, 2012, 2:44 AM

Post #13 of 14 (143 views)
Permalink

Re: autosay [In reply to]

Tom Christiansen <tchrist <at> perl.com> writes:

> $ perl -e 'say "hello there"'

Nowadays I always use perl -E instead of perl -e (but old finger
habits die hard). Let's hope that when the next optional feature is
introduced we won't have to type perl -EE to enable it for oneliners.

Even today, the Camel book claims that "new verbs can be added to the
language without breaking old scripts", but this clearly wasn't felt
to be true for the addition of the new verb 'say'.

--
Ed Avis <eda [at] waniasset>

ilmari at ilmari

Mar 1, 2012, 4:22 AM

Post #14 of 14 (142 views)
Permalink

Re: autosay [In reply to]

Ed Avis <eda [at] waniasset> writes:

> Tom Christiansen <tchrist <at> perl.com> writes:
>
>> $ perl -e 'say "hello there"'
>
> Nowadays I always use perl -E instead of perl -e (but old finger
> habits die hard). Let's hope that when the next optional feature is
> introduced we won't have to type perl -EE to enable it for oneliners.

Quoth perlrun(1):

-E commandline
behaves just like -e, except that it implicitly enables all
optional features (in the main compilation unit). See feature.

So no need to worry about -Escalation.

--
ilmari "A disappointingly low fraction of the human race is, at any
given time, on fire." - Stig Sandbeck Mathisen

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads