# Tag Info

48

Link to the code on GitHub I have been using this. It's mostly Leonid's code from the stackoverflow question you linked to, but it uses Definition instead of DownValues. Symbol names are printed without any context, but the full symbol name is put into a Tooltip so you can always find out what context a symbol is in. Update FullDefinition[symbol] claims ...

29

Symbols are created in the current context during parsing. This should not be a problem in normal circumstances as the symbols are merely "initialized" without values or properties. See these posts for more information: Is it possible to use Begin and End inside a Manipulate? Why doesn't this use of Begin[] work? When does Mathematica create a new ...

29

The answer of @R.M. already explains the essence of the problem. You can streamline the process of removing the Combinatorica from the $ContextPath by loading it via Block[{$ContextPath}, Needs["Combinatorica"]] (or use Get intead of Needs, although Needs is a preferred way to load a package). In this way, you don't have to do anything afterwards, ...

28

In version 10.1, I've built something like Spelunk into GeneralUtilities. To use it, run Needs["GeneralUtilities"] PrintDefinitions[symbol]; This will pop up a window that shows all definitions of symbol. Here is a short summary of features: The window shows code cells containing all DownValues, OwnValues, UpValues, SubValues, and Attributes of a ...

27

The red colouring indicates shadowing — i.e., when a symbol originally in a particular context, is exposed to the current context path, thereby clashing with another symbol of the same name in a different context, also on the context path. Example of shadowing: Here is a short example that demonstrates this. Try it out in a fresh kernel (call Quit[] ...

20

Short answer: yes, it is possible. The problem is that parsing is done line-by-line only for the top-level code. For code inside some head(s), it is first parsed as a whole. Therefore, your f is parsed to Globalf, and this is why that symbol is used. Here is what you can do, schematically: DynamicModule[{x = 5}, With[{def = MakeBoxes[f[y_] := y^2 + 1;], ...

19

Shadowing occurs only when there are two functions with the same name that are in $ContextPath. So right after you do <<Combinatorica, do the following:$ContextPath = Rest@$ContextPath; What this does is that it removes Combinatorica (which is the package you just loaded). Now the only Graph function that's on the path is SystemGraph and you can ... 19 I can now offer a solution which leverages the full power of the code formatter, in its new, more robust form. Load the formatter: Import["https://raw.github.com/lshifr/CodeFormatter/master/CodeFormatter.m"] Some examples: CodeFormatterSpelunk[RunThrough] CodeFormatterSpelunk[PacletManagerCreatePaclet] In the last example, using MakeBoxes ... 17 This behaviour has changed since that book was published. I am writing this additional answer to make it clear how Mathematica 9 searches contexts for symbols and that even the current version 9 documentation is incorrect in describing this. How symbol lookup actually works When you enter a symbol name such as x, Mathematica will check if a symbol with ... 15 Since nobody has mentioned it yet... V8 introduced the undocumented flag Debug$ExamineCode. When it is set to true, the information functions will display the definitions of ReadProtected symbols: Debug$ExamineCode = True ??BinLists It is sometimes useful to suppress some of the internal package names to make it easier to scan the definitions. Here ... 14 Here I offer the safe version of Get that can be used successively to collect all the source files and contexts of packages without polluting the memory (too much). What it does I have practically reverse-engineered all the necessary functions (Get, Needs, BeginPackage, Begin, EndPackage and End) so that I could inject the monitoring code for ... 14 The definitions aren't being lost, they're being shadowed, as described in the tutorial on contexts. Mathematica doesn't warn you about this because it only warns when there is shadowing between contexts that are listed in the$ContextPath. Since Begin only changes $Context and not$ContextPath, you don't get a warning when the symbol that causes shadowing ...

13

I would just use strings, for all their fragility: ClearAll[print]; print[sym_, {conts_String}] := With[{altptrn = Alternatives @@ Reverse[SortBy[{conts}, StringLength]]}, Print@StringReplace[ToString[InputForm@FullDefinition@sym], (x : (_ | "") ~~ altptrn ~~ y : (_ | "")) /; ! (x === "\"" && y === "\"") :> ...

13

Your specific problem looks like you somehow managed to not load the package properly (did you evaluate Get[...]?). There's also an excess space in your long-form call to f (just before EndPackage[]) that will give you an error. Although your package will work if you fix the typo, this is not in general a good way to define your function. To see why, try: ...

13

I am not sure these are the best ways but they should work. You could do what you did with Dimensions for all the symbols in Combinatorica For example, running this replaceAndLoad[context_String -> toContext_String] := Block[{$ContextPath}, Needs[context]; Scan[ToExpression[ toContext <> StringReplace[#, context ~~ sym__ :> sym] ... 13 It appears since version 3 shadowed variables are given priority, as demonstrated below. In the temp context x is taken as tempx unless Globalx exists. Remove[tempx, Globalx] tempx = 6; Begin["temp"]; {x, Globalx} End[]; {6, x} Remove[tempx, Globalx] tempx = 6; x = 5; Begin["temp"]; {x, Globalx} End[]; {5, 5} 12 General First of all, let me say that the mutual dependency of this type is usually a sign of sub-optimal design - if your two functions need to access each other, then it may mean that they should actually belong to the same package. However, in some rare cases such design can indeed simplify things. What you observed can be understood by looking at the ... 12 Using Begin and End won't help, because .mx files are lower-level and the way they are loaded is different from normal packages. I was about to say that this isn't possible, but here is a hack which seems to work: ClearAll[loadInContext]; loadInContext[context_String,file_String/;FileExtension[file]==="mx"]:= Module[{tag}, ... 11 One possibility would be to modify the notebook's stylesheet so that Input cells (or a clone) have something like: CellProlog -> ($ContextPath = DeleteDuplicates[Prepend[$ContextPath,"abc"]]) Then your package's context should be available to all the code: 11 After running your Package code the first time Test1 is added to the$ContextPath. When you call Test1function1[5] the symbol function1 is created in the context Test1 After calling BeginPackage["Test1"] and Begin["Private"] the $ContextPath is: {"Test1","System"} When you use function1 in function1[x_] := x it is found in the$ContextPath and ...

11

Not an answer. Just screen shot. I booted up version 2.2 to verify the book result. And it does verify. Something changed since the book was written !

11

This is because of $ContextPath. If the symbol outside the Begin/End is created in a context that is listed in$ContextPath, Mathematica will recognize it as belonging to that context even when called from a different context (even if Begin/End is put in a package file and called via Get): $ContextPath {"DocumentationSearch", "ResourceLocator", ... 10 This question is not too distantly related to my own on StackOverflow: Exposing Symbols to$ContextPath Leonid provides an interesting approach there that could be adapted to your problem. Rojo provides a solution that creates "proxy symbols" but these are not 100% equivalent. Information no longer works correctly for example: ?? ComKSubsets This ...

10

Well, here is a suggestion: you can overload Needs using Villegas-Gayley trick. To do this safely, here is a generator for local environments, where Needs will be overloaded: createTraceEnvironment[context_String]:= Module[{inNeeds}, Function[ code, InternalInheritedBlock[ ...

10

This is possible in the interactive session with \$PreRead. I will adopt my solution to the same problem posted in this Mathgroup thread. To quote my explanation from there, the essence of the present solution is to delay the parsing of the code (body) that must be executed inside a given context until run-time, that is, replace code ...

9

I think, using contexts here is a sensible suggestion, particularly because you want to use several variables. One possible alternative is to set up a struct-like data structure, where encapsulation mechanism is based on Module-generated persistent variables. There were many discussions related to emulation of structs in Mathematica, but, given the ...

9

One thing that might help you when investigating in such issues is the LinkSnooper. This is a java program that can be used to set up an additional kernel configuration. When you use this kernel, you can watch all traffic between front-end and kernel. With this, you could look what happens if you evaluate a simple 1+1 FE ---> K: ...

9

I will make no attempt to defend the fact that Mathematica simulates scoping by means of variable renaming. However, the behaviour that we see is consistent with the principles under which Mathematica does operate. Whenever Mathematica tries to interpret a symbol name, it first checks to see whether a symbol with that name already exists in a package in ...

8

I have not tested this yet but here is one possible approach: contextFreeDefinition[sym_Symbol, contexts_List] := Internal`InheritedBlock[{sym}, ClearAttributes[sym, ReadProtected]; If[contexts =!= {}, Message[contextFreeDefinition::contexts, contexts]]; Block[{ipf = ToString @ InputForm @ FullDefinition @ sym}, ipf = ...

Only top voted, non community-wiki answers of a minimum length are eligible