Why does the `Context` of a `Pattern` depend on whether I use mini-notation to define it?

Jeff_Brown · 2 January 2022 17:22

I expected these two Patterns to be the same. (To evaluate this in GHCI one first needs to :set -XScopedTypeVariables -XOverloadedStrings.)

p1 :: Pattern String = "x"
p2 :: Pattern String = pure "x"

If I only inspect their Show instances, they do appear to be the same:

*Sound.Tidal.Context> p1
(0>1)|"x"
*Sound.Tidal.Context> p2
(0>1)|"x"

But if I query them, one has a nonempty Context while the other doesn't:

*Sound.Tidal.Context> s a b = State { arc = Arc a b, controls = mempty }
*Sound.Tidal.Context> query p1 (s 0 1)
[[((1,1),(2,1))](0>1)|"x"]
*Sound.Tidal.Context> query p2 (s 0 1)
[[             ](0>1)|"x"]

(I've inserted space above to make the two results easier to compare.)

What's going on?

jwaldmann · 2 January 2022 17:34

Implementation of pure creates the empty context:

github.com

tidalcycles/Tidal/blob/main/src/Sound/Tidal/Pattern.hs#L70

    
      
          instance NFData a => NFData (Pattern a)
          
          
-- type StateMap = Map.Map String (Pattern Value)
          type ControlPattern = Pattern ValueMap
          
          
-- * Applicative and friends
          
          
instance Applicative Pattern where
            -- | Repeat the given value once per cycle, forever
            pure v = Pattern $ \(State a _) ->
              map (\a' -> Event (Context []) (Just a') (sect a a') v) $ cycleArcsInArc a
          
          
  (<*>) = applyPatToPatBoth
          
          
-- | Like <*>, but the 'wholes' come from the left
          (<*) :: Pattern (a -> b) -> Pattern a -> Pattern b
          (<*) = applyPatToPatLeft
          
          
-- | Like <*>, but the 'wholes' come from the right
          (*>) :: Pattern (a -> b) -> Pattern a -> Pattern b
          (*>) = applyPatToPatRight

[ugh, I didn't mean this code to be inlined here]

For the other pattern, mininotation parser inserts source locations.

[EDIT] with pure, mininotation parser is not used at all.

polymorphic.engine · 2 January 2022 18:16

I think the context is only used by feedforward/tidal-gui in the code highlighter to figure out which parts of the code to actually highlight (it's actually a list of pairs of coordinates in the editor), so I wouldn't really worry about it too much

jwaldmann · 2 January 2022 19:13

Yes. Perhaps it's better to hide Context from this kind of output?

[EDIT] sorry I gave the wrong source code location for that.

polymorphic.engine · 2 January 2022 19:36

Yeah I agree that we should hide it by default, it's probably in there for testing purposes

jwaldmann · 2 January 2022 20:11

To clarify (for myself, mostly ...) this is about instance Show (Event a).

Contexts are already hidden in instance Show (Pattern a).

The original poster used query(Arc) to show Events.

"t(1,8)":: Pattern Bool
(0>⅛)|True
...
queryArc ("t(1,8)":: Pattern Bool) (Arc 0 1)
[[((1,1),(2,1)),((3,1),(4,1)),((5,1),(6,1))](0>⅛)|True,...]

Jeff_Brown · 3 January 2022 02:35

Aha! It doesn't matter when playing, in short, but I'll have to modify my tests to ignore those Contexts. Thanks all!

I agree, it seems reasonable to modify the Show instance of Event to not show the Contexts.

polymorphic.engine · 3 January 2022 07:56

Opened a pull request:

github.com/tidalcycles/Tidal

Hide contexts from Events per default

tidalcycles:main ← polymorphicengine:main

opened 07:55AM - 03 Jan 22 UTC

polymorphicengine

+6 -2

https://forum.toplap.org/t/why-does-the-context-of-a-pattern-depend-on-wheth…er-i-use-mini-notation-to-define-it/3767/4 In the above thread we discussed that it can be a little bit confusing that Contexts are in the Show instance for Events, but not for Patterns. I removed it, but there are still the functions `showFull` and `showEventFull` that show the Context of patterns/events.

Jeff_Brown · 3 January 2022 14:32

Ditto:

polymorphic.engine · 3 January 2022 14:48

Ah nice, didn't think of Eq or Ord.
And I think your implementation of the Ord instance without considering the contexts is ok

Jeff_Brown · 5 January 2022 21:44

PS Here's my latest PR to that effect. The earlier one had problems (and my attempts to update it went awry somehow).

github.com/tidalcycles/Tidal

Define the Eq and Ord instances for the Event type by hand.

tidalcycles:main ← JeffreyBenjaminBrown:suggest

opened 04:02PM - 03 Jan 22 UTC

JeffreyBenjaminBrown

+29 -1

This way, otherwise-equal `Event`s are considered equal even if their `Contex…t`s (debugging information) differ. Also, `Event`s are compared first on when they happen (the `part` field), second on their `value`, and only last on their `whole` field (which is often `Nothing`). Sorting a `List` of `Event`s will thus cause the early ones to be first in the `List`, and contemporaneous ones to be adjacent in the list even if their `whole`s differ.