# Is a code golfing library legitimate? [duplicate]

My read on the current state of meta.CG opinion is that the use of libraries is acceptable and that the library call should count in the character count:

Use of built-in functions and libraries in Code Golfs

Using libraries in solutions

And from this discussion I conclude that there isn't really a consensus around whether or not languages specifically built for golfing should be allowed (but GolfScript is used to answer questions all the time, so perhaps that's as definitive an answer as one can get):

What programming language should we consider for the code-golf solution ?

Would the use of a code golfing library therefore be acceptable? I'm thinking of a library that:

• Has a one-letter name (so calling it would require something like library(g) -- 10 characters)
• Shortens commonly used function names (print to p, etc.)
• Curries a few functions so that defaults agree with their common usage in golfing
• Loads a few commonly used libraries (so commonly used that they are pretty much part of the canon in answering questions on SO)
• Would be a general-purpose library (e.g. it wouldn't be updated just to solve a particular problem)

It seems to me that:

• You incur a fairly major upfront cost (10 or so characters) and get a benefit down the road. Not unlike the common golfing trick of shortening functions that you use twice (e.g. l=length;l(a);l(b))
• For short problems this would be at best a slight advantage and for long ones it would be a huge advantage.
• This may help to even out the cross-language differences in function lengths

Sounds like a reasonable compromise to me, but curious what others think.

• From my R-non-user point of view, this reads like a "R doesn't win often enough, can we devise a library from the ground up, we'll publish it and make it well-known enough so we can reference it and win" from disgruntled R users. But maybe I'm missing some background.
– J B
Dec 8, 2011 at 21:53
• @JB - It's a rather accurate observation. Doesn't diminish the need for such a package though ;-) Dec 8, 2011 at 23:09
• @JB I'm clearly coming at this from an R perspective since that's what I know, but I don't think the problem is limited to R. Dec 9, 2011 at 2:58
• The discussion about the legitimacy of GolfScript is actually to be found here Dec 9, 2011 at 12:23

I believe that it shouldn't be a problem, as long as:

1. using the library does not violate the rules of the question
2. you are using a version that was released before the question was posted no longer relevant due to changes in site rules

It's one thing to use standard libraries and another to roll your own. I think it risks turning into a game of "Who can write the most advantageous library?" rather than "Who can find a devious way to use the language?"

(Which isn't to say I don't understand the desire: I often find myself wishing that GolfScript had w as an alias for while or b as an alias for base, and that digits weren't valid in identifiers - but I stick to muttering about it rather than forking the language).

• +1 I have also muttered about # being wasted as far as golfing goes Jan 24, 2012 at 20:25
• Resurrecting the dead here, but if we allow people to construct their own languages and use those (if the language was created before the question date), then we should certainly allow people to create their own libraries under the same restrictions. Jun 15, 2015 at 18:47

IMO the point of golfing is perverting existing languages that were not designed with golfing in mind. Designing a golf library is akin to altering the language with golfing in mind. Which defeats the point.

My opinion makes me pro-J and kinda anti-Golfscript. (well, GS is nice...)

It's been many years since this quesion was asked (and was active). Today, I see some users using pretty much personal golfing languages, and besides the rule of not using languages/language features that didn't exist before the question was asked, it seems everyone is fine with it.

I'm fine with it too. However, I think that to be consistent, we should also then allow custom libraries, as long as they too existed before the challenge in question, and as long as they're "declared". For instance, whether you answer with

or

# VotroC, 32 bytes

shouldn't matter. Here, I imagine "VotroC" as a custom golfing language implemented as a C header file of macro definitions, existing before the challenge question of course.

If submitting as the former, I think you should even be allowed to leave out the #include "votroc.h" or skip it in your byte count, since you could easily work around it by declaring your library a language and submit it as the latter.

Writing macro collections/EDSLs for golfing isn't really against the spirit of golfing more than golfing languages are, IMO. It's really the same thing. So they should "compete" on equal terms.

• I agree with this to an extent. If its a standard library, however, then I'd consider it to be the same language Nov 15, 2016 at 20:16

I think it's a great idea. I have given this some thought, and I have some ideas:

1 - Naming. G might be less problematic than g (a more common local variable).

# Normal way, Not efficient
library(G)

# Golfed way, Much more efficient :)
G::.


3 - How do we accomplish that? Well, in the golf package we define "." using an active binding:

makeActiveBinding(".", function(x) require(G), golfEnv)


4 - Functions to put into it: Well, plenty of candidates, but something to get input efficiently and output efficiently seem like good candidates. I'm often annoyed that paste and cat always have sep=" " when I want sep=""...

I found this question hoping to propose the same thing. Since the [tips] questions are all CW, it seems convenient to have one answer in the [tips] question for each language for a collaborative library. If you keep using the same idiom and abbreviations, add them to the KB, and save yourself X chars next time.

In my PS answers, I find I keep needing a control structure that combines for and forall. I'd love to lose some of the overhead.

To use it in a golf answer, one would have to cite a specific revision dated earlier than the question (no ex-post-facto).