From @masak

Rakudo r34400​:

$ perl6 -e 'print'
$ perl6 -e 'say'

$

S16​:340, about 'print'​:

] It is a compiler error to use a bare C<print> without arguments.
] (However, it's fine if you have an explicit argument list that evaluates to
] the empty list at runtime.)

...and, S16​:360, about 'say'​:

] As with C<print>, it is a compiler error to use a bare C<say> without
] arguments.

From dave.whipp@gmail.com

S16 requires that "say" (and "print") when called with no args should
be a compile-time error. Rakudo accepts it with no error.

From @pmichaud

On Tue, Jan 06, 2009 at 01​:50​:06PM -0800, Dave Whipp wrote​:

S16 requires that "say" (and "print") when called with no args should
be a compile-time error. Rakudo accepts it with no error.

Since S16 has been in an incomplete "draft" status for such a long
time, I'd like to get confirmation from p6l about this part of
the spec before committing it to an implementation.

Thanks,

Pm

The RT System itself - Status changed from 'new' to 'open'

From @TimToady

On Tue, Jan 06, 2009 at 08​:39​:00PM -0600, Patrick R. Michaud wrote​:
: On Tue, Jan 06, 2009 at 01​:50​:06PM -0800, Dave Whipp wrote​:
: >
: > S16 requires that "say" (and "print") when called with no args should
: > be a compile-time error. Rakudo accepts it with no error.
:
: Since S16 has been in an incomplete "draft" status for such a long
: time, I'd like to get confirmation from p6l about this part of
: the spec before committing it to an implementation.

Hmm, well, the case for complaining on "print" is pretty clear cut,
since print with no args is a no-op, and hence can only mean they
were intending to default to $_.

With "say" it's not such a clear case, since they might have been
intending to mean "print nothing but emit the newline". On the
other hand, they might have meant to say $_, in which case they'd
thank us for the error. And it's pretty easy to use any of

  say '';
  say ();
  ''.say;
  print "\n";

to be clearer about the intent. So my inclination is to outlaw
bare "say" as well, as an aid to catching a common p5thinko that
some folks might otherwise find difficult to debug.

I suppose a case could be made for just making one or both of those
warnings. STD already has a mechanism for reporting "Possible
difficulties", so maybe that's a good-enough way to handle it.

Larry

The RT System itself - Status changed from 'new' to 'open'

From @pmichaud

On Wed, Jan 07, 2009 at 05​:53​:40PM -0800, Larry Wall wrote​:

And it's pretty easy to use any of

say '';
say \(\);
''\.say;
print "\\n";

to be clearer about the intent. So my inclination is to outlaw
bare "say" as well, as an aid to catching a common p5thinko that
some folks might otherwise find difficult to debug.

I'm fine with this.

How about C< say() > as a function call instead of a listop?
Still illegal?

If they're "compiler errors", do you expect that we'll catch them
as part of the grammar (i.e., in STD.pm), or a later compiler phase?

I suppose a case could be made for just making one or both of those
warnings. STD already has a mechanism for reporting "Possible
difficulties", so maybe that's a good-enough way to handle it.

That also works for me -- I'd just like a pointer as to where
we're likely to stick the test for this.

Thanks!

Pm

From @pmichaud

On Wed Jan 07 17​:54​:26 2009, larry wrote​:

[...] So my inclination is to outlaw
bare "say" as well, as an aid to catching a common p5thinko that
some folks might otherwise find difficult to debug.

Bare "say" and "print" are now illegal in Rakudo as of r35431. This
currently catches only the truly bare say/print -- the parenthesized
forms are still allowed​:

  say; # error
  say (); # ok
  say(); # spec is unclear, rakudo currently allows this

If the C<say()> and C<print()> forms should be disallowed, we can do
that as well.

Pm

From @pmichaud

On Sun, Jan 11, 2009 at 07​:18​:53PM -0800, Patrick R. Michaud via RT wrote​:

On Wed Jan 07 17​:54​:26 2009, larry wrote​:
Bare "say" and "print" are now illegal in Rakudo as of r35431. This
currently catches only the truly bare say/print -- the parenthesized
forms are still allowed​:

say;      \# error
say \(\);   \# ok
say\(\);    \# spec is unclear, rakudo currently allows this

If the C<say()> and C<print()> forms should be disallowed, we can do
that as well.

Actually, that fix didn't turn out to be complete, so I've entered
a new fix, and the C<say()> and C<print()> forms are now disallowed
also. Thus we're left with​:

  say; # error
  say(); # error
  say (); # ok

Since this matches the spec, I'll close this ticket (as soon as I can
get back into rt.perl.org to do so -- it's not responding for me
right now).

Pm

From @pmichaud

Assigning to moritz to make sure we have a spectest.

Pm

From @moritz

On Sun Jan 11 21​:21​:39 2009, pmichaud wrote​:

Assigning to moritz to make sure we have a spectest.

Added some to t/spec/S16-io/bare-say.t (and added it to t/spectest.data)

Moritz

@moritz - Status changed from 'open' to 'resolved'