[% setvar title Formats out of core / New format syntax %]

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

Formats out of core / New format syntax

VERSION

  Maintainer: Nathan Wiger <nate@wiger.org>
  Date: 30 Aug 2000
  Last Modified: 16 Sep 2000
  Mailing List: perl6-language@perl.org
  Number: 181
  Version: 2
  Status: Retracted

ABSTRACT

There has been much hinting at moving formats out of core. This RFC proposes one way to do this, at the same time standardizing the syntax.

NOTES ON RETRACTION

RFC 230: Replace format built-in with pragmatically-induced format function is a much more complete and comprehensive proposal which I personally like better too. ;-)

DESCRIPTION

Overview

Currently, the general consensus is that formats aren't widely used enough to justify their living in the core binary. [1] However, they are incredibly useful, and need to remain in the core distribution no matter what.

Under this RFC, formats will be available through a simple:

   use Format;

The rest of the RFC will address specific changes in syntax to make this possible (and more consistent too).

Current Syntax

Currently, formats must be named for the bareword filehandle that they're going to be used on, for example:

   format FILE =
@<<<<<<<<<<<<<:  @<<<<<<<<
$name, $ssn
.
   open FILE, ">>$file";
   write FILE;

Some behind the scenes magic is done to bind these two together. In order to change the format name, you have to use the following statements:

   $old = select FILE;
   $~ = MYCUSTOMFORMAT;
   select $old;

Getting this syntax to work as a module would be a collosal headache. In addition, it's pretty peculiar to begin with. As such, a new but very similar syntax is proposed.

New Syntax

Under the new syntax, a format will be held in a variable of the format type:

   my format $FILE_FORMAT = q(
@<<<<<<<<<<<<<:  @<<<<<<<<
$name, $ssn
);

Note that declaring the format is remarkably similar to the current form. However, it now can be handled with the existing variable syntax, simplifying implementation. [2]

Using formats, however, requires one extra step, since there is no longer any intrinsic property tying formats and filehandles together:

   open $FILE, ">>$file";
   format $FILE ($FILE_FORMAT);   # $FILE->format($FILE_FORMAT)
   write $FILE;                   # $FILE->write

Note, however, that this does get rid of the need to do all the special select statements. The format and write methods could simply be member functions of the $FILE object.

However, I don't particularly like extra steps, personally. One way around this would be to assume the default format is [handle]_FORMAT, meaning $FILE's default format would be $FILE_FORMAT. This would make behavior very similar to current, and would make the above extra step unnecessary. More clever ways of doing this probably exist as well.

Finally, note that if "RFC 174" is adopted, this can be made to look even more simple and consistent:

   open $FILE, ">>$file";
   format $FILE, $FILE_FORMAT;    # $FILE->format($FILE_FORMAT)
   write $FILE;                   # $FILE->write

Since the indirect object and function syntaxes could be used interchangeably.

IMPLEMENTATION

Hold on.

MIGRATION

There is a need for migration, but I'd rather save this until later since this idea may get massively revised.

NOTES

[1] I personally disagree, but this RFC is close enough to make me happy. :-)

[2] We might consider making a special case in the Perl parser so that if a variable is declared of type format then the Perl 5 syntax can be used:

   my format $FILE_FORMAT =
@<<<<<<<<<<<<<:  @<<<<<<<<
$name, $ssn
.

Then this is even less different and scary. Get rid of that my and it's Perl 5.

REFERENCES

RFC 174 (v1): Parse func($obj, @args) as func $obj (@args)