Re: string/list division

Aaron Sherman writes:
> On Mon, 2005-03-28 at 13:38, Luke Palmer wrote:
> 
> > Your "list mod" idea is interesting, though.  I fear that adding too
> > many list operators will start to make us look like Haskell, where we
> > have *extremely* expressive single lines that take an hour to write and
> > an hour to read (I call this "concise hell").
> 
> Ah, to have access to the Concise Hell compiler... ;-)
> 
> Seriously, if you have a line of code which takes an hour to write and
> an hour to read, is that any better or worse than the equivalent 10
> pages of code that take an hour to write and an hour to read?

Depends on your reading style, but I think it is.

> 
> That said, one of Perl's largest PR problems has always been the power
> of the syntax and grammar of the language. When people look at a program
> and see:
> 
> 	my %uid_map = map {/^(\w+):[^:]*:(\d+)/} <>;

That line takes about the average amout of time for me to read, but for
a less experienced programmer, this is exactly what I'm talking about.
And indeed, if you did it in C, it would be a lot longer and more
verbose, even though each line would be easier to read than this one.

To illustrate my point, for the novice, this would be a nicer way to
write that:

    my %uid_map;
    while (<>) {
        my ($key, $value) = /^(\w):[^:]:(\d+)/;
        $uid_map{$key} = $value;
    }

Five lines instead of one, not ten pages instead of one.  And after
having illustrated my point, I see why it's a Good Thing.  It forces you
to name things.  If the novice does not understand some syntax, he will
be guided by how you name your intermediate variables.

[snip]

> The question is: should you be apologetic and/or fail to follow this
> semantic compression down to its logical conclusion because some people
> will find it off-putting.
> 
> I think that in the specific case of Perl 6, the answer is a resounding
> NO for two reasons:
> 
>      1. Perl 6 can (dangerous lack of the future subjunctive here)
>         introspect to a degree that almost no other language can (some
>         functional languages are exceptions here), so writing a "strict"
>         module that forces programmers to avoid these semantically rich
>         constructs (or limit their use to "reasonable situations") is at
>         your fingertips. You could even make it invalid at a parser
>         level to chain more than some given number of operations.
>      2. Parrot provides access to Perl 6 code from other languages, so
>         if Damian writes some wiz-bang module that everyone in the world
>         wants access to, even the people who don't like Perl 6 can do so
>         without having to get used to Perl 6. If APL had had Parrot, we
>         might all be running APL code to this day.
> 
> Because of this, Perl 6 need not apologize for it's APL/Haskell-like
> penchant for semantic compression. It can evolve along the lines that
> Perl 4 and 5 made available to it, and not leave anyone behind.

These are definitely good points.  You have to understand that I am
somewhat conflicted about my role in this thread.  I am not opposed to
semantic/syntactic sophistication (like `%hash{dims @a}{@b} = @c` from
earlier today or your example), but I am opposed to semantic/syntactic
complexity.   But you can't have one without the other.  For example:

    # sophisticated (from Perl6::Placeholders)
    my $code = $2;
    my $vars = join ",", sort $code =~ m/(\$\^\w+)/g;
    my $decl = qq{my($vars)=\@_;};

    # complex (from my ass)
    my $decl = 'my(' . join(',', sort $2 =~ m/(\$\^\w+)/g) . ')=@_;';

It's the same code.  And it's exactly what I illustrated eariler.  It's
just that the latter is doing a bunch of unrelated stuff in one line,
and the other is keeping the "semantic units" together... and naming
them.

So I believe that my opposition to operators like `[/]` is that they
lend themselves to both these kinds of code, but the fear comes from the
latter.  I don't think I would mind so much if the same operator were
called `chunks` (or even something sane ;-) instead of `[/]`.  Because
then you could look it up (maybe we just need a big list of operators
with mnemonics and descriptions like we have for special variables in
Perl 5).

Luke

• string/list division by Juerd
• Re: string/list division by Luke Palmer
• Re: string/list division by Aaron Sherman
• Re: string/list division by Luke Palmer