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.