@Christopher2222 Well, you can programmatically insert/embed a Table with prepopulated Cells, and you can even replace that whole thing at once.

And you can build the Cells using entries from a `table`, say.

But IMO the programming would be far more manageable/feasible with the `table` as the mutable data-structure and the Table handling/updating as more of a high-end display mechanism.

One exception to this is the case where all possible content is known and fixed (in one big Table), and the programming controls only how limited and select portions of Cells are hidden/revealed on the fly.

Another exception would be where all the "content" of all the Cells is in their own respective PlotComponent/DataTable/MathContainer/TextArea embedded components.  That could be problematic if your "descriptions" are a mix of text and typeset math.

GUI Tables are not implemented in a way that they are fully programmatically accessible (like a spreadsheet, say). The only way to represent the "content" of a Table's Cells are as XML.

For example a Table's Cell might contain a Section, or a Document Block, or another Table, etc. 

If you were thinking that a Table Cell would just have a Maple expression like say, x+y , as its content then you'd be mistaken.

Now, there is an (obscure, likely undocumented) streamcall that allows you to access the XML of the whole current worksheet. But programming with that would be insane (IMO).

If you want to keep track of, and program with a Maple structure whose contents are expressions the a mutable data structure like a `table` or an `rtable` would be more appropriate.

@Christopher2222 Doing something like Tabulate for Maple 18 is possible. It's not difficult (if you know how), but it is time-consuming.

Why should someone spend the time on backporting to a release at least 3 years old, especially when there's always lots of worthwhile other things to do moving forwards?

@Christopher2222 Yes this has been possible for several releases now.

You can use the DocumentTools:-Tabulate command as an easy way to do simpler cases.

Or you can use DocumentTools:-Layout:-Table for more general functionality. For that you'd also use other commands from the DocumentTools subpackages `Layout` and `Components`.

The original question didn't make it very clear just what level of post-insertion interaction would be wanted (...if any).

Are you saying that you want to see something with `Diff` ( and 2-argument `eval` ) instead of `D` ?

Why would you post such long question and not upload a worksheet containing the full example?

@max125 There is a help page for topic solve/parametric . For your example I used that calling sequence (along with the real option) as a way to invoke SolveTools:-SemiAlgebraic.

I went for that because your problem was a polynomial system and your wanted only real results.

For other kinds of system the goal of obtaining only purely real solutions can get very difficult indeed, and obtaining all real solutions harder still. Sometimes it's not even possible to do in Maple.

@Markiyan Hirnyk 

solve( {x^2+y^2+z^2 = 3, x+y+z = 3}, real, parametric );

                        [[z = 1, y = 1, x = 1]]

@NeillSmith Yes, one way is to put such definitions you like into a personal initialization file. That's relatively easy.

Another slightly more advenced way is to use LibraryTools:-Create  to make a .mla Library archive file, and then to use LibraryTools:-Save to store the procedures to that archive. (And you can store other stuff in it later, too. But keep a copy of the worksheet that actually builds the .mla archive and defines stuff and stores them. Handy for later revisions. You can just keep it in the same folder.)

Then you call augment libname in the initialization file, eg,

libname := "somenewfolder/foobar.mla", libname;

A tip: You should be able to create an alternate "launcher" for the Maple GUI, which passes the -s option and so starts without reading the initialization file. Sometimes useful for checking that weird behavior isn't due to such customizations. This can apply to either scenario: whether you put code definitions of libname adjustments into the init file.

@NeillSmith Please see the followup Comment to my Answer, which has further examples using equations and Equation Label references which do just what you now describe.

So do you generally want to first express the abstract computation (ie. like &* of deprecated linalg package) which you could only later force to compute explicitly (analogous to say hitting with evalm in the linalg sense)? An abstract implementation of the LinearAlgebra functionality is a long-standing general request, not only for the purpose of mathematical display but also for the serious task of expression manipulation/rearrangement.

Attached is a Document using the same two implmentations, but with examples using Equation Label references.

It works for me, using Maple 2016.2.

With one set of uneval quotes the Equation Label can be referenced (within a call to lhs) inside eval(...,1) for single-level evaluation. With two sets of uneval quotes the Equation Label can referenced as is (within a call to lhs).

cross_eqnlabels.mw

note. While Mapleprimes did not successfully inline the attachment, it does let me insert just the link.

@tomleslie The Question's tagged as "Maple 2016", and in version Maple 2016.2 your suggestion doesn't work. The call using uneval-quotes produces output with an unevaluated call to Typesetting:-delayCrossProduct . That's partly why he asked, I believe.

Technically, by itself the $ limits the number of arguments but does not specify that any argument must be passed. That's because even the so-called "required" parameters may not be checked until accessed/used. (See 3rd example in my attachment.)

Maple's quite happy to have a procedure which is defined with say 5 parameters only ever use the first 3 of them. (See 1st example in my attachment.) 

And optional parameters (eg. keyword, positional parameters) muddy things even more. (See 2nd example in my attachment.) And the seq modifier must surely make quite the muddle.

This is all partly why this kind of information is very rarely used, even by experts. It's possible that the OP is trying to do something very specialized, where the 1st operand of the procedure is actually some useful thing.

But I suspect more that the OP is trying to do something much more common, likely related to nargs and _nparams and related counts of the number of arguments that actually get passed into the procedure when called.

params.mw

(I'm sure Carl knows all this. I hope he forgives my adding a note... to the world.)

@gmzsvsclk 

collect(E,[q,w],distributed);

@Fzen 

For your amusement you can rearrange the by, while, and from parts.

for i by -1 while i>0 from numelems(arr) do
    # do something
end do