Is a code golfing library legitimate? [duplicate]

Question

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.

Answer 1

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
3. that version of the library is freely available as of when you are posting your answer (please provide a link in your answer as well)

Answer 2

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).

Answer 3

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...)

Answer 4

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

C with Votrob's Magical Golfing Macro library, 32 bytes

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.

Answer 5

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).

2 - Loading the library:

# 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=""...

Answer 6

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).