Re: RFC 181 (v1) Formats out of core / New format syntax

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/