Preserve visual structure when matching unspecified keys in maps and sets #182
Replies: 4 comments
-
@yuhan0 pointed out (in Slack channel) that |
Beta Was this translation helpful? Give feedback.
-
Based on Slack discussion, an existing option for picky users like me is: (defn memory-variable? [v]
(and (symbol? v)
(re-matches #"!.+" (name v))))
(def extract-unspecified-kvs
(s/bottom-up
(s/rewrite
{& (m/seqable (m/or [(m/pred memory-variable? !unspecified-ks) !unspecified-vs]
!specified-kvs) ...)}
{& (!specified-kvs ... ['& (`m/map-of !unspecified-ks !unspecified-vs)])}
?else
?else)))
(defmacro | [& rules]
`(s/rewrite ~@(map extract-unspecified-kvs rules)))
((| {!k !v}
{!k (m/app inc !v)})
{:a 1
:b 2
:c 3})
;;=> {:a 2, :b 3, :c 4} ^^ use a macro to replace This was offered with big warning signs that I don't fully understand yet :) |
Beta Was this translation helpful? Give feedback.
-
Another idea floated in Slack: |
Beta Was this translation helpful? Give feedback.
-
I like this suggestion from @yuhan0 : "There is already precedence in ..?n for splitting a symbol up into components to bind ?n"
My favourite is |
Beta Was this translation helpful? Give feedback.
-
Problem
Maps and sets with unspecified keys are at a syntactic disadvantage.
Example
The current tools for working with unspecified keys are:
Both visually obscure the structure.
Observe that vectors do not suffer this problem:
[!k ...]
Maps and sets are disadvantaged because unspecified keys must only appear in the
&
clause. This restriction makes sense because keys in maps and sets are unordered, so specified keys do not overlap with unspecified keys.Motivation
In isolation, one may argue that a single map is easy to understand, but in the face of nested maps, the structure quickly becomes obscured. Consider:
The latter is linguistic, the former is visual.
Furthermore, if we had correspondence (see #129), nested maps transformations would preserve their structure completely.
Possible Solution
Make memory variables imply unspecified keys when specified as a key in a map or set.
!k !v
implies{& (map-of !k !v))
.Why does this rule make sense?
Beta Was this translation helpful? Give feedback.
All reactions