I'm excited that Maple is adding functionalities related to theoretical physics. It would be beneficial if the efforts are carried out with more consultation with actual practising theoretical physicists, who have been using computer algebra systems to do calculations in the Standard Model for decades. A historical note is that one of the first computer algebra systems in existence, Schoonschip, was written by Martinus Veltman to solve problems during the development of the Standard Model. He later won a Nobel Prize. Software packages for generating and calculating Feynman diagrams in the complete Standard Model (and proposed extensions thereof) have long existed. Some examples are below:

http://www.feynarts.de/

https://feyncalc.github.io/

https://feynrules.irmp.ucl.ac.be/

https://github.com/vermaseren/form

I'm sure what you have is a great addition to Maple, but personally I think a higher bar needs to be cleared before it's called "a remarkable achievement in computational physics". Such language would make sense if the software is used to perform previously impossible novel calculations published in peer-reviewed journals. This can certainly happen in future, given the strong base of Maple's symbolic calculation capabilities, if the package develops in a direction guided by the actual research frontier today.

@acer Thanks for the answer! I found another issue related to your example: In Maple 2016, the declarations (export and local) must appear before any actual code (definitions of procedures and assignments of variables). I cannot write, for example,

M:=module()
    export F1;
    F1 := 3;
    export F2;
    F2 :=4;
end module;

In this case, the fix is simple: export F2 should be written before F1:=3 .

@Carl Love I mostly agree with you, but here's an example at the other extreme: "Hello world" in C# reads like

System.Console.WriteLine("Hello World!");

This is pretty excessive!

@vv Here's my attempt to use a procedure defined in an inner module.

OM := module()
option packge;
export IM:= module()
    option package;
    export add_three := x-> x+3;
    end module;
export times_two_add_three:= x-> IM:-add_three(2*x);
end module;

I'd like to be able to omit IM:- in the second-to-last line, but neither with(IM); nor uses IM; works (when inserted above the second-to-last line).

@vv This is almost what I want. The only remaining issue is that I cannot write (using your example)

with(IM);

inside the outer module. For example, I might want to do this if I want to use some "inner" procedure heavily in the defintion of a procedure in the outer module. When I try to do this, Maple gives me some mysterious error, so I assume this is not supported.

@Carl Love thanks, it surely helps to make the code shorter when definitions and export are written together. The only minor annoyance is that I still have to write multiple lines of

with(OM:-IM1);
with(OM:-IM2);
with(OM:-IM3);
...

when there are many inner modules, to access the procedures exported by inner modules. What would be really convenient (but not currently possible) is this: inside the outer module, you write something like

export IM1:-procedure1;
export IM2:-procedure2;
export IM3:-procedure3;
...

Then the user of the outer module would access procedure1, procedure2, procedure3... by writing just one line

with(outerModule);

In other words, I'm mainly concerned with reducing the verbosity for the user not the package writer (OK, both are myself, but I'll write the package once and use it many times). This is the "nested export" feature which would be nice. In any case, I'll still use nested modules (as currently implemented in Maple) as I feel the benefit of a modular coding style outweights these minor complaints.

@Carl Love  Great. I'm writing packages (i.e. modules with option package). I need to access procedures defined and exported by an "inner" package. After some trial and error, here's what works:

1. Inside an outerModule, define several "sub-modules", say, innerModule1, innerModule2, innerModule3.

2. Export some procedures in each sub-module.

3. Inside outerModule, add
export innerModule1;
export innerModule2;
export innerModule3;

4. In the main program, add
with(outerModule:-innerModule1);
with(outerModule:-innerModule2);
with(outerModule:-innerModule3);

Now I can call the procedures exported by the inner modules. Unfortunately this gets very verbose when there are many inner modules. It would be really helpful if Maple supported "nested export", allowing procedures exported by inner modules to be further exported by the outer module. Incidentally, in a different programming language Julia, you can do it like this:

module OuterModule

module InnerModule1
add_three(x) = x + 3 # Julia notation for defining a function, i.e. procedure in Maple
end

using .InnerModule1  # Similar to Maple's "with". Brings `add_three` into the namespace
export add_three # Export it from OuterModule too

end

using OuterModule  # Now I can call the function add_three, made available via nested export.

The above example shows that you may get only one term even when you specify the order to be 3. The mysterious error "division by zero series" can be avoided by switching from series to MultiSeries:-series, though I've found the latter to be sometimes slower when operating on large expressions.

Thanks for all the helpful replies. Indeed the presence of poles triggers the issue. Here's a simple line of code which demonstrates the problem

series(1/((x^2 + 1)^2-1), x=0, 2);

Maple 2020 tells me

Error, division by zero series

The error disappears when I increase the order

series(1/((x^2 + 1)^2-1), x=0, 3);

Maple now gives me the result with only one term (sorry I don't know how to adjust the image size)

Strangely, if I re-run the first line of code, no more error will be produced, because Maple has "remembered" the subsequent result. To reliably reproduce the error, you should first restart the Maple server.

@Carl Love Your answer below is more or less what's needed, but I suppose your procedure should be modified to add exception handling to "catch" the error and continue to increase the order, otherwise Maple quits the calculation as soon as an error is encountered.

This may not be practical, but a library implementing some of Mathematica's pattern matching functionality would be very useful. I use both systems. Symbolic manipulations are generally faster in Maple, sometimes by an order of magnitude (e.g. for polynomial operations for which Maple has built-in parallelized algorithms), but certain programming tasks are cumbersome without pattern matching.

@acer Suppose the main module is in the plain text file main.mpl, and a local procedure is in proc1.mpl. Then I add $include "proc1.mpl" inside main.mpl. But I want to load main.mpl from a Maple worksheet in another directory, by read("file_path/main.mpl"). Now this will cause an error, because main.mpl will be looking for proc1.mpl in the current working directory of the worksheet, rather than the directory that contains both main.mpl and proc1.mpl. What's a good way around this problem? For example setting up a default directory for $include, by some environment variable?

@acer My procedures are already in a module, so I'll just unnest the inner procedure and move it into the module itself. The minor annoyance is that the source file for the module will contain more top-level procedures, which somehow affects readability from my perspective, but this is no worse than the analogous situation in C programming.

@Carl Love I just had a chance to come back to this project, thanks for the interesting code! I learned several new things about Maple programming by understanding your code.

Incidentally, Wolfram Mathematica's version of applyrule (ReplaceAll) can actually get the job done, because it understands commutativity of multiplication.