Skip to main content

programming - Is Package development (via InitializationCells) compatible with creating new Notations (via MakeExpressions)?


Can new (lower-level) notations be readily used within package code?


There are a few notational additions that might improve my code base but I'm not sure if these will end up being more trouble than they are worth.


For example, take a first step in an attempt to implement a more “natural” and “efficient” struct; Using MakeExpression


MakeExpression[RowBox[{lhs___, x__, "\[CenterDot]", y__, rhs___}],StandardForm] := 
MakeExpression[RowBox[{lhs, RowBox[{x, "[", y, "]"}], rhs}],StandardForm];

yields a more OO-like notation


In[2]:= obj."field1"."field2"



Out[2]:= obj["field1"]["field2"]


[Here the . is mimicking Mma's \[CenterDot] -SE won't let newbies post images)]


In any (frontend) package development however, placing obj."field1"."field2" within an initialization cell causes this exact form to be placed in the corresponding .m file. It is this form that is subsequently loaded in by Get i.e. without any of the frontend parsing provided by the MakeExpression definition.


Hence the intended notation does not take effect in packages (instead CenterDot in CenterDot[obj,"field1","field2"] becomes unintentionally defined but a priori I want to avoid overloading CenterDot for efficiency/inheritance/encapsulation reasons).


One hack is to forcibly activate the frontend's parser while loading in packages by invisibly opening up the .m file and evaluating all initialization cells - something along the lines of:


ParsingGet[pathTomFile_] := With[{nb = NotebookOpen[pathTomFile, Visible -> False]},
FrontEndTokenExecute[nb, "EvaluateInitialization"];
NotebookClose@nb]

This then creates such messiness as having to explicitly integrate with Get's package name arguments, multi-argument BeginPackage calls, "stub symbols" and avoiding developmental surprises such as obj."field1"."field2" not reflecting package updates in single frontend tests such as (ParsingGet[mfilepath]; obj."field1"."field2") (the kernel will grab obj."field1"."field2" and not let go).



I’m a bit wary of going down a path that seems to quickly set off a series of cascading hacks but on the other hand I’m wondering if I’ve missed something (an InitializionCell-like option value?) or if anyone has extensively used such notational (or perhaps more accurately language) changes in package development?


One might expect they should be able to play nicely together since a whole package has been devoted to these lower-level notations in Mma (Jason Harris’s Notation package) and anyone going down this more involved notational route would surely want to harness them in their own packages at some point?



Answer



"these will end up being more trouble than they are worth." - to my mind, this is a very accurate assessment of the situation.


As far as syntax is concerned, you will face multiple obstacles, starting from package and front-end parser differences you outlined (which makes the use of e.g. Notation package in packages quite non-trivial if not problematic), and ending with the limitations of the Notation package itself. If you need a pre-processor to change some of the Mathematica syntax, the general solution would require a full Mathematica parser with modifiable grammar, something like preprocessors in some functional languages (camlp4 in Ocaml for example). Everything else (including the Notation package) will have lots of limitations.


What is worse, is that you seem to be willing to add some OO features, and even if you succeed with the syntax, you will run into the problems of semantics. And these are, I believe, unsolvable without adding a certain amount of native OO support to Mathematica. There were a number of discussions regarding OO in Mathematica, here are some links:


Struct-equivalent-in-mathematica


Struct-data-type-in-mathematica


Object-oriented-mathematica-programming


Question-on-setting-up-a-struct-in-mathematica-safely



Mathematica-oo-system-or-alternatives


which you may want to check out.


EDIT


To be a bit more constructive and illustrate what can be involved in making Notation work in packages, here is a link to a Mathgroup thread where I described one possible way to use it.


Comments

Popular posts from this blog

plotting - How to draw lines between specified dots on ListPlot?

I would like to create a plot where I have unconnected dots and some connected. So far, I have figured out how to draw the dots. My code is the following: ListPlot[{{1, 1}, {2, 2}, {3, 3}, {4, 4}, {1, 4}, {2, 5}, {3, 6}, {4, 7}, {1, 7}, {2, 8}, {3, 9}, {4, 10}, {1, 10}, {2, 11}, {3, 12}, {4,13}, {2.5, 7}}, Ticks -> {{1, 2, 3, 4}, None}, AxesStyle -> Thin, TicksStyle -> Directive[Black, Bold, 12], Mesh -> Full] I have thought using ListLinePlot command, but I don't know how to specify to the command to draw only selected lines between the dots. Do have any suggestions/hints on how to do that? Thank you. Answer One possibility would be to use Epilog with Line : ListPlot[ {{1, 1}, {2, 2}, {3, 3}, {4, 4}, {1, 4}, {2, 5}, {3, 6}, {4, 7}, {1, 7}, {2, 8}, {3, 9}, {4, 10}, {1, 10}, {2, 11}, {3, 12}, {4, 13}, {2.5, 7}}, Ticks -> {{1, 2, 3, 4}, None}, AxesStyle -> Thin, TicksStyle -> Directive[Black, Bold, 12], Mesh -> Full, Epilog -> { Line[ ...

dynamic - How can I make a clickable ArrayPlot that returns input?

I would like to create a dynamic ArrayPlot so that the rectangles, when clicked, provide the input. Can I use ArrayPlot for this? Or is there something else I should have to use? Answer ArrayPlot is much more than just a simple array like Grid : it represents a ranged 2D dataset, and its visualization can be finetuned by options like DataReversed and DataRange . These features make it quite complicated to reproduce the same layout and order with Grid . Here I offer AnnotatedArrayPlot which comes in handy when your dataset is more than just a flat 2D array. The dynamic interface allows highlighting individual cells and possibly interacting with them. AnnotatedArrayPlot works the same way as ArrayPlot and accepts the same options plus Enabled , HighlightCoordinates , HighlightStyle and HighlightElementFunction . data = {{Missing["HasSomeMoreData"], GrayLevel[ 1], {RGBColor[0, 1, 1], RGBColor[0, 0, 1], GrayLevel[1]}, RGBColor[0, 1, 0]}, {GrayLevel[0], GrayLevel...

Is there a way to do conditional matrix loop using 'continue'

I have the following: n = 3; m = 5; ww = RandomReal[{0, 0.1}, {n, n}]; uu = RandomReal[{0, 1}, {m, n}]; pp = RandomReal[{0, 1}, {n, n}]; ss = RandomInteger[{0, 5}, {m, n}]; Grid[{{"ww", "uu", "pp", "ss"}, {ww // TableForm, uu // TableForm, pp // TableForm, ss // TableForm}}, Spacings -> {5, 2}, Dividers -> All] where I would like to look at every element of matrix ss and produce a matrix tt , with zeroes at the locations in ss which have zeroes, and in all other positions do the following: tt = (-1/Subscript[ww, m]) Log[(1 - uu)/(Subscript[pp, m - 1])], where Subscript[ww, m] is the value at index of ww matrix and where Subscript[pp, m - 1] is the value at index-1 of pp matrix. So for example if the first value ever read from matrix ss happens to be 2, then value taken from matrix ww would be from the row 2, but from pp would be from row 1. Also how to tell difference between a 0 as a valid value from within the matrix elemen...