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

Jeff_Brown · January 2, 2022, 5:22pm

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 · January 2, 2022, 5:34pm

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 · January 2, 2022, 6:16pm

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 · January 2, 2022, 7:13pm

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 · January 2, 2022, 7:36pm

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

jwaldmann · January 2, 2022, 8:11pm

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 · January 3, 2022, 2:35am

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 · January 3, 2022, 7:56am

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 · January 3, 2022, 2:32pm

Ditto:

polymorphic.engine · January 3, 2022, 2:48pm

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 · January 5, 2022, 9:44pm

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.