Re: PERLISP meditations

[LanX]

in reply to PERLISP meditations

Thats what you want?

my $sq = sub { $_[0]**2 };
my $id = sub { $_[0] };
 
sub sum {
  my ($a,$b,$func) =@_;
  $func //= $id;
  my $sum;
  $sum += $func->($_)  for ($a..$b);
  return $sum;
}
 
sub sum_sq{ sum($_[0],$_[1],$sq)}
 
$,=",";
print sum(3,5),sum_sq(3,5);        # 12,50

I skipped the &next sub for integer stepping, but shouldn't be to difficult with a while loop checking $a<$b.

(UPDATE: I'm puzzled... if "&next" is necessary to get the next element of an iterator one must also provide a &cmp for checking $a<$b in the loop-condition)

Better avoid Lisp-recursion in Perl, when you can use "real" loops, we don't automatically optimize them to loops like Lisp does.

[protist]

The idea was to use the same logic, that is, recursive logic. Also the iterator is supplied to the sum subroutine in my example (as it is given in the LISP version). By using codereferences instead of normal subroutines, you simplified the passing of arguments. This has the effect, however, of making $sq and $id no longer callable in the same fashion as sum_sq is.

I like your use of //=, but I think the brevity of your code is due to simplification of, and less-strict adherence to, the LISP example.

[LanX]

Yes but LISP has no builtin loops thats why you need recursions there which are optimized at compile-time. Perl can't do this (see Tail call) even gotos are no big help here.

You didn't provide much explanation thats why I replied with my interpretation.

Regarding iterators and next please see my update in my first post, a flexible next() is of little use if there isn't also a cmp() for abitrary iterators/data structures.

[protist]

The lisp example was recursive, so I made mine recursive. This is nebulous, abstract, and subjective. I realize this. I was attempting to model the Perl program after the logic of the LISP program as written, not after its compiled representation. I was attempting to "think in LISP" while programming in Perl.

Regardless of its utility, I provided a flexible next() because the LISP example did. I would add, however, that the flexible next is still compatible with the normal comparison as written for many types of iterations, in so long as the iterations cause A to increase, and have either no upper bound or an upper bound above B.