develooper Front page | perl.perl6.language | Postings from March 2005

Re: string/list division

Thread Previous
Luke Palmer
March 29, 2005 06:11
Re: string/list division
Message ID:
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.


> 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

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).


Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About