Query re: duction and precedence.

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) <HughMiller@chevron.com> 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:	hdmi@chevrontexaco.com
>
>
> -----Original Message-----
> From: Darren Duncan [mailto:darren@darrenduncan.net]
> Sent: Sunday, March 30, 2008 2:00 AM
> To: p6l
> Subject: Re: Query re: duction and precedence.
>
> Mark J. Reed wrote: 
> 
>
> 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|intersectio
n 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 <markjreed@mail.com>