Re: Exegesis 7: Why so many field specifiers?

[Damian Conway]

Rick Delaney wrote:

> Why not something like
>
> Single-line         Block
> ===========         =====
> [<<<]               {<<<}
> [>>>]               {>>>}
> [|||]               {|||}
> [''']               {'''}
>
> which distinguishes the 2 main field types and gives us only the 4
> justifiers we need?
>
> I can appreciate the elegance and power of bracketing the fields even
> though it screws up one- and two-character fields.  And while it's nice
> to be down from 3 metacharacters in Perl 5 formats to 1 it doesn't feel
> quite worth it when every justification specifier must be doubled.
>
> Having two sets of field delimiters means that if a new justifier is
> added we need only come up with one character for it.  It also clearly
> distinguishes the field type for two-character fields.  Neither of these
> is a strong argument for changing the existing design but I'm wondering
> why the first table above would be easier to learn/remember than the
> second.
I did think long and hard about this issue, and considered the very points
you make -- at some length. In the end I decided that either (...) or
[...] were simply too common in literal text for it to be reasonable to
use them as delimiters for block fields.
I *suppose* an argument might be made that the "multiplicity" connotations
of �...� might make them a suitable alternative, but can you imagine the
screams of protest from the seven-bit lobby?
Moreover, as I looked at various examples, it became obvious to me that
differentiating the behaviour of fields only by their delimiters made it
much harder to quickly visualize what a particular format would do. And
hence harder to maintain that formatting code.
For example, if we compare:

    print form
        "{<<<<<<<<<<<} [<<<<<<<<<<<<<<<<<<<<<] {<<<<<<<<<<<<}",
         $title,       $info,                  $reference,
        "{<<<<<<<<<<<} {<<<<<<<<<<<<<<<<<<<<<} [<<<<<<<<<<<<]",
         $subtitle,    $source,                $cross_refs;
with:

    print form
        "{<<<<<<<<<<<} {[[[[[[[[[[[[[[[[[[[[[} {<<<<<<<<<<<<}",
         $title,       $info,                  $reference,
        "{<<<<<<<<<<<} {<<<<<<<<<<<<<<<<<<<<<} {[[[[[[[[[[[[}",
         $subtitle,    $source,                $cross_refs;
for me, at least, it's a great deal easier to distinguish the block fields
and single-line fields in the second version, and therefore to predict
at a glance what the final text will look like.
In the end it was a decision that might have gone either way, but one that
I made consciously and for what I consider to be good reasons.
And, of course, the beauty of C<form> is that, like so much of the rest of 
Perl 6, if you don't like the syntax I chose, you can always create a module 
to replace it with the syntax you'd prefer:

    module Form::Less::Travailed {
        my sub translate (Str $_ is copy, [EMAIL PROTECTED]) {
            s/^\[/{/;
            s/\]$/}/;
            tr/<>|'/[]I"/;
            return $_;
        }
        use Form :field{ /\[    .*?    \]/ => &translate,
                         /\{ <[][I"]>+ \}/ => { die "Ugly field: $^yuck" },
                       };
        sub form is exported {...}
    }
Or, in Perl 5:

    package Perl6::Form::Less::Travailed;

    sub translate {
        for (shift) {
            s/^\[/{/;
            s/\]$/}/;
            tr/<>|'/[]I"/;
            return $_;
        }
    }
    use Perl6::Form {
        field => { qr/\[   .*?   \]/x => \&translate,
                   qr/\{ [][I"]+ \}/x => sub { die "Ugly field: $_[0]" }
                 },
    };
    use Perl6::Export;

    sub form is exported;

    1;



Damian