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

I'm not on -io, so copy me on discussion.  But this RFC was intriguing, so I
read the discussion on the archive for it, and have the following comments.

Perl6 RFC Librarian wrote:

>    format FILE =
> @<<<<<<<<<<<<<:  @<<<<<<<<
> $name, $ssn
> .

> =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
> );

So who needs a special format type?  Just need a string.  It becomes a
format when you use it as such...  So just

  my $frm = <<'.'
@<<<<<<<<<<<<<:  @<<<<<<<<
$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]

Only the parser's special case needs the special type variable; not a good
one, in my opinion.  We don't need more special cases in the parser.

There was some discussion of special compiling for use.  That sounds similar
to compiling a regex.  I'm no Perl internals guy, so I don't have a clue how
either of these should be or are currently done.  If I were to invent
something new to do it, I'd say it is still scalar, so could still be a
simple variable, but, like scalar's already have numeric vs string forms,
I'd invent a couple new variations: string with regex augmentation, and
string with format augmentation.  These would act like a string everywhere
except when used as a regex or format.  When used that way, if the
augmentation exists, use it instead of recompiling.  When assigning to a
scalar, if an augmentation exists, delete the augmentation, reverting back
to a normal string (or even a number).  For non-core access, one might need
get/set functions for the augmentation value/type.  If this makes no sense,
just delete the whole paragraph.

> 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

So how about:

  open $FILE, ">>$file";
  format $FILE (<<'.');
@<<<<<<<<<<<<<:  @<<<<<<<<
$name, $ssn
.

Now that's pretty amazingly close to the existing syntax, as long as the
order can be arranged.  The old syntax allowed the format for a file to be
declared independently of the sequence of opening the file.  On the other
hand, perhaps the following sequence would also be possible, if one is
careful that open doesn't discard existing formats... and there is no
particular reason it should.  And it need only "construct" $FILE if it isn't
already a File...

  my File $FILE;
  format $FILE (<<'.');
@<<<<<<<<<<<<<:  @<<<<<<<<
$name, $ssn
.
  open $FILE,">>$file";

> However, I don't particularly like extra steps, personally.

I don't see any extra steps, or even any extra variables, in the above.

Of the ideas previously mentioned in the thread of responses to this RFC, I
like the idea of

   write $FILE, $format;

but not

   write $FILE, $format [, actual values];

The format contains the variable specifications, and those are probably
compiled somehow into the definition, and should be left alone.  After all,
with the first form you could also use:

  write $FILE, <<'.';
@<<<<<<<<<<<<<:  @<<<<<<<<
$name, $ssn
.

I look forward to version 2.

--
Glenn
=====
There  are two kinds of people, those
who finish  what they start,  and  so
on...                 -- Robert Byrne



____________NetZero Free Internet Access and Email_________
Download Now     http://www.netzero.net/download/index.html
Request a CDROM  1-800-333-3633
___________________________________________________________