# Function that requires different syntax to “call”

Is it allowed to submit a Python solution like the below:

{"a":"b"}


if the challenge is to output b if the input is a, and error otherwise? I could claim, "It is an anonymous function, it just requires a different syntax:"

f = {"a":"b"}
f[input()]


Is this a valid submission?

• Regardless of syntax, in Python, f would not be a function, it would be a dictionary. Even the syntax used to call f is not the way a function is called in Python, which would be f(x) not f[x]. – miles Jun 6 '16 at 4:07
• I'd argue that, in this situation, the proper corresponding submission is {"a":"b"}.__getitem__. – Sp3000 Jun 6 '16 at 9:39
• I would say that if {"a":"b"} has the correct behavior as the submission for some challenge, it's a bad challenge. – John Dvorak Jun 15 '16 at 7:39

## It's not a function (at least in this case)

No, it shouldn't be allowed, at least not as a "function".

Your submission is a hashmap, which isn't a function. Last time I checked I couldn't perform primality checking by accessing a hashmap (without hardcoding every number which is disallowed by this loophole).

@Mego stated that python's 'collections.defaultdict', can perform primality checking, and I'm guessing can add two numbers, and so it fulfills the definition of a function. But the again, python has functions, a hashmap simply is not a function.

Languages which have functions, those functions are the only functions. Anything else is not a function and is viable to abuse.

E.g. If "functions that get called in a different way", were allowed. Well, guess what? I have a solution that's called through eval! Huh,... I also have a function that's called through prompt().split("").map((l,i,a)=><CODE HERE>).

So here's my stance:

If it's not a function, it's not a function

Pretty straightforward, eh?

• With a collections.defaultdict, you can cleverly define the default value to calculate the primality. Not that it'd be shorter than a real function, but the point stands. – user45941 Jun 7 '16 at 0:59
• Just because this doesn't work for one specific problem doesn't mean it is invalid all the time. -1 – Rɪᴋᴇʀ Jun 7 '16 at 20:03
• @EᴀsᴛᴇʀʟʏIʀᴋ updated to address Mego, and your points – Downgoat Jun 8 '16 at 0:35
• @Mego I'm not so sure about the defaultdict point - if you define it so that the default value calculates primality then the submission should be the factory function you gave the defaultdict, not the dict itself surely? – Sp3000 Jun 8 '16 at 2:28
• @Sp3000 I never said it would be the shortest submission. In fact, I said the exact opposite in my first comment. I'm just saying it would be valid. – user45941 Jun 8 '16 at 3:05
• I think this logic is faulty. We require languages to do primality testing, not functions. – Nathan Merrill Jun 10 '16 at 2:44
• @NathanMerrill if we allow functions as submissions, why should they not fulfill the definition of a programming language? – Downgoat Jun 10 '16 at 3:29
• (at least in this cae) should be case. – Erik the Outgolfer Jun 10 '16 at 8:00
• Regardless of hypotheticals, we currently don't enforce functions to be capable of primality checking, and never have. If we are going to make that a requirement of functions, then it needs to be on the right meta post – Nathan Merrill Jun 10 '16 at 16:06
• @Mego I don't see how that's relevant. we're talking about the definition of a function. in your given hypothetical language, your "functions" are really operators. C++ and Python are not your hypothetical language so I don't see how they're relevant. Either way: how would you define a function in your hypothetical language. Shouldn't a function be allowed to consist of more than one operator? otherwise I fail to see how a function would be distinct from just the individual operator – Downgoat Jun 11 '16 at 16:46
• In Ruby, you have methods (created in the current context by def and called with parentheses), procedures/lambdas (called with .call , square brackets or with .(...)) and blocks (proc literals that can be passed as implicit arguments to functions and called with yield). Surely at least the first two should be allowed? – John Dvorak Jun 14 '16 at 5:34
• Let's say that a language doesn't distinguish between functions and strings, and to call a function you eval it. Would a string be a legal submission in that case? Why not in other languages then? – John Dvorak Jun 14 '16 at 5:40
• I have two objects, foo and bar. For both of them, x[2] returns true and x["anything else"] returns false. If we go by labels assigned by the language creators, only one of them is a valid submission in Ruby. Isn't it weird? – John Dvorak Jun 14 '16 at 5:42
• So, why should an evaluable string be a valid submission in my Golfscript variant (where you set up the arguments on the stack and then eval the string) but not in Javascript (where you set up some local variables and then eval the string)? Golfscript does have a separate function type, but the only observable difference is during addition, where function addition separates tokens automatically while string addition does not. My golfscript variant removes strings and functions entirely (because functions are just strings with special addition and strings are just arrays with special printing). – John Dvorak Jun 14 '16 at 6:04
• And no, the difference is not because of how you pass arguments. regcall is not just a valid calling convention in c/assembly, but it's the fastest one available, and the only possibility in INTERCAL. – John Dvorak Jun 14 '16 at 6:06

It's not a function in Python (since Python has functions, and that is objectively not a function), so you couldn't claim it is one.

However, in the mathematical sense, a dict (or any other mapping type) is a function (or close enough for our standards). Python dicts define a domain (with no repeated values), a codomain (with possibly repeated values), and a mapping from domain values to codomain values. That is exactly the definition of a function in mathematics. Specifically, it functions identically to a partial function, in which not all of the elements of the domain (i.e. every hashable Python object) have a mapping to elements of the codomain (though using collections.defaultdict or the default parameter of dict.get make it a total function).

Furthermore, they fulfill our requirements for function submissions - they are consistent and reusable.

As such, it is my opinion that mapping objects (such as Python dicts, C++ std::maps, and Java java.util.HashMaps) are valid function submissions.

• What about an array or a list (provided that the "input" is an integer)? Many challenges are like "return the nth value that...", so may I simply return an array/list of all values and omit the indexing? E.g. for this challenge the last line of my answer can be shortened to g"1", saving 4 bytes. – nimi Jun 6 '16 at 18:59
• @nimi Sure, an array or list is also a mapping type (with the domain being integers). – user45941 Jun 6 '16 at 20:39
• then I don't think it's a good idea to allow "mapping objects" as valid functions submissions. – nimi Jun 6 '16 at 21:28
• @nimi Then we need a stricter definition of function that arrays and dictionaries don't satisfy, because they satisfy all of our requirements currently. I don't see a problem with allowing them. – user45941 Jun 6 '16 at 21:29
• @Upgoat There's no contradiction. I'm saying it's not a function in the context of the language, but it fulfills our requirements for functions. – user45941 Jun 7 '16 at 0:57
• There's a definite contradiction. You say that it fulfils our requirements for function submissions, but the post you link to support that says "if it's blatantly obvious it's not a function, it's not a function." and "Python has functions. Anything else is not a function" – Peter Taylor Jun 7 '16 at 10:37
• @PeterTaylor I linked to the question, not the answer. None of the answers have sufficient votes to be considered consensus. The general idea that all of the votes-up answers share is that the code needs to be reusable, consistent, and independent. Dicts and lists satisfy those requirements. – user45941 Jun 7 '16 at 18:11
• Should there be a limit to the complexity of the "mapping object" and/or "access fucntion"? If so, where's the line? Some examples: a) simple arrays, accessed with bracket syntax a[i] b) association lists, i.e. lists of key-value pairs, accessed via a function (Lisp: assoc, Haskell: lookup, etc.) c) binary search trees, tries, etc. which have complex access functions (remember: code for retrieving elements is not part of the solution and is not included in the byte count) ... – nimi Jun 11 '16 at 16:16
• ... d) anything from above but with additional data stored in the objects, say arrays of triples where the data for i is stored in the ith array element and 2nd element of the triple (example: given i, return i squared: answer: [(0,1,0),(0,4,5),(3,9,8),(0,16,33)...]). Any difference between built-in and user provided "mapping objects"? – nimi Jun 11 '16 at 16:17
• @nimi What would be the purpose of limiting the complexity? If it maps inputs to outputs in such a manner that each input has exactly one output, it's a function. How it does the mapping is irrelevant. – user45941 Jun 11 '16 at 16:22
• Whether you think this specific example prssentd by the OP should be valid is another thing, but this opens up a whole new area, available to abuse. I could say my js solution is prompt()-2 and it's run through eval. There's no point in allowing what's not a function as a function as this could be abused to such a high extent – Downgoat Jun 11 '16 at 16:56
• @Upgoat That's still abusing the loophole I linked. – user45941 Jun 11 '16 at 17:13
• @Upgoat As our policies currently stand, mapping objects satisfy all of our requirements for functions. If you don't want them to be valid, you need a stronger argument than "they're not functions" or "look at how you can abuse these already-banned loopholes". – user45941 Jun 11 '16 at 17:18
• @nimi You're not getting it. I detailed exactly why they are functions in the mathematical sense, and satisfy all of our requirements for functions. If you don't believe they should be acceptable submissions, you must have a stricter idea of what constitutes a function than our current consensus. – user45941 Jun 12 '16 at 8:45

Just because you can claim something, doesn't make you right. If you did claim that this was an anonymous function then you would be objectively wrong and your answer would quickly receive a lot of downvotes and votes for deletion as low quality.

• This doesn't answer this question. Is it allowed, or not in your opinion? You're just saying it is not a function. – NoOneIsHere Jun 6 '16 at 18:59
• @NoOneIsHere By saying it isn't a function, it is implied that it is a code snippet, and we already have a policy regarding this :) – Katenkyo Jun 7 '16 at 6:56
• @NoOneIsHere, the wording of the question seems to be asking whether it is allowed to claim that "This is a function". Claiming that behaviour is justified because X where X is objectively false is (or should be) unacceptable behaviour in any community. To be honest, on revisiting the question I've downvoted because a) meta is for discussing real issues: this seems very artificial and can only be relevant in the context of a really poor quality question on main; b) this is a code golf and challenge community, not a rules-lawyer community. – Peter Taylor Jun 7 '16 at 7:38
• This is asking about our standard for our community. – noɥʇʎԀʎzɐɹƆ Jun 11 '16 at 14:46