How to understand chapter 6 of Higher Order Perl?

[Anonymous Monk]

The first 5 chapters weren't bad at all, but I'm seriously stuck at chapter 6. I can't understand what calls what and where. I tried to follow the examples with the debugger, but it's a bit worthless for that kind of thing. It doesn't help that the examples are really boring and kind of obfuscated. For instance:

sub promise(&) { $_[0] }

That's right, that thing does nothing. I find this really annoying. Does someone know where I can find better explanations of infinite streams or whatever they are called. Not nesessarily in Perl.

[BrowserUk]

It doesn't help that the examples are really boring and kind of obfuscated. For instance: sub promise(&) { $_[0] } That's right, that thing does nothing. I find this really annoying.

It doesn't "do nothing". It constructs a 'promise' from an anonymous block.

That is, it takes an anonymous block of code and returns a code reference to it, so that it can be executed at sometime in the future:

sub promise(&) { $_[0] };;
...
$later = promise{ say 'Keeping my' };;
...
$later->();; ## or just &$later;;
Keeping my

In other words, it constructs a callback.

To create an 'infinite' stream of values starting at 123 and incrementing by 2:

sub countFromBy{ my( $from, $step ) = @_; return promise{ $from += $st
+ep } };;
...
$counter = countFromBy( 123, 2 );;
...
say &$counter for 1 .. 10;;
125
127
129
131
133
135
137
139
141
143

Maybe that clarifies things a little for you?

[McA]

May I add somthing?

The book says that this is "syntactic sugar". So, BrowserUk's example is the same as:

$later = sub { say 'Keeping my' };
...
$later->();

McA

[Anonymous Monk]

Nah, I actually understand what it does (which is nothing useful). I just find it very annoying. That's not the real problem, of course. The problem is that I need some kind of tool or something to track all these function calls. So far I'm doing it manually, and that's kind of difficult when there is stuff like

my $hamming;
$hamming = node(1,
    promise {
        merge(scale($hamming, 2),
          merge(scale($hamming, 3),
            scale($hamming, 5),
      ))
   }
);

I find it kind of unreadable even without promise.

[BrowserUk]

Nah, I actually understand what it does (which is nothing useful). I just find it very annoying.

I don't disagree with you.

That's not the real problem, of course. The problem is that I need some kind of tool or something to track all these function calls. So far I'm doing it manually, and that's kind of difficult when there is stuff like ... I find it kind of unreadable even without promise.

Again, I don't disagree. I call it obfuscation through over-encapsulation.

The misguided attempt to gloss over moderately "difficult" perl syntax with myriad small, trivial named subroutines or methods. All it does is obscure the underlying algorithm; complicate maintenance and debugging; and throw performance to the dogs of dogma.

This is far simpler, clearer and way more efficient.

[Anonymous Monk]

time for a week long break?

[kcott]

I had a very brief look at that — I haven't read this previously.

It indicates that code is "syntactic sugar". It's a subroutine definition (see perlsub) with a prototype. It's not actually intended to do anything by itself anymore than any other subroutine definition is.

Following the point where it's introduced, it appears in a number of examples as function arguments. The first one is this:

node($m, promise { upto($m+1, $n) } );

Here's a very trivial example of usage which, with the information from the links I provided above, may help your understanding.

#!/usr/bin/env perl

use strict;
use warnings;

sub promise (&) { $_[0] }

make_good_on_promise(promise { print @_ }, "Hello.\n");

sub make_good_on_promise {
    my ($promise_to_do, $whatever) = @_;

    $promise_to_do->($whatever);
}

Sample run (as stated — a trivial example):

$ pm_example.pl
Hello.
$

[Anonymous Monk]

https://metacpan.org/pod/HOP::Stream#promise says

promise

  my $promise = promise { ... };

A utility function with a code prototype (sub promise(&);) allowing one to specify a coderef with curly braces and omit the sub keyword.

For debugging you might try https://metacpan.org/pod/HOP::Stream#show

[Anonymous Monk]

For comparison; sub allows you to specify a coderef with curly braces. And sub allows you to omit the "promise" word.

What's the point of "promise" other than to make you type more letters?

[Anonymous Monk]

So I was thinking about what BrowserUK said. "Misguided attempts to gloss over moderately 'difficult' Perl syntax..." It appears to me he's absolutely right. So I went ahead and rewrote some of the examples from the book.

sub upto_list {
    my    $from = shift;
    state $upto = shift;
    return undef if $from > $upto;
    return {
        head => $from,
        tail => sub {
            upto_list( $from + 1 );
            },
    };
}

sub show {
    my $node = shift;
    my $i    = shift // 10;
    while ($node->{head} && $i-- > 0) {
        say $node->{head};
        $node = $node->{tail}->();
    }
}

show( upto_list( 10, 15 ) );

I personally think that that is much easier to understand than the Lisp-like version from the book... It even works faster. What's the point in making Perl look like Lisp anyway? So! I'll answer my own question. 'Anonimous Monk, just rewrite the whole damn chapter in Perl'. Thanks everyone! Especially BrowserUK.

[BrowserUk]

Why did you use state there?

The problem is, it means that you cannot construct two concurrent iterators that work correctly.

With the line commented out in the following:

#my $_10_15 = upto_list( 10, 15 );
my $_5_30 = upto_list( 5, 30 );

show( $_5_30, 20 );

the show() line produces the expected 20 values:

C:\test>1078236.pl
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

But uncomment the 10/15 constructor and the show() now only produces 11 values despite requesting 20:

C:\test>1078236.pl
5
6
7
8
9
10
11
12
13
14
15

[sundialsvc4]

This style of programming has a definite (niche, in my opinion) place, in which place it turns out to be quite useful indeed.   I happen to find the quoted bit of syntax (in the OP) to be very obfuscatory, because it is not instantly obvious what the construct “(&)” means ... and, as it turns out, “it means everything.”   Your entire understanding of the example hinges, I think, upon knowing precisely what that ampersand does.   I do not prefer code that is not understandable at a glance by any/everyone who is reasonably familiar with the language.   If I have to stop and think about it ... if I am the slightest bit uncertain ... then I know that my successors will feel the same way (maybe), and that bugs might be the result.   Bugs of the type that are introduced by mis-reading of the source code are very expen$ive.   So, I look for another way to say it, even if the algorithm remains unchanged.

That being said, this is of course meant to be an example, meant to be condensed into just one line and probably being the minimal way to present it.   The book’s author in this case was dealing to the book’s purposes of example, whereas a real-world application of the idea would be different.   In a future edition of the (e-)book, perhaps a few more sentences could be added.

[Anonymous Monk]

In a future edition of the (e-)book, perhaps a few more sentences could be added.

it already does ... it , page 123, pdf page 141

[Anonymous Monk]

So I'm reading the book again: it's all a bit clearer now. Chapter 6 is simply full of spaghetti code. Nothing more and nothing else.