in reply to Re^4: reduce like iterators
in thread reduce like iterators

How is memorizing a new special var any different than memorizing a new BLOCK LIST function name? Either way, you are having to memorize something new. Also depending on how you define your block list function, you are effectively making $a, $b, or $_ into a special purpose variable of your own choosing.

Also I'm not sure I understand how you separate the notion of special variable from block function/syntax. Special variables generally are part of a process and the process drives the variables. Regexs are complicated processes with lots of mid-process data so they have lots of special variables. Sort is fairly simple, so it has just two $a and $b. But in each case, accompanying the special variable is a function or special syntax. $1 is associated with the syntax of a regular expression. $_ is associated with sort, grep, map, and for not because the variable has special meaning in and of itself, but because each of these function need only a current list member and $_ is symbol used when we need the current item of the list.

If we were to start adding special variables to grep/sort/map and other list processing functions, I fear we'd bloat the amount of information that Perl would have to track on each iteration. I suppose the bloat could be avoided if Perl could decide what information to track by surveying the contents of the block and any special variables used within. So for example, if $N was reserved for run count, it would only track run count if the grep/map/foreach block contained $N. Is that the kind of thing you are getting at?

There are so many possibilities of things one might want to track where would it stop? Run length? Cumulative frequency of the current value? Minimum found so far? Maximum found so far? Moving average? Wouldn't making all of these part of the language, each with its own special symbol make the language more complex? Wouldn't it be wiser to stick with the minimum number of symbols needed to do the job and let those who need more add them via the block/list syntax? An iteration through a list has to have a current member or else it makes no sense as an iterator. The special variable $_ is essential. A sort process needs two items to compare otherwise there is nothing to sort. $a and $b are essential to the process. But other "state of the list" variables are not. They are application dependent and perhaps should be left to applications to define on an as needed basis.

I guess I still don't get what you are striving for, design wise. A reflection on the value of different kinds of syntax elements? How best to use the tools at hand in Perl? The ideal minimal set of iterators, whether they be represented by new block function names or new special variables or some combination of the two?

Replies are listed 'Best First'.
Re^6: reduce like iterators
by LanX (Saint) on Jan 04, 2011 at 19:49 UTC
    > How is memorizing a new special var any different than memorizing a new BLOCK LIST function name?

    reduce iterates over neighboring couples, i.e. one iteration less.

    So each new iterator needs a new name ...

    Lets suppose appending _couple instead of inventing individual names is sufficient.

    first_couple {$a != $b} 0 ..9 any_couple ... map_couple ... ...

    when letting $_ iterating normally with $^PRE activated you might want to add _ante everywhere

    map_ante { $_ == $^PRE ? $_ : () } grep_ante ...

    simply having special vars which only change behavior when they are used within the block, simplifies notation.

    Even if one doesn't touch classical iterator names to guaranty backwards compatibility, already those three cases can be integrated into one naming convention:

    xgrep { $_ == 9 } LIST # like ordinary grep xgrep { $a == $b } LIST # like grep_couple xgrep { $^PRE == $_ } LIST # like grep_ante xgrep { $a == $^PRE } LIST # ERROR xfirst ... # and so on

    In other words orthogonality helps to keep the namespace slim. And I'm sure there are still other variants of special vars to be considered.

    I promise to answer your other points soon, unfortunately I don't have the possibility at the moment...

    Cheers Rolf