Well, all's fair if you predeclare, but a language whose main expression format is prefix or postfix is no longer Perl. Maybe Perlisp or Pforth. Plus, given the complex interactions of the various operators, many of which don't look like operators, it's not necessarily straightforward to provide, say, a "use rpn;" pragma.
On 3/31/08, Miller, Hugh (hdmi) <[EMAIL PROTECTED]> wrote: > The inevitable question - why not support Polish Notation or Reverse > Polish ? Well known to be easier to use, since it involves no > ambiguities in regard to association, is notationally clearer (not > needing parentheses). Seems to make it easier to analyze what one might > want to mean by > > [op] (p1 p2 p3 ... ) > > E.g., > > Convention 1 > > [op] (p1 p2 p3 ... ) =by definition= p1 p2 op p3 op ... pN op > > Convention 2 > > [op] (p1 p2 p3 ... ) =by definition= p1 p2 p3 ... pN op op op ... > op > > One could support both conventions (with notational differences) ... > > Example > > [^] (2 3 4) =defn 1= 2 3 ^ 4 ^ , i.e., (2^3)^4 > > [^] (2 3 4) = defn 2= 2 3 4 ^^ , i.e., (2^(3^4)) > > Etc. > > - > Hugh Miller > e-mail: [EMAIL PROTECTED] > > > -----Original Message----- > From: Darren Duncan [mailto:[EMAIL PROTECTED] > Sent: Sunday, March 30, 2008 2:00 AM > To: p6l > Subject: Re: Query re: duction and precedence. > > Mark J. Reed wrote: > > You anticipated me. So, is there a core method for > > foldl/foldr/inject/reduce, or do you have to roll your own as in p5? > > > > On 3/29/08, Larry Wall <[EMAIL PROTECTED]> wrote: > >> On Sat, Mar 29, 2008 at 10:18:53PM -0400, Mark J. Reed wrote: > >> : In general, is > >> : > >> : [op] (p1,p2,p3,p4...) > >> : > >> : expected to return the same result as > >> : > >> : p1 op p2 op p3 op p4... > >> : > >> : including precedence considerations? > >> > >> Yes, in fact the section on Reduction Operators uses exponentiation > >> obliquely in one of its examples of something that should work > >> right-to-left. Admittedly it's not clearly stated there... > >> > >> But the basic idea is always that the reduction form should produce > >> the same result as if you'd written it out with interspersed infixes. > >> It's a linguistic construct, not a functional programming construct. > >> It's not intended to be in the same league as foldl and foldr, and is > > >> only just slightly beyond a macro insofar as it can intersperse > >> however many operators it needs to for an arbitrarily sized list. > >> It's not making any attempt to deal with anonymous first-class > >> functions though. Call a real function for that. :) > > I think it would be powerful while not too difficult for Perl 6's > "reduce" > to be able to do everything you'd get in functional programming, at > least some of the time. > > Generally speaking, as long as the base operator is associative, then > > [op] *$seq_or_array_etc > > ... should auto-parallelize with a deterministic result; or as long as > the base operator is both associative and commutative, then > > [op] *$set_or_bag_or_seq_or_array_etc > > ... should also auto-parallelize with a deterministic result. > > And then you get all the functional programming goodies. The first > example works for string catenation, but the second doesn't; the second > does work for sum|product|and|or|xor|union|intersection though. > > Some base operators have an identity value in case the input collection > is empty, as is the case with the above operators, but others only work > with a non-empty input, such as mean|median|mode. > > For other operators, non-assoc etc, the work will probably all have to > be linear. Eg difference|quotient|exponentiation. > > Something I'm wondering, though, realistically how often would one > actually be reducing on an operator that is not associative? What > practical use is there for [-] (3,4,5) for example? > > Are you just supporting that with all operators for parsing rule > simplicity as per a macro? I can understand that reasoning, but > otherwise ... > > I would think it makes sense to restrict the use of the reduction > meta-operator to just work over operators that are at least associative. > > -- Darren Duncan > -- Sent from Gmail for mobile | mobile.google.com Mark J. Reed <[EMAIL PROTECTED]>
