Addressing the followup,:

To plot the Vector V, interpreting its entries as uniformly spaced from a to b on the x-axis,

   plot(<<seq(a..b,(b-a)/(op(1,V)-1))>|V>);

and so, for V with 11 elements then to represent those on a plot from x=0..1,

   plot(<<seq(0..1,1/10)>|V>);

@Zeineb The detail that the data ranges from 0 to 1 on the x-axis is not present in the Vector, nor is it present elsewhere in your Question.

You have left out another detail: whether the Vector entries correspond to uniform placement along x=0..1.

@mmcdara You asked, "By the way, why doesn't Maple affect the type Vector to pf? id it because table is more general a type?"

It is because a table can be indexed by expressions other than just an integer, and so that behavior should be retained for backwards compatibility as well as broader generality.

@mmcdara The very first sentence of my Answer states that pf is a table.

That is a consequence of how the OP wrote his code. A preconstructed Vector is a decent alternative, but I stuck with what the OP had.

@Felipe_123 Do you mean like one of these, say?

PlotHistogram_2.mw

You could easily adjust the offset, if you want the bin numbers centered, or at left or right, etc.

You should run through what all these commands and options do. By familiarizing yourself with it, you'll be better able to customize it on your own in future.

Or you could construct a bar chart from the results from Statistics:-Histogram.

@markweitzman In Maple 2019.2 it doesn't bother with ftoc or ftocms once it gets that result from the meijergspecial method.

In Maple 2020.1 the internal mechanisms have been adjusted, and it continues for your example and tries ftoc and gets the simpler result.

You can see evidence of some of this by issuing these commands:

restart;
kernelopts(version);
infolevel[int]:=4:
int(2*Pi*x*sqrt(1+x^(-4/3)/9), x=0..1);

As previously mentioned, you can force method=ftoc or method=ftocms and get the simpler result from Maple 2019.2 as well.

Does your computation require the Grid Toolbox, rather than just the Grid package that is stock in Maple 2020, in order to compute with parallelization on your local multicore machine?

@robertocooper I have deleted a duplicate of this very Question (which merely showed another attempt at programming it). Don't split the Question and topic like that.

You can put your followup code in a new Reply here, or augment the Question body above and add it there.

@tomleslie I suspect that the Question is about discovering the particular identities of all the instances existing within some Document, of a given type of Embedded Component.

I don't think that the OP is asking about valid terms for referring to types of Components.

@Carl Love That's a very good point, thanks. I was hung up on the italics issue, which is not nearly as important.

However, I feel that the mechanism of assigning something (anything) to the problematic names is handy, but not great. It's a workaround.

It would better if the Typesetting package offered a configuration option for this. It has several similar things for special-function calls, relational operators, etc. It seems natural to me that it could also offer control for the Greek letters.

@mmcdara I didn't suggest that you would remove the global declaration inside your procedures. But it's not necessary at the top level. That is all.

You have shown one possible edit to the code, to initialize G:=[] inside the outer procedure. Fine.

But it's not the only way to edit the original.

You could also have kept the G:=[] done at the top level just before calling `Main` (or `f` in your followup)  while deleting the problematic top level global declaration statement. That is the shortest edit to the original. [edit] I showed this very idea, with code, in my Answer.

There are also ways to access and assign to global G from within the procedures -- even if they don't have their own `global` declarations. But I'll leave those aside as they are not simpler.

As an aside, personally I think changing globals from with procs is generally inferior namespace management. A modern alternative is to have Main be an appliable module which stores its own module-local G and provides an accessing export for getting G's value from outside Main.

@mmcdara [response below edited, in light of latest reply by the OP.]

At the top level assignments and access to the global G are immediately available.

You have not shown a version of the procedure Main (or even a very simplified one), which illustrates the difficulty in running in Maple 2020 versus Maple 2015.

Can you show a simple example in which the top level statement
   global G;
is required in order for a Main procedure to function properly in your Maple 2015?

Is it possible that the code change to initially assign the empty list to G is needed for some other reason, unrelated to whether you explicitly declare global G at the top level in Maple 2015?

@mmcdara I don't understand where the proc(...) exists, that matches that end proc. It's not clear from your proto-code what is being done (as you aver) at the "top level".

You didn't attach a worksheet with code that reproduces the issue (as I suggested). That makes it more difficult to tell what your code actually does in Maple 2015.

The term top level usually refers to statements outside any procedure body (including any parent procedure).

Could you attach an example of a worksheet in which that syntax was used and explain what effect you think it had?

@Gillee I only shoved in that eval from habit (for the case where the operator were assigned to a name, so get around last-name-eval). But it's not necessary for the anonymous operator. This should serve also:

Grid:-Map(subs(rr=r,MM=M,k->LArip(k,rr,MM)),[$(1..r)])

There are other ways to handle the original issue; I just went for less editing.

I have not studied your algorithm, but it seems that it might benefit from memoization. For example, the following runs in about 14sec using n=8 on my machine (previously was 24sec).

Magma_GridMap_ac_memo.mw

You could check for correct results.