8
$\begingroup$

In my package, I use some of the built-in Mathematica symbols in non-canonical ways. Right now, I use them as Options or OptionValues to certain package symbols. Therefore, I modified the ::usage of the built-in symbols to include information about how those symbols are used in the package.

For example the package has a function FoldDistribution and I've given it an option Integer that can be True or False. So I modified the ::usage as follows:

Unprotect[Integer]

Integer::usage = "Integer is the head used for integer.
Integer is an option to FoldDistribution."

Protect[Integer]

Giving ? Integer:

enter image description here

So far, things look like they're going ok, and nothing fundamentally wrong seems to be happening with how Mathematica operates. Question: should I be worried about anything bad happening down the line? Is it recommended not to use built-in symbols in unintended ways? And what about changing their usage messages?

Improve this question
$\endgroup$
7
  • 5
    $\begingroup$ Built-ins are not bound by the same rules as top-level definitions. Do not be surprised if your modifications magically disappear at any time during a session, or are accepted in some contexts but ignored in others. Personally, I would never do this in a package. $\endgroup$
    – Oleksandr R.
    Dec 20, 2015 at 22:41
  • 3
    $\begingroup$ I also think this might be error prone. But at a design level, why do you have a need to use that particular name for an option? And if it is absolutely the only name that makes sense, why not go with the string "Integer"? $\endgroup$
    – Daniel Lichtblau
    Dec 20, 2015 at 23:51
  • 3
    $\begingroup$ I second the concerns of others. I would never do this. Use your own names or strings, as others have suggested. Changing properties of built-in symbols have an effect on entire system, and you can't know all the consequences. There have been multiple discussions about this here on the site, notably this one, and also here. You can seldom win big by changing built-ins, but it is very easy to mess things up badly. $\endgroup$
    – Leonid Shifrin
    Dec 21, 2015 at 8:12
  • $\begingroup$ @LeonidShifrin Thanks. The answer by Istvan seems to disagree with your opinion. Perhaps I should have mentioned that the only way I intend to use the symbols are as option names. I don't modify their definitions. Would this be safe? Or would still advise against it? $\endgroup$
    – QuantumDot
    Dec 21, 2015 at 21:00
  • 2
    $\begingroup$ @IstvánZachar I would still not do this. I do sometimes use built-ins as option names, but usually as a short-cut, and I never document that (so never really modify those symbols' global properties). And I would never do anything like that in the user-facing code. Any global modification you make to a built-in symbol, can have unanticipated consequences. And the more common the symbol is, the bigger are the chances to mess something up. Given other possibilities (your own names or strings), I just don't see that the the gain is worth the risk. $\endgroup$
    – Leonid Shifrin
    Dec 22, 2015 at 5:16

1 Answer 1

Reset to default
4
$\begingroup$

You don't have to unprotect system symbols to attach messages to them. The usual way (used throughout built-in packages) is the following way:

Attributes[Dot]
Message[Dot::usage]

Mathematica graphics

Dot::usage = If[ValueQ[Dot::usage], Dot::usage <> "\n" <> #, #] &@ "MyFunction[..., Dot -> ...] does ...";
Message[Dot::usage]

As long as you use the symbol only as an inert option name I think this is a pretty safe method, as you do not even unprotect it so you cannot mess up its definition.

Note, that if you call the attaching code a second time, you will have a redundant message: make sure that you package this so that it is only called once. The ValueQ thing is only needed if you attach to a symbol that you are not sure is defined in another package, not being a system symbol.

Mathematica graphics

Improve this answer
$\endgroup$
3
  • $\begingroup$ It's good to know I don't need to unprotect the system symbol to attach messages to them. And yes, it is true the only way I'm using these symbols are as option names. So I suppose you would disagree with the comments under the original question provided I only use these symbols as options names? $\endgroup$
    – QuantumDot
    Dec 21, 2015 at 20:58
  • $\begingroup$ @QuantumDot Exactly. I'm using this kind of extension since years and without any problem. I do not like to clutter the namespace with extra symbolnames, and on top of that, I do not like to use MyIntegrate as an option name when Integrate describes the best what my option does. Let's be honest, Stephen Wolfram really put a lot of thought into naming things and he did a quite good job. On the other hand, he really forced us to come up with convoluted names if we do not want interference. $\endgroup$
    – István Zachar
    Dec 21, 2015 at 21:31
  • $\begingroup$ I will accept this answer, also bearing in mind the warnings given by Leonid and Daniel as comments to the question. $\endgroup$
    – QuantumDot
    Dec 26, 2015 at 22:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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