@Carl Love And here are the results of the experiment:

KeyLE:= (k1, k2)->
local r:= 0;
   if [k1,k2]::listlist then #try lex order of lists
       k1=k2 or `or`((do until k1[++r] <> k2[r]), thisproc(k1[r], k2[r]))
   else 
       try #numeric or string order 
           if (r:= evalb(k1 <= k2))::truefalse then r else error fi
       catch: evalb(k1 = {k1,k2}[1]) #set order (guaranteed to work)
       end try   
   fi
:
KeyLE_lame:= (k1, k2)-> 
    try if (local r:= evalb(k1 <= k2))::truefalse then r else error fi
    catch: evalb(k1 = {k1,k2}[1])
    end try
:
#Test list to sort:
S:= [seq]([seq](i), i= Iterator:-CartesianProduct([0, -1., 1.] $ 2))
: 
S1:= sort(S, 'key'= (x-> x));
    S1 := [[0, 0], [0, -1.], [0, 1.], [-1., 0], [-1., -1.], 
      [-1., 1.], [1., 0], [1., -1.], [1., 1.]]

S2:= sort(S, 'setorder');
    S2 := [[0, 0], [0, -1.], [0, 1.], [-1., 0], [-1., -1.],
      [-1., 1.], [1., 0], [1., -1.], [1., 1.]]  

S3:= sort(S, KeyLE_lame); 
    S3 := [[0, 0], [0, -1.], [0, 1.], [-1., 0], [-1., -1.],
      [-1., 1.], [1., 0], [1., -1.], [1., 1.]]  

S4:= sort(S, KeyLE);
   S4 := [[-1., -1.], [-1., 0], [-1., 1.], [0, -1.], [0, 0], 
     [0, 1.], [1., -1.], [1., 0], [1., 1.]]

nops({S1,S2,S3});
                               1
evalb(S1 = S4);
                             false

So lexicographic order of the lists doesn't have precedence over set order. Nonetheless, my idea of having key return a list is still useful, as shown in my Answer. If all the lists have the same number of entries, and the items in each list position collate as desired, then set order and lexicographic order will be the same. In particular, realcons fields in the list should be evalf'd to floats because set order puts integers before floats.

This is probably obvious, but one reason why the lexicographic order of lists is more desirable is that it makes keyed sort distribute over Cartesian products in the sense that

sort(A X B, key= (x-> x)) = sort(A, key= (x-> x)) X sort(B, key= (x-> x)),

where A and B are lists, and X is the Cartesian product operator.

@janhardo There is no formal structure for files with extension .mpl; you could just as well use .txt.

@David Sycamore My code was skipping the cases where the odd number appended to the right of the digit sum has leading zeros.

@Joe Riel I'm guessing (or perhaps I should say "hoping") that the builtin code of sort totally orders the keys the same way that they're ordered by this "<=" procedure:

KeyLE:= (k1, k2)->
local r:= 0;
   if [k1,k2]::listlist then #try lex order of lists
       k1=k2 or `or`((do until k1[++r] <> k2[r]), thisproc(k1[r], k2[r]))
   else
       try #numeric or string order 
           if (r:= evalb(k1 <= k2))::truefalse then r else error fi
       catch: evalb(k1 = {k1,k2}[1]) #set order (guaranteed to work)
       end try
   fi
:

Specifically, my hope is that lexicographic order of lists of the same length takes precedence over set order. Here is the *lame* alternative:

KeyLE_lame:= (k1, k2)->
    try if (local r:= evalb(k1 <= k2))::truefalse then r else error fi
    catch: evalb(k1 = {k1,k2}[1])
    end try
:

I'll run some experiments to discriminate these tomorrow.

@Anthrazit Definitely I would choose JSON over XML for this purpose. The "ML" in XML stands for "markup language", meaning that it's more oriented towards visual display than data storage.

@Joe Riel I think that you realize this already, but I'll mention it for Scot's and others' benefit: keyed sorts use setorder of the keys as a last resort if the keys are incomparable numerically or as strings. It may then try lexicographic order of lists (not sure). Only if the keys are otherwise incomparable does it use setorder.^[*1] For example,

S:= {evalf(-Pi), 0, evalf(Pi+1)}:
sort([S[]], 'key'= (x-> x));
                 [-3.141592654, 0, 4.141592654]

sort([S[]], 'setorder');
                 [0, -3.141592654, 4.141592654]

[*1] These statements are guesses based on some *small* amount of experimentation on my part. Since sort is built-in, I can't read its code and say for sure.

@Scot Gould You wrote:

• If I understand what you wrote, sort uses the value from first entry of a row label's list that it obtains from the key function to order the row labels, but if the two values from the two lists are equal, it uses the values from the second entry to compare. Yes?

Yes.

• This is exactly what I want it to do.

Yes, of course; that's why I posted it.

• However, in looking over examples in Help, I saw only one example of using 'key' so I'm not exactly sure how one would be able to know sort will work with a list of entries in the keys. 

It's my own discovery.

• Unless you object, I will suggest Maple add this example to the list of examples in both the "sort" help page and the "DataFrame/sort" page.

That's a good suggestion. I don't object.

I cannot duplicate your error in Maple 2020.1, and reading through your sys, I don't see how it's possible that you got that error in an earlier version of Maple. Your sys appears to be manifestly an explicit first-order system, so it doesn't need to be converted to one. So, are you sure that you got that specific error message using exactly the code shown in your worksheet? Please re-execute and confirm.

I get the error "initial Newton iteration not converging". That can usually be corrected by using a continuation parameter. I see that you mentioned continuation in a code comment.

@Anthrazit My shared kernel idea was based on a false impression of what you wanted. After reading your Reply to Tom, I realized that what you want is a database, something like your own version of Maple's ScientificConstants package. Mac Dude's Reply to your Reply outlines a potential solution. You should leverage Maple's Records as much as possible.

@Joe Riel I don't know if this is significantly more efficient, but I like it better (Maple 2019 or later required):

fd:= FileTools:-Text:-Open("data.csv"):
A:= Array([while (line:= readline(fd)) <> 0 do [parse(line)] od]);
fclose(fd);

Like your solution, mine supposes that each line contains the same number of entries, none of which are lists.

@Bohdan I'm guessing that your indexed entries are actually stored in the external file as strings, enclosed in double quotes. In that case, use datatype= anything. Let's say that you've successfully imported the file to a Maple matrix named M. We need to convert those strings to algebraic expressions. To do that, use

M1:= subsindets[flat](M, string, parse);

I just saw that you said "length exceeds error". The message "Length exceeds...." is not an error or even a warning. It's just a message that's shown instead of the actual output. It's only shown after that output has been computed in its entirety without error. That output still remains programmatically accessible.

@SeyiOshin You wrote:

• I have used Matlab to obtain the eigenvalues of the matrices when all the variables are defined

Then you weren't using Matlab's symbolic capabilities.

• and it did so in a fraction of the time it took Maple.

I don't find that surprising at all; Matlab works quite efficiently with hardware-float matrices. But I suspect that you would've achieved better results in Maple (better than what you got, not better than Matlab) had you declared your matrices to have datatype= float[8] (if they are real numbers) and shape= symmetric (if indeed they were symmetric).

And you think that Matlab's symbolic capabilities will work more efficiently than Maple's? I'd bet money against that proposition.

@acer In my experience, the "usual manner" is that the length of the expanded procedure is checked before performing any elision required by a low setting of interface(verboseproc). This is unfortunate. This is why procedures output by dsolve(..., numeric) for large systems often get the "length exceeded" message even though their bodies would've usually been elided anyway.