[% setvar title Formats out of core / New format syntax %]
|Note: these documents may be out of date. Do not use as reference!|
To see what is currently happening visit http://www.perl6.org/
Formats out of core / New format syntax
Maintainer: Nathan Wiger <firstname.lastname@example.org> Date: 30 Aug 2000 Last Modified: 16 Sep 2000 Mailing List: email@example.com Number: 181 Version: 2 Status: Retracted
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.
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. ;-)
Currently, the general consensus is that formats aren't widely used enough to justify their living in the core binary.  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:
The rest of the RFC will address specific changes in syntax to make this possible (and more consistent too).
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.
Under the new syntax, a format will be held in a variable of the
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. 
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
write methods could simply be
member functions of the
However, I don't particularly like extra steps, personally. One way
around this would be to assume the default format is
$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.
There is a need for migration, but I'd rather save this until later since this idea may get massively revised.
 I personally disagree, but this RFC is close enough to make me happy. :-)
 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
my format $FILE_FORMAT = @<<<<<<<<<<<<<: @<<<<<<<< $name, $ssn .
Then this is even less different and scary. Get rid of that
it's Perl 5.
RFC 174 (v1): Parse
func($obj, @args) as
func $obj (@args)