Skip to main content
changed the treeform discussion a bit
Source Link
WReach
  • 69.3k
  • 4
  • 165
  • 272

Summary

The root cause of the surprising behaviour is that Function does not recognize Slot[] when it appears within an association object (as opposed to an association constructor). To fix it, we must either "unwrap" the association object returned by URLParse or use a different approach altogether.

The Problem: Association Objects vs. Association Constructors

We can demonstrate the problem with a simpler example:

f = With[{assoc = <| "a" -> #1 |>}, assoc &]
(* <|"a" -> #1|> & *)

The function definition looks okay. But it will not work:

f["hello world!"]
(* <|"a" -> #1|> *)

We can see the structural difference between an association objectconstructor and an association constructorobject using TreeForm:

fFunction[<| "a" -> # |>] // TreeForm    (* constructor *)

association object TreeForm

yet:association constructor TreeForm

<|Function[Evaluate[<| "a" -> #1|># &|>]] // TreeForm    (* object *)

association constructor TreeFormassociation object TreeForm

More discussion on this distinction can be found in (148095). See the section labelled Ambiguity of Association.

Fixing the Original Definition

We can change the original definition to unwrap the association object during the initial evaluation and to recreate it upon use. We do that using Normal@URLParse[...] and Inactive[URLBuild@*Association]. The updated definition looks like this:

ClearAll[urlModifier];
urlModifier[url_]:=ReplaceAll[Function@Evaluate[
    Inactive[URLBuild@*Association][
        Normal@URLParse[url]/.{"slot"->Inactive[StringReplace][Slot[1]," "->"_"]}
    ]
],{Inactive[x_]:>x}];

... so then:

urlModifier["https://www.somewebsite.com/path/slot"]["hello world!"]

(* "https://www.somewebsite.com/path/hello_world%21" *)

Alternative Definitions

There are simpler ways to express this operation.

For example, we could define the urlModifier operator like this:

ClearAll[urlModifier]

urlModifier[url_] :=
  URLBuild[URLParse[url] /. {"slot" -> StringReplace[#, " "->"_"]}] &

We could also define it explicitly as a "curried form":

ClearAll[urlModifier]

urlModifier[url_][s_] :=
  URLBuild[URLParse[url] /. { "slot" -> StringReplace[s," "->"_"]}]

The Function form offers an advantage over the curried form in that, if desired, we could perform the initial URL-parsing at the moment of creation instead of every time the generated function is used:

ClearAll[urlModifier]

urlModifier[url_] :=
  With[{parsedUrl = URLParse[url]}
  , URLBuild[parsedUrl /. {"slot" -> StringReplace[#, " "->"_"]}] &
  ]

All of these definitions give the same results as the corrected original.

Summary

The root cause of the surprising behaviour is that Function does not recognize Slot[] when it appears within an association object (as opposed to an association constructor). To fix it, we must either "unwrap" the association object returned by URLParse or use a different approach altogether.

The Problem: Association Objects vs. Association Constructors

We can demonstrate the problem with a simpler example:

f = With[{assoc = <| "a" -> #1 |>}, assoc &]
(* <|"a" -> #1|> & *)

The function definition looks okay. But it will not work:

f["hello world!"]
(* <|"a" -> #1|> *)

We can see the structural difference between an association object and an association constructor using TreeForm:

f // TreeForm

association object TreeForm

yet:

<| "a" -> #1|> & // TreeForm

association constructor TreeForm

More discussion on this distinction can be found in (148095). See the section labelled Ambiguity of Association.

Fixing the Original Definition

We can change the original definition to unwrap the association object during the initial evaluation and to recreate it upon use. We do that using Normal@URLParse[...] and Inactive[URLBuild@*Association]. The updated definition looks like this:

ClearAll[urlModifier];
urlModifier[url_]:=ReplaceAll[Function@Evaluate[
    Inactive[URLBuild@*Association][
        Normal@URLParse[url]/.{"slot"->Inactive[StringReplace][Slot[1]," "->"_"]}
    ]
],{Inactive[x_]:>x}];

... so then:

urlModifier["https://www.somewebsite.com/path/slot"]["hello world!"]

(* "https://www.somewebsite.com/path/hello_world%21" *)

Alternative Definitions

There are simpler ways to express this operation.

For example, we could define the urlModifier operator like this:

ClearAll[urlModifier]

urlModifier[url_] :=
  URLBuild[URLParse[url] /. {"slot" -> StringReplace[#, " "->"_"]}] &

We could also define it explicitly as a "curried form":

ClearAll[urlModifier]

urlModifier[url_][s_] :=
  URLBuild[URLParse[url] /. { "slot" -> StringReplace[s," "->"_"]}]

The Function form offers an advantage over the curried form in that, if desired, we could perform the initial URL-parsing at the moment of creation instead of every time the generated function is used:

ClearAll[urlModifier]

urlModifier[url_] :=
  With[{parsedUrl = URLParse[url]}
  , URLBuild[parsedUrl /. {"slot" -> StringReplace[#, " "->"_"]}] &
  ]

All of these definitions give the same results as the corrected original.

Summary

The root cause of the surprising behaviour is that Function does not recognize Slot[] when it appears within an association object (as opposed to an association constructor). To fix it, we must either "unwrap" the association object returned by URLParse or use a different approach altogether.

The Problem: Association Objects vs. Association Constructors

We can demonstrate the problem with a simpler example:

f = With[{assoc = <| "a" -> #1 |>}, assoc &]
(* <|"a" -> #1|> & *)

The function definition looks okay. But it will not work:

f["hello world!"]
(* <|"a" -> #1|> *)

We can see the structural difference between an association constructor and an association object using TreeForm:

Function[<| "a" -> # |>] // TreeForm    (* constructor *)

association constructor TreeForm

Function[Evaluate[<| "a" -> # |>]] // TreeForm    (* object *)

association object TreeForm

More discussion on this distinction can be found in (148095). See the section labelled Ambiguity of Association.

Fixing the Original Definition

We can change the original definition to unwrap the association object during the initial evaluation and to recreate it upon use. We do that using Normal@URLParse[...] and Inactive[URLBuild@*Association]. The updated definition looks like this:

ClearAll[urlModifier];
urlModifier[url_]:=ReplaceAll[Function@Evaluate[
    Inactive[URLBuild@*Association][
        Normal@URLParse[url]/.{"slot"->Inactive[StringReplace][Slot[1]," "->"_"]}
    ]
],{Inactive[x_]:>x}];

... so then:

urlModifier["https://www.somewebsite.com/path/slot"]["hello world!"]

(* "https://www.somewebsite.com/path/hello_world%21" *)

Alternative Definitions

There are simpler ways to express this operation.

For example, we could define the urlModifier operator like this:

ClearAll[urlModifier]

urlModifier[url_] :=
  URLBuild[URLParse[url] /. {"slot" -> StringReplace[#, " "->"_"]}] &

We could also define it explicitly as a "curried form":

ClearAll[urlModifier]

urlModifier[url_][s_] :=
  URLBuild[URLParse[url] /. { "slot" -> StringReplace[s," "->"_"]}]

The Function form offers an advantage over the curried form in that, if desired, we could perform the initial URL-parsing at the moment of creation instead of every time the generated function is used:

ClearAll[urlModifier]

urlModifier[url_] :=
  With[{parsedUrl = URLParse[url]}
  , URLBuild[parsedUrl /. {"slot" -> StringReplace[#, " "->"_"]}] &
  ]

All of these definitions give the same results as the corrected original.

deleted 165 characters in body
Source Link
WReach
  • 69.3k
  • 4
  • 165
  • 272

Summary

The root cause of the surprising behaviour is that Function does not recognize Slot[] when it appears within an association object (as opposed to an association constructor). To fix it, we must either "unwrap" the association object returned by URLParse or use a different approach altogether.

The Problem: Association Objects vs. Association Constructors

The problem is that the function is being constructed from an association object. Function will not recognize slot references that appear within such objects.

We can demonstrate the problem with a simpler example:

f = With[{assoc = <| "a" -> #1 |>}, assoc &]
(* <|"a" -> #1|> & *)

The function definition looks okay. But it will not work:

f["hello world!"]
(* <|"a" -> #1|> *)

We can see the structural difference between an association object and an association constructor using TreeForm:

f // TreeForm

association object TreeForm

yet:

<| "a" -> #1|> & // TreeForm

association constructor TreeForm

More discussion on this distinction can be found in (148095). See the section labelled Ambiguity of Association.

Fixing the Original Definition

We can change the original definition to unwrap the association object during the initial evaluation and to recreate it upon use. We do that using Normal@URLParse[...] and Inactive[URLBuild@*Association]. The updated definition looks like this:

ClearAll[urlModifier];
urlModifier[url_]:=ReplaceAll[Function@Evaluate[
    Inactive[URLBuild@*Association][
        Normal@URLParse[url]/.{"slot"->Inactive[StringReplace][Slot[1]," "->"_"]}
    ]
],{Inactive[x_]:>x}];

... so then:

urlModifier["https://www.somewebsite.com/path/slot"]["hello world!"]

(* "https://www.somewebsite.com/path/hello_world%21" *)

Alternative Definitions

There are simpler ways to express this operation.

For example, we could define the urlModifier operator like this:

ClearAll[urlModifier]

urlModifier[url_] :=
  URLBuild[URLParse[url] /. {"slot" -> StringReplace[#, " "->"_"]}] &

We could also define it explicitly as a "curried form":

ClearAll[urlModifier]

urlModifier[url_][s_] :=
  URLBuild[URLParse[url] /. { "slot" -> StringReplace[s," "->"_"]}]

The Function form offers an advantage over the curried form in that, if desired, we could perform the initial URL-parsing at the moment of creation instead of every time the generated function is used:

ClearAll[urlModifier]

urlModifier[url_] :=
  With[{parsedUrl = URLParse[url]}
  , URLBuild[parsedUrl /. {"slot" -> StringReplace[#, " "->"_"]}] &
  ]

All of these definitions give the same results as the corrected original.

Summary

The root cause of the surprising behaviour is that Function does not recognize Slot[] when it appears within an association object (as opposed to an association constructor). To fix it, we must either "unwrap" the association object returned by URLParse or use a different approach altogether.

The Problem: Association Objects vs. Association Constructors

The problem is that the function is being constructed from an association object. Function will not recognize slot references that appear within such objects.

We can demonstrate the problem with a simpler example:

f = With[{assoc = <| "a" -> #1 |>}, assoc &]
(* <|"a" -> #1|> & *)

The function definition looks okay. But it will not work:

f["hello world!"]
(* <|"a" -> #1|> *)

We can see the structural difference between an association object and an association constructor using TreeForm:

f // TreeForm

association object TreeForm

yet:

<| "a" -> #1|> & // TreeForm

association constructor TreeForm

More discussion on this distinction can be found in (148095). See the section labelled Ambiguity of Association.

Fixing the Original Definition

We can change the original definition to unwrap the association object during the initial evaluation and to recreate it upon use. We do that using Normal@URLParse[...] and Inactive[URLBuild@*Association]. The updated definition looks like this:

ClearAll[urlModifier];
urlModifier[url_]:=ReplaceAll[Function@Evaluate[
    Inactive[URLBuild@*Association][
        Normal@URLParse[url]/.{"slot"->Inactive[StringReplace][Slot[1]," "->"_"]}
    ]
],{Inactive[x_]:>x}];

... so then:

urlModifier["https://www.somewebsite.com/path/slot"]["hello world!"]

(* "https://www.somewebsite.com/path/hello_world%21" *)

Alternative Definitions

There are simpler ways to express this operation.

For example, we could define the urlModifier operator like this:

ClearAll[urlModifier]

urlModifier[url_] :=
  URLBuild[URLParse[url] /. {"slot" -> StringReplace[#, " "->"_"]}] &

We could also define it explicitly as a "curried form":

ClearAll[urlModifier]

urlModifier[url_][s_] :=
  URLBuild[URLParse[url] /. { "slot" -> StringReplace[s," "->"_"]}]

The Function form offers an advantage over the curried form in that, if desired, we could perform the initial URL-parsing at the moment of creation instead of every time the generated function is used:

ClearAll[urlModifier]

urlModifier[url_] :=
  With[{parsedUrl = URLParse[url]}
  , URLBuild[parsedUrl /. {"slot" -> StringReplace[#, " "->"_"]}] &
  ]

All of these definitions give the same results as the corrected original.

Summary

The root cause of the surprising behaviour is that Function does not recognize Slot[] when it appears within an association object (as opposed to an association constructor). To fix it, we must either "unwrap" the association object returned by URLParse or use a different approach altogether.

The Problem: Association Objects vs. Association Constructors

We can demonstrate the problem with a simpler example:

f = With[{assoc = <| "a" -> #1 |>}, assoc &]
(* <|"a" -> #1|> & *)

The function definition looks okay. But it will not work:

f["hello world!"]
(* <|"a" -> #1|> *)

We can see the structural difference between an association object and an association constructor using TreeForm:

f // TreeForm

association object TreeForm

yet:

<| "a" -> #1|> & // TreeForm

association constructor TreeForm

More discussion on this distinction can be found in (148095). See the section labelled Ambiguity of Association.

Fixing the Original Definition

We can change the original definition to unwrap the association object during the initial evaluation and to recreate it upon use. We do that using Normal@URLParse[...] and Inactive[URLBuild@*Association]. The updated definition looks like this:

ClearAll[urlModifier];
urlModifier[url_]:=ReplaceAll[Function@Evaluate[
    Inactive[URLBuild@*Association][
        Normal@URLParse[url]/.{"slot"->Inactive[StringReplace][Slot[1]," "->"_"]}
    ]
],{Inactive[x_]:>x}];

... so then:

urlModifier["https://www.somewebsite.com/path/slot"]["hello world!"]

(* "https://www.somewebsite.com/path/hello_world%21" *)

Alternative Definitions

There are simpler ways to express this operation.

For example, we could define the urlModifier operator like this:

ClearAll[urlModifier]

urlModifier[url_] :=
  URLBuild[URLParse[url] /. {"slot" -> StringReplace[#, " "->"_"]}] &

We could also define it explicitly as a "curried form":

ClearAll[urlModifier]

urlModifier[url_][s_] :=
  URLBuild[URLParse[url] /. { "slot" -> StringReplace[s," "->"_"]}]

The Function form offers an advantage over the curried form in that, if desired, we could perform the initial URL-parsing at the moment of creation instead of every time the generated function is used:

ClearAll[urlModifier]

urlModifier[url_] :=
  With[{parsedUrl = URLParse[url]}
  , URLBuild[parsedUrl /. {"slot" -> StringReplace[#, " "->"_"]}] &
  ]

All of these definitions give the same results as the corrected original.

Source Link
WReach
  • 69.3k
  • 4
  • 165
  • 272

Summary

The root cause of the surprising behaviour is that Function does not recognize Slot[] when it appears within an association object (as opposed to an association constructor). To fix it, we must either "unwrap" the association object returned by URLParse or use a different approach altogether.

The Problem: Association Objects vs. Association Constructors

The problem is that the function is being constructed from an association object. Function will not recognize slot references that appear within such objects.

We can demonstrate the problem with a simpler example:

f = With[{assoc = <| "a" -> #1 |>}, assoc &]
(* <|"a" -> #1|> & *)

The function definition looks okay. But it will not work:

f["hello world!"]
(* <|"a" -> #1|> *)

We can see the structural difference between an association object and an association constructor using TreeForm:

f // TreeForm

association object TreeForm

yet:

<| "a" -> #1|> & // TreeForm

association constructor TreeForm

More discussion on this distinction can be found in (148095). See the section labelled Ambiguity of Association.

Fixing the Original Definition

We can change the original definition to unwrap the association object during the initial evaluation and to recreate it upon use. We do that using Normal@URLParse[...] and Inactive[URLBuild@*Association]. The updated definition looks like this:

ClearAll[urlModifier];
urlModifier[url_]:=ReplaceAll[Function@Evaluate[
    Inactive[URLBuild@*Association][
        Normal@URLParse[url]/.{"slot"->Inactive[StringReplace][Slot[1]," "->"_"]}
    ]
],{Inactive[x_]:>x}];

... so then:

urlModifier["https://www.somewebsite.com/path/slot"]["hello world!"]

(* "https://www.somewebsite.com/path/hello_world%21" *)

Alternative Definitions

There are simpler ways to express this operation.

For example, we could define the urlModifier operator like this:

ClearAll[urlModifier]

urlModifier[url_] :=
  URLBuild[URLParse[url] /. {"slot" -> StringReplace[#, " "->"_"]}] &

We could also define it explicitly as a "curried form":

ClearAll[urlModifier]

urlModifier[url_][s_] :=
  URLBuild[URLParse[url] /. { "slot" -> StringReplace[s," "->"_"]}]

The Function form offers an advantage over the curried form in that, if desired, we could perform the initial URL-parsing at the moment of creation instead of every time the generated function is used:

ClearAll[urlModifier]

urlModifier[url_] :=
  With[{parsedUrl = URLParse[url]}
  , URLBuild[parsedUrl /. {"slot" -> StringReplace[#, " "->"_"]}] &
  ]

All of these definitions give the same results as the corrected original.