@Carl Love Thanks. The documentation of Procedures says: 

One may infer that a variable declared local is visible in a nested scope (provided that no (conflicting) re-declaration exists) and any inner namesake will be in agreement with it in surrounding procedures. However, the experiment seems to mean that proc/use inserts local symbols (in this example, CompSeq) only into the actual statement body and does not insert such symbols into code (in this example, `convert/CompSeq`) that is called from body but does not explicitly appear in body.
As a result, even if CompSeq has already been localized before invoking `convert/CompSeq` in the environment, the CompSeq on line 45 of `convert/CompSeq` is still unable to access and inherit definitions from the outer local CompSeq. 

Ming-Ho Yee wrote that line 4 does not update the mapping created on line 1, so in your translation, the “:-” prefix (in other words, setting a global variable) should not be alowed to be used. In the next post, Ming-Ho Yee additionally wrote that: if your definition of dynamic scope is “a variable is bound to the most recent assignment during the program’s execution”, then it is not correct to say R is dynamically scoped. Moreover, running the program provided by this blog post in Maple returns 1. Accordingly, in my view, the core of Maple kernel only implements lexical scoping (proc) and read‐only lexical variables (use). 

@nm Here is a example that using a plain name is unsafe.
This works well: 

verify(2, 1, greater_than);
 = 
                              true

But if I happen to make a assignment …? 

greater_than := 0: # accidentally 
verify(2, 1, greater_than);
 = 
                             false

verify(2, 1, evaln(greater_than));
Error, (in verify) verification `greater_than` does not exist
verify(2, 1, 'greater_than');
Error, (in verify) verification `greater_than` does not exist

Certainly I can obtain the correct result after deleting definitions; however, this means that using plain names is less safe (No warning here!) after all.

@Carl Love I'm not sure if I have understood right, yet the following instance appears to imply the use of lexical scoping:

:-CompSeq := -1: # the computation sequence below is from CompSeq 
(proc($) local CompSeq: convert([x = a + b, i = a*b, j = x + i, y = a + sin(x)], procedure, 'locals' = {i, j}, 'globals' = {x, y}, 'params' = {a, b}) end)();
Error, (in convert/list) too many levels of recursion
use CompSeq = 'CompSeq' in convert([x = a + b, i = a*b, j = x + i, y = a + sin(x)], procedure, 'locals' = {i, j}, 'globals' = {x, y}, 'params' = {a, b}) end;
Error, (in convert/CompSeq) too many levels of recursion

It seems that I'll have either to temporarily clear `CompSeq` or to provisionally modify `convert/CompSeq` during the execution. 

@C_R This is because Maple and Mathematica use different argument conventions. Though convert("-2 EllipticE[1/2 ([Pi]/2 - x), 2]", 'FromMma'); returns -2*EllipticE(sin(1/4*Pi - 1/2*x), sqrt(2)), in Maple, 

> ArrayTools:-Alias(<seq(simplify(fnormal(subs[eval](x = Pi*\
> i, -2*EllipticE(sin(1/4*Pi - 1/2*x), sqrt(2))))), i = -6. .. 6, 1/2)>, [6, 4], C_order);
                         [1.198140235     0.    -1.198140235    -1.198140235 - 1.198140234 I]
                         [                                                                  ]
                         [-1.198140235    0.    1.198140235     1.198140235 + 1.198140234 I ]
                         [                                                                  ]
                         [1.198140235     0.    -1.198140235    -1.198140235 - 1.198140234 I]
                         [                                                                  ]
                         [-1.198140235    0.    1.198140235     1.198140235 + 1.198140234 I ]
                         [                                                                  ]
                         [1.198140235     0.    -1.198140235    -1.198140235 - 1.198140234 I]
                         [                                                                  ]
                         [-1.198140235    0.    1.198140235     1.198140235 + 1.198140234 I ]

while in Mathematica, 

In[2]:= Multicolumn[
         Chop[Table[-2. EllipticE[1/4 (\[Pi] - 2 x), 2], {x, -6 \[Pi], 
            6 \[Pi], \[Pi]/2}]], {6, 4}, Alignment \[Rule] Center, 
         Appearance \[Rule] "Horizontal"]

Out[2]= -8.38698 - 7.18884 I   -7.18884 - 7.18884 I   -5.9907 - 7.18884 I    -5.9907 - 5.9907 I

        -5.9907 - 4.79256 I    -4.79256 - 4.79256 I   -3.59442 - 4.79256 I   -3.59442 - 3.59442 I

        -3.59442 - 2.39628 I   -2.39628 - 2.39628 I   -1.19814 - 2.39628 I   -1.19814 - 1.19814 I

        -1.19814               0                      1.19814                1.19814 + 1.19814 I

        1.19814 + 2.39628 I    2.39628 + 2.39628 I    3.59442 + 2.39628 I    3.59442 + 3.59442 I

        3.59442 + 4.79256 I    4.79256 + 4.79256 I    5.9907 + 4.79256 I     5.9907 + 5.9907 I

So specifying the assumption is, in effect, not unnecessary: 

simplify(diff(-2*EllipticE(sin(1/4*Pi - 1/2*x), sqrt(2)), x) - sqrt(sin(x)), assume = [x in RealRange(-Pi/2, 3*Pi/2)]);
 = 
                               0

@C_R I think that if I suppose that 0 ≤ x ≤ π, a simpler solution will be obtained as follows: According to Reciprocal-Modulus Transformation, we may have EllipticE(z, k) - (1 - k**2)*EllipticF(z, k) = k*EllipticE(k*z, 1/k) (But is this still correct for z > 1???). So after simplifying the result given by Maple manually, . And then 

f := (simplify@@2)(1/combine(1/eval(int(sqrt(sin(x)), x), 2*EllipticE(sqrt(sin(x) + 1), sqrt(2)/2) - EllipticF(sqrt(sin(x) + 1), sqrt(2)/2) = sqrt(2)*EllipticE(cos(1/2*(Pi/2 - x)), sqrt(2))))) assuming x in RealRange(0, Pi);
 = 
                                  /   /1      1  \   (1/2)\
     -2 I signum(cos(x)) EllipticE|sin|- Pi + - x|, 2     |
                                  \   \4      2  /        /

Compare:

g := convert("-2 EllipticE[1/2 ([Pi]/2 - x), 2]", 'FromMma'); # Note that (*Maple's *)EllipticE(x, k)＝(*Mathematica's *)EllipticE[ϕ, m], where x = sin(ϕ) and m = k2. 
 = 
                         /   /1      1  \         \
             -2 EllipticE|sin|- Pi - - x|, sqrt(2)|
                         \   \4      2  /         /

seq(MmaTranslator:-Mma:-Chop(evalf(subs(x = j*Pi, (f - g) - (1 - I)*sqrt(2/Pi)*signum(cos(x))*GAMMA(3/4)^2)), 2^(-10)), j = 0 .. 1, 1/20);
 = 
 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

Unfortunately, I am not sure if this is mathematically correct …. 

I do not know why Maple is unable to reduce those trigonometric functions in the result, yet I additionally find that Maple fails to fully simplify the corresponding definite integration as well:

simplify(int(sqrt(sin(x)), x = Pi/2 .. Pi));
 = 
     /          /1  (1/2)\              /1  (1/2)\\  (1/2)
     |-EllipticK|- 2     | + 2 EllipticE|- 2     || 2     
     \          \2       /              \2       //       

In[1]:= Integrate[Sqrt[Sin[x]], {x, \[Pi]/2, \[Pi]}]

             2         3 2
Out[1]= Sqrt[--] Gamma[-]
             Pi        4

Perharps Maple has forgotten some of what the developers once taught it ….

@Carl Love & @mmcdara Many thanks. Maybe such functionalities can be built into the underlying core so that Maple can sort rows of the rtable in-place.

@nm Thanks for your advice. But they behave differently. For example, 

ArrayTools:-SortBy(<4, 1, 1 | 0, 2, 5 | 7, 9, 8>, [.., 1]);
                           [1  2  9]
                           [       ]
                           [1  5  8]
                           [       ]
                           [4  0  7]

ArrayTools:-SortBy(<4, 1, 1 | 0, 2, 5 | 7, 9, 8>, 'column', [1, 3, 2]);
Error, (in ArrayTools:-SortBy) for 2-D rtable, expecting either list of indices or keyword column/row and index to specify what is to be sorted

while my purpose is: first sort the rows of the input 2-D array in specific order based on the elements in the specified column, then sort rows that have equal elements in the specified column based on the elements in the next specified column, and so forth. (Also, I hope that there will be a multidimensional analogue.)

@mmcdara Thanks for your test. I think that when working with Statistics, perharps using Sort@Trim is better (since they are in the same toolchain).
As for your last point, the reason is that you only measure the average time (instead of the total time). The MatLab code given in that Blog is: 

    tic
    for i=1:300
        y=mink(x,j*100);
    end
    minkResults(j)=toc;

 So “CodeTools:-Usage(..., 'interations' = 300)” should be changed to something like

to 5 do (*warm up the code to avoid its first-time costs*) od:
time[real]('(Statistics:-Sort@Statistics:-Trim)( … )' $ 3e2);

 Besides, though there exists a one-dimensional Statistics:-Sort function, is there a similar sortrows/sortcols in Maple?

@dharr Thanks. This is also useful, because the input data can contain any element.

@mmcdara Thanks. I think this function is just what I am seeking, although it appears to only handle numeric objects with real values.
Besides, in your worksheet, "the sorted 1000 smaller" runs much faster than "the 1000 smaller". Maybe there is some mistake?

@jalal For example, 

InertForm:-Display(InertForm:-Parse("2*sqrt(3)"), 'inert' = false);
subs("⋅" = " ", %);

Do you mean combinat:-randcomb([`+`, `*`, `-`], 1)? 

@Carl Love Thanks. I think that I know why `Iterator:-CartesianProduct` is not faster; later I find a bug in `Iterator:-CartesianProduct`. Below is the output from showstat(Iterator:-CartesianProduct::ModuleCopy): 

So by default the iterator is not compiled. However, even if I specify “'compile' = true” manually, the compiled iterator still runs slower (!) than your uncompiled `CP[6]`, which is really strange. 

@ecterrab I think that what the OP wants is a direct shortcut key for the overbar U+0305 (something like an overscript with long underlines).

@Carl Love In the main code, “It:-CartesianProduct(DigitSets())” is used. Suppose that DigitSets() is {0, 1, 2, 3}, {0, 1, 2, 3}. Is there any difference among 

Iterator:-CartesianProduct({0, 1, 2, 3}, {0, 1, 2, 3}):
Iterator:-MixedRadixGrayCode([3 + 1, 3 + 1]):
Iterator:-MultiSeq(<0, 0> .. <3, 3>):
Iterator:-MixedRadixTuples([3 + 1, 3 + 1]):
combinat:-cartprod([{0, 1, 2, 3}, {0, 1, 2, 3}]):

?