Open met4000 opened 4 years ago
This has been suggested a couple of times already (#747, #194). The idea itself sounds fine, but no one has implemented it yet though.
Ah, my bad; when I was looking through the list of feature requests I didn't notice them because they used different keywords. You can close this; it directly duplicates both of those feature requests.
Issue type:
(Note that while I only refer to partial application in the description/explanation, I am also talking about
pipe
ing; not justapply
ing)Short Description:
Allow partial application of operations/operators through use of placeholders.
(Not-So-Short) Explanation:
Regardless of possible implementations: the feature request is to allow 'blank variable cards' to act as placeholders, allowing some inputs for operations/operators to remain 'un-applied', resulting in an operator with the 'un-applied' inputs and returning the original output.
Some examples (and possible implementation, using blank variable cards in the operation interface of the variable programmer): In example1, a 'blank variable card' and 'integer constant 64' are applied to the 'relational less than' operation. This would result in operator
op1
, which acts as if defined by the Haskell code:In example2, a
blank variable card
is used when applying values to an operator with theapply2
operation. In this case,op2
acts as if defined by:In example3, two
blank variable card
s and aboolean constant false
are applied to theNBT.with_boolean
operation; only the last input is applied.op3
acts as if defined by:(end of description)
This feature essentially makes InDy no longer a "pointfree" language, which makes it much easier, simpler, and intuitive for players to make functions that are currently more 'complex' to achieve. While the implementation I suggested above doesn't particularly allow a parallel implementation for
pipe
as well asapply
, this does not have to be the only implementation. Another possibility that supports having bothapply
andpipe
could be an interface (similar to or within the variable programmer) that accepts an operator and creates a box/slot for each respective input of the operator. The player can then place in a value/operator to apply/pipe it into that respective input. The interface would then program a variable card to be an operator that accepts the respective remainingun-applied
/un-piped
inputs and returns the output of the operator. For example: (Whereblank
,string constant
, andblank
are applied to the input operatorInputOp
, which is theNBT.boolean_with
operator of signatureNBT -> String -> Boolean -> NBT
, and producesOutputOp
of signatureNBT -> Boolean -> NBT
)As I've described just the behaviours of applying so far; piping would work by substituting the piped input with the input(s) of the piped operator. For example, piping
arithmeticAddition
with signatureNumberA -> NumberB -> Number
into the third input ofNBT.with_integer
with signatureNBT -> String -> Integer -> NBT
would make an operator with signatureNBT -> String -> NumberA -> NumberB -> NBT
.I'm not sure if this should be treated as two feature requests (one for partial applying, and one for 'partial piping'), especially as I think the piping behaviour is much harder to implement.
TL;DR: Allow partial application/piping of operations/operators through use of placeholders. This makes it easier and more intuitive to make 'complex' functions. A possible implementation would be using blank variable cards in the variable programmer to represent 'un-applied'/'un-piped' inputs. See above for example behaviours.
(link to discord conversation)