=head1 TITLE

Formats out of core / New format syntax

=head1 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

=head1 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.

=head1 NOTES ON RETRACTION

B<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. ;-)

=head1 DESCRIPTION

=head2 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).

=head2 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.

=head2 New Syntax

Under the new syntax, a format will be held in a variable of the
C<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
C<select> statements. The C<format> and C<write> methods could simply be
member functions of the C<$FILE> object.

However, I don't particularly like extra steps, personally. One way
around this would be to assume the default format is C<[handle]_FORMAT>,
meaning C<$FILE>'s default format would be C<$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 L<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.

=head1 IMPLEMENTATION

Hold on.

=head1 MIGRATION

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

=head1 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 C<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 C<my> and
it's Perl 5.

=head1 REFERENCES

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