Destructuring ambiguity after &

[mva]

I'm relying on "&" destructuring to hierarchically decompose my URI namespace. At the end of the URI, the "&" can match both "no further path segment" as well as "exactly one empty path segment", and the two cannot be distinguished afterwards.

First a non-"&" example:

(use 'net.cgrand.moustache)  ;; [net.cgrand/moustache "1.0.0-SNAPSHOT"]

(def my-app
     (app
      ["foo"] (fn [_] "foo")
      ["foo" ""] (fn [_] "foo/")))

(my-app {:uri "/foo"}) ; ["foo"]
==> "foo"
(my-app {:uri "/foo/"}) ; ["foo" ""]
==> "foo/"

And then the "foo" prefix factored out:

(def my-app
     (app ["foo" &]
          (app [] (fn [_] "foo")
               [""] (fn [_] "foo/"))))

(my-app {:uri "/foo"}) ; ["foo"]
==> "foo"
(my-app {:uri "/foo/"}) ; ["foo" ""]
==> "foo"  ;; <--- my problem

Here, the two different URIs are no longer distinguishable by app's destructuring mechanism.

I'm not sure what I would expect app to do different here. When I wrote this code I thought I could represent the "no path" situation with [] -- which might be a bogus idea. Another option is to have ["foo" &] not match "/foo" at all, which would resolve the ambiguity afterwards.

What is your take on this?

[cgrand]

Good catch! I'll have to rework this. Originally & was meant to support nesting apps. So I may make ["foo" &] not match "foo".

Actually ["foo" &] and ["foo" & etc] does different things (the second form is not considered nesting) so I may decide that ["foo" & etc] can also match "/foo". However it's not very regular.

I'll have to ponder this and how this relate with the ring disussion on context/path handling.