5
\$\begingroup\$

Prompted by this comment.


The scoring of optional flags passed to compilers/interpreters has already been handled here and here. However there is another case of one more level of indirection. Specifically compilers/interpreters for some languages may themselves be built with extra options to enable/disable certain optional features. These options may be passed to the ./configure script run before building the given compiler/interpreter, assuming the common ./configure && make && make install build paradigm.

For example, the bash shell (interpreter for the bash shell language) has quite a few of these options, for example:

--enable-extended-glob-default
--enable-net-redirections
  • The first is disabled by default, that is we need to pass --enable-extended-glob-default to the ./configure script to enable it in a new bash build.
  • The second is enabled by default; that is to access this this feature, then no defaults need to be changed. However, if we need to disable it for some reason, then we need to pass --disable-net-redirections to the configure script.

In the case any of these optional are needed, how should these extra build options be scored?

I've added some answers. With @MartinBüttner's encouragement I've deleted some of these answers to allow more community input and not swing the discussion with my own bias. Having said that, some other suggestions for possible solutions are:

  • Only allow bone-stock builds of the compiler/interpreter
  • Only allow bone-stock builds of the compiler/interpreter with all optional features turned off (even defaults)
  • Allow any compiler/interpreter build options for free
  • Assume all optional features turned off (even defaults) and add option length to score for any optional features used (even defaults)

Vote and add your own as you see appropriate. Please don't be shy about downvoting answers you think are no good.

\$\endgroup\$
  • \$\begingroup\$ Robert Cartaino made a good point against using meta as a poll where you post all the answers yourself. (On top of the fact that it sort of pre-empts decent arguments for the positions you don't support yourself it will also raise the problem of implicit up/downvotes on your own answers.) \$\endgroup\$ – Martin Ender Oct 27 '15 at 18:26
  • \$\begingroup\$ Hi @MartinBüttner, that point has some merit. I wanted to add these answers (perhaps I went overboard on this one) just as suggestions of the possible solutions. I will happily delete all these answers (especially those with no votes), but would it be OK to note these possible solutions in the question itself? \$\endgroup\$ – Digital Trauma Oct 27 '15 at 18:52
  • \$\begingroup\$ Sure, that seems reasonable. \$\endgroup\$ – Martin Ender Oct 27 '15 at 19:04
7
\$\begingroup\$

I think it's hard to properly define what "default" means in a few cases. Take php for example: it has a pretty huge default library, but most of it you can only access if the appropriate module is built. The list of "default" modules is usually not set in stone, different distros think differently on what should be part of php by default and what not: should we only limit it to the language that was meant by the langauge maintainers, if that would mean most common compiled implementations (e.g. actual binaries you get from the distros) are out of the question? Or should we limit to language maintainer defaults + anything that it is in at least one usable binary that you can find? What about linux distros, like gentoo, where you can fine tune what gets built?

I think it is much easier to just allow any of the compiler flags for free. A compiler / interpreter built with different flags, is still just another compiler / interpreter (we can probably argue about whether the actual binary that was built is "existing" before or after the challenge was posted, and whether a solution using some non standard flags is using a loophole or not, but I'd say if the source code is there before the challenge, then it's okay).

Is it something that could potentially be abused? Yes, as @Doorknob said, one would just create a weird language that only has compiler flags (I guess they would be in the family of languages). But I think the community is good enough to downvote answers like this, while in no way limiting actual creative use for language features that are there, but just not widely used (like the one that started this discussion in the first place).

Actually: We could just use the definition of the languages to create a rule around compiler flags: if the compiler flags make the language an language, then they count as 1 byte/character per byte/character in the flag. Otherwise they are free. This definition would hopefully discourage most of the loophole usage, while still retaining the creative approach. This would also make it a properly defined rule around compiler flags (for anyone who dislikes rules that are not set in stone)

\$\endgroup\$
2
\$\begingroup\$

Anything that uses the default compiler/interpreter build should not incur any extra scoring. That is, since the --enable-net-redirections bash build option is enabled by default, it does not need to be passed, and should not incur any extra scoring.

However for features that are not enabled by default such as --enable-extended-glob-default for bash, then if you are using a build of bash with this feature enabled at build time, then the length of the command-line option should be added to your score - in this case 30 bytes.

\$\endgroup\$
2
\$\begingroup\$

Note this is the same as this answer with one important distinction in scoring calculation.


Anything that uses the default compiler/interpreter build should not incur any extra scoring. That is, since the --enable-net-redirections bash build option is enabled by default, it does not need to be passed, and should not incur any extra scoring.

However for features that are not enabled by default such as --enable-extended-glob-default for bash, then if you are using a build of bash with this feature enabled at build time, some extra score should be added.

30 extra points for --enable-extended-glob-default seems like a steep penalty. Instead, each extra option enabled will incur 1 extra point.

\$\endgroup\$
  • 3
    \$\begingroup\$ This can be abused by creating a "language" programmed entirely in compiler flags, scoring 1 on every single challenge. \$\endgroup\$ – Doorknob Oct 27 '15 at 21:28
  • \$\begingroup\$ I think we should also define what is "enabled by default", as especially in the linux world different distros use different defaults (and we're not even talking gentoo style flags). There might be even some cases where the "default by compiler maintainer" is not even the default on any of the mainstream linux distros \$\endgroup\$ – SztupY Oct 28 '15 at 11:47

You must log in to answer this question.

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