Re^8: Next Language to Learn (Lazy Perl)

Is this supposed to be Haskell code or Haskell semantics?

For me it looks more like LISP phrased in Perl..

Did you mean:

sub all_even_from{
  my $even=shift;
  sub {
    $even+=2;
  }
}
 
$iter=all_even_from(4);
 
print $iter->() for (1..5);
[download]

> so maybe your general idea of using an operator would lead in the right direction...

I didn't talk about operators but about tie.

Using Tie::Array you could try to tie the iterator to an array @even such that you can subsequently write something like this, _with_ lazy evaluation.

 
 for (1 ..5) {
   print shift @even;
 }
[download]

again, show me what you like about Haskell - eg list comprehensions (???) - and I will see whats feasible.

Cheers Rolf

Comment on Re^8: Next Language to Learn (Lazy Perl) Select or Download Code

Replies are listed 'Best First'.
Re^9: Next Language to Learn (Lazy Perl) by rovf (Priest) on Apr 01, 2010 at 11:07 UTC
Is this supposed to be Haskell code or Haskell semantics? Perl-Code to show the general idea of how to apply lazy evaluation, not restricted to Haskell (which is just one of the languages having lazy evaluation builtin). Using Tie::Array you could try to tie the iterator to an array @even such that you can subsequently write something like this, _with_ lazy evaluation. Good point! show me what you like about Haskell - eg list comprehensions (???) - and I will see whats feasible. I'm not an advocate for a particular language (Haskell was just given as an example, because several implementations are available), but I like the idea in FP that you don't have side effects. This is nice for the programmer, but can be hairy for the implementation. List comprehension helps if you transform arrays, but I think array update is more tricky. Where you write in an imperative language something like `$a->[$n]+=$k` to update the array element at postition $n, you would in FP (conceptionally) return a copy of the array, which differs from the original one only in the element with index $n. Of course you don't want to actually copy the whole array, unless it is really necessary. For instance, if you have an array $a and a function &fa expecting an array (I stay with Perl syntax here), and you want to invoke the function with $a, but set the first element of $a to zero, the non-functional solution would be simply `$a->[0]=0; fa($a);` [download] while a functional solution would need something like `fa(update($a,0,0))` [download] and need to be clever enough to not make a copy of the array until this is becomes necessary. But a guess with a clever usage of tied variables and Perl objects, you might indeed be able to come up with a FP framework for Perl... -- Ronald Fischer <ynnor@mm.st>	[reply] [d/l] [select]
Re^10: Next Language to Learn (Lazy Perl) by LanX (Saint) on Apr 01, 2010 at 17:58 UTC
The lack of side effects is for you of interest for parallel computing or just for theoretical studies? > Where you write in an imperative language something like `$a->[$n]+=$k` to update the array element at postition $n, you would in FP (conceptionally) return a copy of the array, which differs from the original one only in the element with index $n. First of all I have to say that LISP doesn't normally use arrays, the normal approach are linked lists, replacing an element is simply done by manipulating the chain, so no big copies needed. If you want linked lists and FP mechanisms I strongly recommend reading "Higher Order Perl"! Then, the default for passing arrays in perl is by copy, so calling `f(@$ar)` will not effect the original array. And if you wanna pass arrayrefs you still can write `f( [@$ar] )` if you - for whatever reason- don't wanna do the copy within the function. The functionality of splice may be of further interest for you. Cheers Rolf	[reply] [d/l] [select]
Re^11: Next Language to Learn (Lazy Perl) by rovf (Priest) on Apr 06, 2010 at 07:09 UTC
The lack of side effects is for you of interest for parallel computing or just for theoretical studies? Much more egoistic: It's for ease of debugging ;-) It is easier to analyze a program, and consequently to debug it, if you don't have to care about state. First of all I have to say that LISP doesn't normally use arrays, the normal approach are linked lists, replacing an element is simply done by manipulating the chain, so no big copies needed. It depends what you want to do. All LISPs I came accross so far provide arrays (for instance, using make-array in Common LISP), and whether I use an array or a linked list or a property list or what else, depends on what I want to do with it. This is not different from Perl (or Ruby, or nearly anything else). Then, the default for passing arrays in perl is by copy, so calling f(@$ar) will not effect the original array. Actually, Perl passes by reference, i.e. f can modify the original array; only that most people write their functions in a way that they just affect a copy - but the copying happens at the called side, not at the caller side. If you want linked lists and FP mechanisms I strongly recommend reading "Higher Order Perl"! Interesting reading indeed. Also has a small chapter about delayed evaluation. The functionality of splice may be of further interest for you. Not really. Although it does aggreagate update, it (naturally, since it uses eager evaluation) has to make a copy of the whole array.... -- Ronald Fischer <ynnor@mm.st>	[reply] [d/l]