I want to hide Module's symbol names (such as x$23118) from the end user of a package I am developing. To give some context: The user inputs a equation into a function that holds its arguments and replaces all occouring symbols via Module to protect the user from stray definitions. The output of the function, however, should still display the original symbol names to not confuse the user and to improve readability (x is a lot nicer than x$23118, especially if the equation has more than one independent variable).

The function I wrote for localizing the symbols and keeping their initial names is

SetAttributes[localize, HoldAll];    
localize[x_] := Interpretation[SymbolName@Unevaluated@x, Module[{x}, x]]

which seems to work for protecting from stray definitions

x = 1;
localize@x (*outputs x, and upon evaluating the output cell again yields x$23553 *)

What makes me question this approach is the following, try:

{localize@x, localize@x} // Union (* outputs {x} 
and upon evaluating the output cell again yields {x$23554}  *)

and compare with

{Module[{x}, x], Module[{x}, x]} // Union (* yields {x$23118, x$23119}*)

From {localize@x, localize@x} // Union I expected an output cell containing {x,x} that upon repeated evaluation would evaluate to what {Module[{x}, x], Module[{x}, x]} // Union directly gave.

In my use case the behavior shown is actually beneficial but I would like to:

  1. Understand why the behavior is the way it is
  2. Know if this method is safe to use for localizing symbols
  • $\begingroup$ The same questions of course apply for something like localize[x : {__}] := Interpretation[SymbolName /@ Unevaluated /@ Unevaluated@x, Module[x, x]] for localizing multiple symbols at once $\endgroup$ – Sascha Nov 10 '16 at 9:36
  • $\begingroup$ Can you explain why you want this? It seems like a really really awful idea to me. But I don't know what you want to use it for so maybe it is reasonable ... I just can't imagine how though. Why awful? It makes one thing look like another, there will be confusion. Interpretation only works in notebooks, and only interacts with notebooks. The output still has head Interpretation and can't be computed with. Interesting things only happen when you copy and paste the output or re-evaluate the output cell, as it's all about interpretation of box forms. $\endgroup$ – Szabolcs Nov 10 '16 at 9:37
  • $\begingroup$ To understand the behaviour, try res = {localize[x], localize[x]}; InputForm[res]. For as long as we don't interact with the front end and notebooks, Interpretation behaves as if it were sym with SetAttributes[sym, HoldRest]. $\endgroup$ – Szabolcs Nov 10 '16 at 9:40
  • $\begingroup$ @Szabolcs I know what you mean when you say that hiding something like this from the user is a bad idea (and I definitely agree) but from experience I know that people not too familiar with Mathematica (i.e. Matlab users) tend to both be very casual with short symbol names (e.g. x) and global symbols at the same time which leads to disbelieve when stuff inevitable goes awry. A small part of what I am developing is a function that turns an impedance network description like z1 + z2 || z3 into the network's transfer function. (+ corresponds to series; || to parallel connection) $\endgroup$ – Sascha Nov 10 '16 at 9:49
  • $\begingroup$ Can you explain better how these "localized" symbols will be used? It is only for displaying output? Do users interact with them? If yes, how? Can you give a short and trivial example of how a user might interact with these? Can you explain "localization" better? Localized to what scope? Maybe in chat? $\endgroup$ – Szabolcs Nov 10 '16 at 10:03

Your Answer

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

Browse other questions tagged or ask your own question.