This is mostly specific to Vyxal, but I've worded the language so that any hypothetical stack language could utilise this

Say you have a stack-based language which supports function objects on the stack.

And say that there's no way to take function objects on STDIN - they have to be placed in the header.

But say that there's a way to add function objects to STDIN via a built-in - it takes a function as its argument and injects it into where STDIN is coming from.

Is this a valid black-box function input format for challenges that require functions as input?

  • 2
    \$\begingroup\$ Surely if there are functions in this hypothetical language, it would be easiest to just make the submission a function rather than a full program? \$\endgroup\$
    – Jo King Mod
    Sep 5, 2022 at 2:22
  • \$\begingroup\$ @JoKing yes you could but the point of the post is that it makes it shorter to provide it via input \$\endgroup\$
    – naffetS
    Sep 5, 2022 at 3:29

3 Answers 3


A Hard "Maybe"

There are two cases here, namely a function submission and a program submission. For both, it's important to make a distinction between the actual STDIN stream provided to the program and the "internal STDIN"/logical input list which the program can manipulate.

Program submission: No

This would be equivalent to taking input through direct source code insertion. If it is impossible to input a function through the real STDIN to the program, that's that.

Function submission: Depends

The issue with function submissions is that they have to be reusable. A function that can be run once has to be able to run twice. This excludes them from using program styles of input for various reasons which I intuitively understand but can't put into words too well, but in the case of an "internal STDIN" input list which is really just a piece of global state which the program can manipulate, it might be permissible--but I'm tempted to say it's tantamount to taking them under a predetermined name when passing directly is possible.


Yes, but you must count the code to append to STDIN

This seems like the most consistent method with our existing rules. Given that languages can already assume function objects to be pre-defined/on the stack, I don't think it is necessary, or potentially even fair, to allow such languages to ignore the code required to transform the input from one format into an "easier to use" format.



As the function is in the header anyway, appending it to STDIN is basically just turning the header field into an alternative input field.

Only functions should be given in this way - strings, lists and numbers should all be taken in original STDIN.

This helps languages which otherwise have to add boilerplate bytes to their code to even come close to enjoying the benefits of things like implicit input, input cycling and more.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .