On 31 Aug 2000 06:28:10 -0000, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
Being one of world's active format users, I have to comment.
> Formats out of core / New format syntax
> Currently, the general consensus is that formats aren't widely used
> enough to justify their living in the core binary. [1] However, they are
They *are* incredibly useful. About 60% of our production scripts use formats.
They serve a good purpose when dealing with fixed width font reports,
something we have to do by law (we produce and fill in (preprinted) birth-,
marriage-, divorce-, decease-certificates and such that are to be printed in
fixed pitch fonts by law).
> 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;
Have you also looked at Damian's Text::Autoformat, which has a renewed format
implementation that looks *very* good a candidate for replacing perl 4/5's
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:
You can name a format anything you like, which I do all the time. The only
*default* format is the one with the same same as the currently selected
filehandle.
> 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
Something I realized already. One more reason to look at Damian's
implementation.
> 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
> );
I like it's lexical scoping here!
> 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
I don't care for a default format for a file handle. I'd like to see write
changed, so it accepts the format name as a first argument, so I do not have
to twiddle with $~ all the time.
> 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.
write's are called in a sequence where the currently selected filehandle will
probably not mean so much overhead in programming, esp. where every other io
function accepts a file handle.
write [format_name [,] [filehandle]];
would be best. No, uh, if Johan's qf() would be implemented, write could
detect itself and it could even be:
write [format_name] [filehandle];
I don't know if I want a comma there, I think yes, but ...
> 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.
No objections.
> 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.
If there is a need for migration anyway, look at Damian's implementation again
and add new functionality at the same time, like footers.
> =head1 NOTES
>
> [1] I personally disagree, but this RFC is close enough to make me
> happy. :-)
Disagree to what? The part before the [1]: justification of removal out of
core, of the part after: it's usefulness?
> [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:
No pleaso don't make it more complicated than needed.
> 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.
And get rid of the '$' too. If it's feasable in your mind to do it in the
perl6 parser, it would also be possible to move that to the perl5-perl6
converter.
> =head1 REFERENCES
>
> RFC 174 (v1): Parse C<func($obj, @args)> as C<func $obj (@args)>
Damian Conway's Text::AutoFormat
--
H.Merijn Brand Amsterdam Perl Mongers (http://www.amsterdam.pm.org/)
using perl5.005.03, 5.6.0 & 516 on HP-UX 10.20, HP-UX 11.00, AIX 4.2, AIX 4.3,
DEC OSF/1 4.0 and WinNT 4.0 SP-6a, often with Tk800.022 and/or DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
