Back to Questions
996
views3
comments
multiple evals of active pattern matchers needed?
f#compiler

Paraphrasing some code:

1
2
3
4
5
6
7
8
9
10

let (|SN|_|) = function
    | R_Scope(ScopeName name,rast) 
                        ->Some (name, rast)
    | _ -> None

let fn = function
    | SN ("A", a) -> ...
    | SN ("B", [ b] ) -> ...
    | SN ("C", R_X( [ R_Y "$$" as m; e2 ]) -> ...
    | _ -> ...

Now, the active pattern SN in the above case seems to be getting called up to three times, up to the first |case that matches.

However because the AP does not have additional parameters and the only input is from the function's implied "match $$ with", which remains constant for each case invocation, why doesn't the compiler just call the AP once and simply do the pattern-matching/binding (up to) 3 times? Even w/o optimization on I still seem to get this behavior.

thanks,

m

.

The last line of Section 7.1.2.3 of the spec indicates that:

A pattern matching function may be executed multiple times against the same input when resolving a single overall pattern match: the precise number of times the active recognizer is executed is implementation dependent.

So it looks like you can't rely on such an example being evaluated only once, although it's possible that a future version of the compiler will optimize the active pattern decision tree differently.

By on 6/22/2009 12:28 PM ()

So, did I ask something really silly? :) If so, let me know...

I just want to know if I should refrain from using active patterns when they aren't trivial and when I'm using the same AP mutliple times in the same match but with different pattern matches & bindings.

By on 6/22/2009 11:50 AM ()

Thanks for the pointer - appreciated.

That's a shame -- this, at the surface anyway, seems like an "already unrolled loop" that makes detection of the single call rather explicit. ( activePatternFns |> sort |> unique |> // use local memoized version for pattern match orelse eval and memoize )

It's easy to view AP's as hygenic/type-safe macros of sorts that only work on the left side of match cases - now that (somewhat misguided) analogy is broken, and alas, so is some code speed - so will re-factor AP's in inner loops that look like this.

thanks,m

By on 6/22/2009 1:22 PM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper