Is there a rationale, beyond historical accident, why some Mathematica option values are strings, while others are symbols?

It seems natural that some value spaces, e.g. named color schemes, are so numerous and only applicable to ColorData, e.g. ColorData["HTML"] and so should be strings.

On the other hand wouldn't it make more sense if "XAxis" in PairedHistogram[..., BarOrigin -> "XAxis"] were a built in symbol to be shared as an option value across composite graphics functions?

  • 1
    $\begingroup$ Related question $\endgroup$ – Leonid Shifrin Mar 27 '13 at 21:33
  • 6
    $\begingroup$ Btw, strings almost always work even when the option is a symbol $\endgroup$ – Rojo Aug 3 '14 at 3:05

In older versions (5 and before), most option names were symbols. It's since about version 6 that string option names have proliferated.

I think that the reason is to avoid cluttering the name space. Once you introduce a new name, it won't be available for package authors to use for other purposes (in particular, function names). At least not without shadowing the built-in one. Considering the huge number of options introduced since version 6, I think it was a good decision to use strings for most of them.

Every time a new symbol is introduced in a new version, there's a chance it will break some third party package. Using strings reduces the likelihood of this happening. Strings, unlike symbols, are not part of a namespace (so there's no shadowing issue) and can't have associated definitions (so breakage due to conflict is impossible).

  • 5
    $\begingroup$ +1. I agree with your reasoning, I also think it is namespace-related. This does however come at a price - string options are much less discoverable in the documentation and otherwise. $\endgroup$ – Leonid Shifrin Mar 27 '13 at 21:41
  • 3
    $\begingroup$ @Leonid Yes, that is the disadvantage. Auto-completion doesn't work. Theoretically this could be remedied by improving auto-completion in the front end ... $\endgroup$ – Szabolcs Mar 27 '13 at 21:41
  • $\begingroup$ Szabolcs' answer makes sense. But also thanks for pointing out documentation - which is often a struggle. One would think keyword registration and search to be entirely feasible. $\endgroup$ – alancalvitti Mar 27 '13 at 21:43
  • $\begingroup$ Talking about documentation and options, I still couldn't figure out how to use the "EdgeLayout" suboption of GraphLayout ... see here $\endgroup$ – Szabolcs Mar 27 '13 at 21:44
  • $\begingroup$ I also get Graph[<<4>>,<<3>>] with EdgeLayout in MMA9. Have you filed a note w/ tech support? $\endgroup$ – alancalvitti Mar 27 '13 at 22:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.