[% setvar title Built-in functions should be functions %]

This file is part of the Perl 6 Archive

Note: these documents may be out of date. Do not use as reference!

To see what is currently happening visit http://www.perl6.org/

TITLE

Built-in functions should be functions

VERSION

  Maintainer: Johan Vromans <jvromans@squirrel.nl>
  Date: 27 Aug 2000
  Last Modified: 20 Sep 2000
  Mailing List: perl6-language@perl.org
  Number: 168
  Version: 3
  Status: Frozen

NOTE

See CHANGES for warp-up info.

ABSTRACT

RFC 26 proposes to eliminate the distinction between functions and operators from a language perspective.

This RFC proposes that all Perl built-in functions should be usable in all ways normal functions can be used. It is part of a big consipracy to remove the number of cases with exceptional behaviour in Perl.

DESCRIPTION

Named operators, like abs, can be called like functions in which case they behave like functions. However, that's where the similarity ends. You cannot override most builtins, and cannot tack a reference to them.

There is no reason why the built-ins should be treated differently. A famous Perl saying reads "if it looks like a function, it is a function." So be it.

In particular, it is desired that every built-in

Overriding

The principle of least surprise dictates that

    sub I<foo> { return 10 }
    print I<foo>();

should call foo() and print "10" for all foo.

Currently, most built-ins are excluded from this. For example:

    sub system { return 10 }
    print system();

Instead of calling the user defined system(), the built-in is used.

The second line may give a warning, but only if warnings are enabled:

    Ambiguous call resolved as CORE::system(), qualify as such or use &

References

You can call a built-in, but not take a reference.

    $a = \&system;
    print $a->(-1)

This gives an error:

    Undefined subroutine &main::system called

This should return a reference to the built-in instead.

Since &foo implicitly refers to the current package, it would be acceptible to require

    $a = \&CORE::system;

Note that this currently (5.7.0 DEVEL6806) results in the error:

    Undefined subroutine &CORE::system called

which is surprising, if not misleading.

Prototypes

Currently, several built-ins do not provide prototype information.

    prototype("CORE::abs")  ==>  ;$
    prototype("CORE::shift")  ==>  undef

This must be fixed. One might even call this a bug, although the current prototype mechanism is not powerful enough to cope with all built-ins.

CHANGES

Version 3

Added CHANGES.

Version 3, 20 September

Frozen after some discussions on the mailing list. People seem to like the idea, but worry about the prototypes. Other RFC will deal with that.

Version 2, 28 Aug 2000

Add Status indicator.

REFERENCES

RFC 26: Named operators versus functions

Tom Christiansen in <12231.967154045@chthon> (perl6-internals, Aug 24, 2000).