Back to Questions
1.2k
views6
comments
Feature request: AS bindings in WHEN clauses for pattern matching
f#

I find myself calling code twice when I want to perform a test that has a side-effect of producing a value in a when clause: 

1
2
3
4
5
6
7
8

match foo with

    | A(Pattern,Here) as input

    when expensiveFn input |> Option.isSome  -> 

            let x = expensiveFn input |> Option.get

Although I could memoize this class of fn's, it would seem more straightforard if I could use an as clause in the when:

1
2
3
4
5
6
7
8

match foo with

    | A(Pattern,Here) as input

    when expensiveFn input as test |> Option.isSome  -> 

            let x = test|> Option.get

Another option would be to allow an intermediate let in between the pattern match and the "when", like a "let" in a LINQ query:

1
2
3
4
5
6
7
8
9
10

match foo with

    | A(Pattern,Here) as input

    let test = expensiveFn input 

    when test |> Option.isSome  -> 

            let x = test |> Option.get

(BTW, I'm using:

[ c o d e l a n g u a g e = " F # " ]

and I'm still getting my spaces eaten - something else needed??)

Anyone else find this useful? Am I missing an alternate approach?

thanks,

mike

.

E.g., in the case of:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

 

match foo with

| A(Pattern,Here) as input

when expensiveFn input as test |> Option.isSome -> 

let x = test|> Option.get 

| Another Pattern::Here as input

when ...

| YetAnother Pattern::Here as input

when ...
By on 12/6/2009 12:48 PM ()

You shouldn't have effects inside a pattern match. I'd suggest you get rid of the 'when' and do this instead:

1
2
3
4
5
6
7
8
9

 

match foo with 
| A(Pattern,Here) as input ->
    let r = expensiveFn input
    match r with
    | Some(x) -> (* code *)
    | None -> (* code that would have gone in a pattern further below *)
By on 12/6/2009 12:11 PM ()

That refactoring doesn't do the same thing, right? - if the inner match fails in your case, then the next subsequent outer match will not be tried.

By on 12/6/2009 12:46 PM ()

Well, that's why I had

"code that would have gone in a pattern further below"

This may be easier said than done in a particular case, depending on exactly the control flow and code that's going on.

By on 12/6/2009 12:50 PM ()

> Well, that's why I had

> "code that would have gone in a pattern further below"

Gotcha. (Just goes to show that comments tend to be no-ops for my brain...)

Code will wander right, but that's not so bad. I stilll think the "as" here seems natural.

Why not have it operate like an ebedded let in any expression? 

1
2
3
4

let y = (m*x) as slope + b

// y and slope visible from here on

But this would mess something else up somewhere...

By on 12/6/2009 5:45 PM ()

Nice feature, IMHO.

By on 12/7/2009 4:04 AM ()

    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