You have a nice interface for creating normal variables, but when you want to start using Operators, you end up stuck in the Operator screen for most of it, which is harder to use and doesn't look as good. I'd much rather just use the regular interface to create the operators. Seeing the input types and output types without having to hover over them would be very helpful as well.

A Pattern Variable Card sounds awesome to say the least. But I suggest "Placeholder Card" instead. if they're an upgrade to a variable card, but only used to essentially hold the place of a variable card, then they're not a type of variable cards anymore in my opinion, and it'd have more to do with placeholding than with patterns.

That's definitely possible, and shouldn't be too hard to implement.

I thought of an intuitive way to do this: if you use an operator but don't give it any operands, the operator itself would be what gets written to the variable card. You could also reduce the need for "apply" (and "flip" too if you wanted to get really fancy) by writing out a partially applied operator if some but not all of the operands are given.

@josephcsible While that would be useful for power-users, it may be very confusion for new(er) players that don't know yet how everything works. Perhaps some kind of toggle button to enable that feature could be useful. Will have to experiment with that a bit.

After struggling with flip and apply, which I feel needlessly complicates and bloats the system, I had a thought that builds off of @josephcsible 's suggestion. How about using a blank variable card to denote the desire to create an operator, i.e., put a blank variable card in the spot that you want to be an operator argument. You could do some sort of visual notice when someone does this to let them know it is and advanced usage mode. This would eliminate the need for flip and possibly apply, though it may still be needed to do some more advanced operators.

@xannor The problem with using blank variable cards like that is that they're already defined to mean "true" in a lot of places, so you'd have ambiguity as to what you meant when you use one.

@josephcsible do you mean in the code? If I put a blank variable card in, for example the &&, it is not a valid operation so I cannot create a new variable from it. Do you have an example where it currently be used like this because this is definitely something I was not aware of, and unsure how useful it is as "blank" or undefined should never mean true.

If you put them directly in one of the writers, or in an Integrated Tunnels importer/exporter, then they act like "true". It's useful as a shortcut to use Integrated Tunnels as a simple pipe, for example.

Ok, I am not sure why that shortcut is necessary as opposed to creating a boolean true variable, but that would not interfere with using a blank variable in the programmer to mark an "argument" for an operator. Plus I was not implying that it should be recorded as a blank, just as a method to tell the programmer what to create, once the operator is created it would be the same as an any other "applied" or piped operator and not actually use the blank variables.

It's definitely technically possible to do what you want. If @rubensworks is okay with the possibility for confusion, I can try to PR it.

Ok, I am not sure why that shortcut is necessary as opposed to creating a boolean true variable

People like to be lazy, including myself :-)

It's definitely technically possible to do what you want. If @rubensworks is okay with the possibility for confusion, I can try to PR it.

I think we can get the best of both worlds. What if instead of using blank variable cards, we use a new item for this that is created with a blank variable card (Pattern Variable Card)?

@rubensworks some languages that rely on libraries to become vaguely functional use placeholder functions when currying. However maybe to make things easier creating partials in the short term you could have ‘applyLeft’ that is a reference to ‘apply’ and ‘applyRight’ that removes the need to flip in most cases.