Patterns in left- and right-hand sides of ":"?

Innards
1

(some random thoughts about mininotation syntax w.r.t. :)

I thought that casio:[0 1] was equivalent to [casio:0 casio:1] but it's not - it is equivalent to casio [0 1], the parser accepts casio: as an atom in Pattern String.

On the other hand, [bd sn]:0 is rejected by the mininotation parser (syntax error in sequence).

"casio::::2:3" :: Pattern String is accepted and s "casio::::2:3" is s "casio:2".

Could/should the parser be more strict here? (reject the first example as well)

Or more flexible (treat : as binary operator on patterns)? - That certainly looks like much more work.

1 Like
2

i think it would be good to not allow : as character in a string to avoid such confusions..
it would be satisfying to make this operation part of the language to allow patterning it, but it seems quite tricky because the types don't really line up.. what i mean is that we would probably want to parse x:2 as Pattern (String,Int) but the s or sound function doesn't go well with that..
the reason for this (or rather why this noation actually works at the moment) is because of grouped parameters: for example look at the definition of sound https://hackage.haskell.org/package/tidal-1.9.3/docs/src/Sound.Tidal.Params.html#sound
this is a bit of a hack imo, but it works and it would be quite difficult to "make it right"

3

now that i think of it, because of the above mentioned hack it is actually neccessary that it is parsed as it is at the moment..

so this would required some big changes with the way grouped parameters work, which might be worth investigating to allow patterning

4

big changes .. worth investigating

maybe. we can always write s "foo" # n "bar" so perhaps we are not missing too much when arguments of : are not patternable.

My observation was just that the : parsing behaviour feels inconsistent (rejects pattern in left-hand side, but seems to accept pattern in right-hand side - but actually the semantics is different).

We could strengthen the definition of what's accepted in an atomic String
(Tidal/src/Sound/Tidal/ParseBP.hs at 2.0-dev · tidalcycles/Tidal · GitHub)

pString = do c <- pCharNum <?> "charnum"
             cs <- many (letter <|> oneOf "0123456789:.-_") <?> "string"
             return (c:cs)

e.g., only allow at most one :. But, since no-one was complaining until now...

I was reading that there's a parser overhaul for tidal-2 coming anyway. Perhaps someone in the know can comment.

5

yes that's a good point

Well i wrote that overhaul, but as i tried to point out before, this has actually not much to do with the parser, it is just how tidal is grouping parameters at the moment and this is the main source of the unexpected failures/successes of the parser, i don't think it is too neccessary to try to fix some results of this, rather it would be a possibility to actually reimplement the grouping itself (and move it to the parser) which would fix everything