Note however that some built-ins can't have their syntax expressed by a prototype (such as system or chomp). If you override them you won't be able to fully mimic their original syntax.

IMHO the first sentence doesn't apply here because eof's syntax can be expressed by a prototype - this is also the reason why I personally am not bothered by the fact it does have a protoype. The second sentence only applies because AFAIK there isn't a built-in way for functions to know whether they were called with parens or not, but this has nothing to do with the prototype.

> IMHO the first sentence doesn't apply here because eof's syntax can be expressed by a prototype

Depends how you define "syntax can be expressed by a prototype".

A "can be parsed without errors" criteria is not enough for me.

eof(); and eof; are (magically) different syntax for eof, and this difference can't be expressed with prototypes.

In the past the prototype symbol set was extended with *, + or _ in order to add prototypes to other built-ins.

This criteria isn't met here.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

eof(); and eof; are (magically) different syntax for eof, and this difference can't be expressed with prototypes.

I'm not sure this is a job for prototypes. Every Perl function can be called with and without parens (given the compiler knows about it), it's always valid syntax. The trick would be to detect inside a hypothetical sub myeof whether the parens are there are not - how would one do this with prototypes? Seems more like a job for something like caller. It's also worth noting that AFAIK eof is the only function in Perl that behaves this way... the exception that confirms the rule ;-)

Interesting side note: see eof in perltie.

A "can be parsed without errors" criteria is not enough for me.

I don't think that's the criteria. It's more like: "Every variation of the builtin's syntax can be expressed by prototypes" - look at threads like Prototype like sort()? where everyone's implementations got close to the original, but noone was able to replicate all of sort's syntax. All of eof's syntax can be replicated, but not its functionality. That's where the difference is.

I do understand how you are interpreting that piece of documentation, but I think you should cut the authors some slack :-) eof is a unique case, and knowing this, I don't think that passage is inaccurate.

Two reasons I can think of:

• So it can be overridden. As I remember it, prototypes were added to ops as part of making them overridable.
• It was done by accident (i.e. without knowledge the prototype was inadequate).

the prototype was inadequate

how so?

That certain operators (eof, open, etc.) have prototypes that aren't adequate for representing the syntax of the operator is the premise of the question.

For example,

• An overridden eof operator can't distinguish whether it was was called as eof or eof() while the real operator does.

• open( STDERR , ">&=", STDOUT ) is perfectly valid with the real operator, but throws a strict error with an overridden open.

  $ perl <<'.'
  use strict;
  open( STDERR , ">&=", STDOUT );
  BEGIN { *CORE::GLOBAL::open = sub (*;$@) { } }
  open( STDERR , ">&=", STDOUT );
  .
  Bareword "STDOUT" not allowed while "strict subs" in use at - line 4.
  Execution of - aborted due to compilation errors.
  [download]

---

Upd: Fixed accidental double negation.