Compare: ø, µ, ð, ɓ

I think ø must force the arity of the chain, but the others don't. Notice that ɓ doesn't do what ,@/ would

okay so the first one makes sense i guess, but if the first one does that, it doesn't make so much sense why the second still works

the fourth is... weird, i'd expect it to do ,@/, yeah

in fact, ,ɓ/ , works the same as ,ð/ ,

so the "swap args" is working on neither the quicked link or the following chain

looks like it's source code digging time

) is unique, in that it's a "forward" separator - it can't apply "backwards" in the same way

Oh, I got it

		for word in regex_chain.findall(line):
			chain = []
			arity, start, isForward = chain_separators.get(word[:1], default_chain_separation)
			for token in regex_token.findall(start + word):
				if token in atoms:
					chain.append(atoms[token])
				elif token in quicks:
					popped = []
					while not quicks[token].condition(popped) and (chain or chains):
						popped.insert(0, chain.pop() if chain else chains.pop())
					chain += quicks[token].quicklink(popped, links, index)
				elif token in hypers:

The arity only kicks in on create_chain which isn't reached if the quick exhausts the previous chain

oh huh

That doesn't explain ø tho

okay, so basically while a quick's condition isn't met, if the chain is non-empty, it pops a link, and if it is, it pops an entire chain while there are still whole chains left

implicitly, each link starts with a chain separator with arity -1, start '', and forward is true

ok so if we walk through parsing ,ø/

actually you know what, i should just fork this and print the parsed code and quit

@cairdcoinheringaahing Nope, ) can be used

@hyper-neutrino Just open Python in tio and import jelly

oh right

[[{'arity': 0, 'chain': [{'arity': 1, 'call': <function reduce.<locals>.<lambda> at 0x7f6fbc3b69e0>}], 'call': <function create_chain.<locals>.<lambda> at 0x7f6fbc2f8830>}]]

Readable

whereas µ gives [[{'arity': 1, 'chain': [{'arity': 1, 'call': <function reduce.<locals>.<lambda> at 0x7faa28f069e0>}], 'call': <function create_chain.<locals>.<lambda> at 0x7faa28e48830>}]]

...hwhaa

ð gives [[{'arity': 2, 'chain': [{'arity': 1, 'call': <function reduce.<locals>.<lambda> at 0x7fba709a99e0>}], 'call': <function create_chain.<locals>.<lambda> at 0x7fba708eb830>}]]

same with ɓ

so i guess it does change the arity of the outer link

but since this sublink is a monad, it makes no difference

unless the outer arity is 0 and then it doesn't take an argument so the sublink monad is evaluated on 0 instead

huh

whut

i think that makes sense?

lol this is why i didn't implement chain separators in yuno

Ok, I think I get it. Essentially, when used by a quick, the chain separator applies "backwards" to the previous chain, as it gets "eaten" by the chain.pop() if chain else chains.pop() functionality. Therefore, in ,<sep>/, <sep> sets the arity of the whole line, not the previous link/chain. Example.

For ø, that makes it niladic, and so it doesn't even consider the argument passed. For the others, it makes them monadic/dyadic. However, / is a monad, meaning that it will only ever execute on the left argument. It requires a dyad to operate on, so it just runs the link to its left as dyadic_link, which shouldn't cause errors: Try it online!

So, if you want to run a monad M on the first element of a list equal to the number of elements in a list (e.g. halve the first element n times, the list has n elements), then Mµ/ works :P

oh... yeah, that looks right :p

,: tio.run/##y0rNyan8/1/n////0YY6CkY6Csax/6NNdBRMdRTMYgE

,€: tio.run/##y0rNyan8/1/nUdOa////RxvqKBjpKBjH/o820VEw1VEwiwUA

,ø€ produces nothing as expected: tio.run/##y0rNyan8/1/n8I5HTWv@//8fbaijYKSjYBz7P9pER8FUR8EsFgA

,µ€ produces [1, 1], [2, 2], [3, 3] as expected: tio.run/##y0rNyan8/1/n0NZHTWv@//8fbaijYKSjYBz7P9pER8FUR8EsFgA

... so does ,ð€...

does € automatically assume the link is monadic if it's variadic?

well anyway, ,µ" gives [1, 1], [2, 2], [3, 3] as expected

," gives [1, 4], [2, 5], [3, 6] and so does ,ð" - so I guess EACH assumes its link is a monad and VECTORIZE assumes it's a dyad

(since " actually breaks on monads for some reason)

and ,ɓ" gives [4, 1], [5, 2], [6, 3]

so yeah, i think your explanation is correct \o/

I think that some quicks definitely "assume" the link is of a specific arity, but I'm not sure about €

Maybe its because € is a hyper not a quick?

	'€': lambda link, none = None: attrdict(
		arity = max(1, link.arity),
		call = lambda x, y = None: [variadic_link(link, (t, y)) for t in iterable(x, make_range = True)]
	),

[[{'arity': 2, 'chain': [{'arity': 1, 'call': <function <lambda>.<locals>.<lambda> at 0x7ff7262939e0>}], 'call': <function create_chain.<locals>.<lambda> at 0x7ff7261d5830>}]]

That's ,ð€, so yeah, it looks like it assumes it to be a monad

hm. okay

oh, okay

and huh

tf

it assumes the link before is a monad, making y = None

that looks like a bug

That definitely is a bug

maybe when copy pasting left-map?

Ѐ does the same thing

	'Ѐ': lambda link, none = None: attrdict(
		arity = max(1, link.arity),
		call = lambda x, y = None: [variadic_link(link, (x, t)) for t in iterable(y, make_range = True)]
	),

Yeah, that doesn't make sense. Ѐ is always used on dyads, so the arity should be 2 and the y = None shouldn't be there

weird

I guess that's from copy-pasting from € as the code is the same aside from a couple of changes to fit the left/right map

probably

i kind of wish ) were itself variadic cuz it not only is monadic but affects the whole chain, but i've never really encountered that situation either lol

My issue with ) is that because its implemented as a quick attached to a chain, you can't do chain stuff with it. For example, Rð,µH (super simple) would yield [1,2,3,4,5],2.5 for 5, so Rð,)H should yield [1,2.5],[2,2.5],[3,2.5],[4,2.5],[5,2.5] per the 2-1 chaining rules: but it don't

wait why not

Because when you use a quick on a chain, it pops it out of the chaining patterns

[[{'arity': -1, 'chain': [{'arity': 1, 'ldepth': 0, 'call': <function <lambda> at 0x7f63cb95f440>}], 'call': <function create_chain.<locals>.<lambda> at 0x7f63cbefe170>}, {'arity': 1, 'chain': [{'arity': 2, 'call': <function <lambda>.<locals>.<lambda> at 0x7f63cbd9d830>}, {'arity': 1, 'ldepth': 0, 'call': <function <lambda> at 0x7f63cb95b290>}], 'call': <function create_chain.<locals>.<lambda> at 0x7f63cb8fb9e0>}]]

[
	[
		{
			'arity': -1,
			'chain': [
				{
					'arity': 1,
					'ldepth': 0,
					'call': <function <lambda> at 0x7f63cb95f440>
				}
			],
			'call': <function create_chain.<locals>.<lambda> at 0x7f63cbefe170>
		},
		{
			'arity': 1,
			'chain': [
				{
					'arity': 2,
					'call': <function <lambda>.<locals>.<lambda> at 0x7f63cbd9d830>
				},
				{
					'arity': 1,
					'ldepth': 0,
					'call': <function <lambda> at 0x7f63cb95b290>
				}
			],
			'call': <function create_chain.<locals>.<lambda> at 0x7f63cb8fb9e0>

ok so there's just one link obviously

the link contains just one chain?

No, it has 2

The first is the arity -1 one, which is R. The second is the arity: 1 one with 2 links in its chain

wait i am misreading the levels on this structure lol

thanks

okay so R is a variadic chain with just one link being the monadic range link

Compare that to the parsing for Rð,µH:

[
	[
		{'arity': -1,
		 'chain': [
			{'arity': 1,
			 'ldepth': 0,
			 'call': <function <lambda> at 0x7ff607913440>
			}
		 ],
		 'call': <function create_chain.<locals>.<lambda> at 0x7ff607eb2170>
		},
		{'arity': 2,
		 'chain': [
			{'arity': 2,
			 'call': <function <lambda> at 0x7ff607916950>
			}
		 ],
		 'call': <function create_chain.<locals>.<lambda> at 0x7ff607e0f9e0>
		},
		{'arity': 1,
		 'chain': [
			{'arity': 1,
			 'ldepth': 0,
			 'call': <function <lambda> at 0x7ff60790f290>
			}

Which clearly has 3 chains in a -1,2,1 arity pattern

... wait, why does it work that way

wait shouldn't there at least be an empty dyadic chain in the first one?

The chains in Rð,µH are R (-1), , (2, because of ð) and H (1 because of µ)

that part makes sense

i am confused about the ) variant lol

However, ) is equivalent to µ€, and the € nests the ð,µH chains

shouldn't it only pop the , chain?

I is dumb

@hyper-neutrino I think it doesn't because of the 2-1 chaining rule? But that doesn't make sense :/

regex-chain matches ['R', 'ð,', ')H']

so initially, chains = []

in the first chain, there is only "R" which regex-token matches as ['R']

so the first chain is [range], and that gets appended to chains

Which is the first variadic chain in chains

Oh, wait

the second chain is [','] when findall'd which is only [pair] and that gets appended to chains as a dyad because of ð

the third chain is '€H'

because start + word

... wait hold on

word is )H, right?

@hyper-neutrino oh hang on, no I've got it

is the third chain €)H ???

Yes, but ) is ignored

€ pops , and pushes ,€ to chain, then H is parsed as a monad and pushed to chain, which is then appended to chains

i suppose this doesn't explain anything cuz ) isn't defined otherwise

So the second chain is [pair-each, halve]

wait shit i'm stupid

okay this makes sense now

ah this makes sense now

so it calls ,<each>H on R on (input)

and the latter link ,<each>H is forced monadic because of mu

and the dyad separator pushed the , as a dyad so that's why there's no empty 2-chain

Basically, what happens in the ,)H is that H operates on the range, not on the left argument, so it halves each element in the range, then that is passed to the , chain

that makes sense

because ,€H is the 2,1 subchain in a forced monadic chain

and the forced monadic chain accepts the result of the above chain which is the range

Yeah

nice :D

But it contradicts how Rð,µH chains

So µ != µ€ in chaining patterns

well that makes sense

because € pops a chain if it's right next to a chain separator which it always is with )

It makes sense according to the implementation, but I'd expect the chaining rules to take priority

don't chaining rules only happen after parsing though?

like the parser's job is to just produce a list of links, each of which is a list of chains

and after that's done, the evaluator will walk down each link and do dynamic grouping based on link arity or whatever

I mean, I guess :P

It just ruins good chain usage, forcing additional links

true

i guess like you said

Feels like being punished for doing the "proper" thing :P

based on the implementation this makes perfect sense

but based on the design philosophy it feels like it's not doing what you want :p

see this is why i didn't implement chain separators at all and just used subfunctions

Chains and chain separators seem to be a unique thing to Jelly tbh

yeah

it's golfier but if you have bracket autocompletion like i do it doesn't really matter in most shorter things

and honestly using chain separators for really long solutions sounds like hell

It can be really complicated keeping track of the chains, but it saves hella bytes over having new links if it's too long to use the "last N links" quicks

yeah definitely

) is really nice for shorter and TBH more "trivial" like 1|02|20-chain type answers

@cairdcoinheringaahing do you think +) on [1, 2, 3] and [4, 5, 6] should give [2, 4, 6] or [[5, 6, 7], [6, 7, 8], [7, 8, 9]] ?

The first, but ð+) should be the latter

or rather, if it were changed to work as the second (so basically, it is variadic and uses the link's arity) do you think it would help with golfing

I think so, as it would save on using ç€ a decent amount

oh i guess another thing about chain separators is it avoids wasting byte allocation

like there are four separators (if you don't count ))

but with bracketing subfuncs you'd need two per arity/config

Plus potentially more to indicate arity/argument order

yeah