@Ali Hassani I amended the example above to include a Grid:-Wait(1) command. This is needed to make the code totally safe. However, it's unlikely to make any difference when there's such trivial code in the preceding Run command.

@vv Sorry, I corrected my definition of "lexicographically earlier". The last clause should be "for all k < n, A(k) = B(k)". Now do you agree that it's total and lexicographic?

You wrote:

• x[n] seems to be the least positive interger not in { x[1],...,x[n-1] } which satisfies ...

Yes, exactly. 

It is the sequences themselves that are ordered, not the concatentions of the digits of their (finite) initial segments.

@Ali Hassani No worries.

It can be done like this:

restart:
Grid:-Run(0, "a:= 2; Grid:-Send(1, a);");
Grid:-Run(1, "a:= Grid:-Receive(0);");
Grid:-Wait(1);
Grid:-Get(1, a);
                               2

This is just an example to promote your understanding. It's not meant to show a good way of doing this in practice.

@vv The OP is using the following ordering of infinite sequences A and B of positive integers: A is "lexicographically earlier" than B iff there exists an n such that A(n) < B(n) and for all k < n, A(k) = B(k).

@Ali Hassani I am using the term "master node" loosely to refer to the the process with which you are directly interacting (typing into). This node should not be considered to be part of the "grid". The master node is not the same as node 0, which is part of the grid. Unfortunately, if you inquire Grid:-MyNode() before any other Grid computation happens, it'll say 0. Perhaps this should be considered a bug. If you use Grid:-MyNode() from the master node after doing an actual Grid computation, it'll return -1:

restart:
printf("My node is %d.\n", Grid:-MyNode());
Grid:-Run(0, "a:= 2; a;"):
printf("My node is %d.\n", Grid:-MyNode()); 
My node is 0.
My node is -1.

I don't think that it's ever useful to issue a Grid:-Receive command from the master node. When Grid:-Receive(n) is issued from any node, that node waits until a message is sent to it (using Grid:-Send) from node n. So, your Grid:-Receive command from the master node is simply waiting for a message that'll never come.

To send the value of a from node 0 to node 1 (and name it a in node 1), do

restart:
Grid:-Run(0, "a:= 2;");
Grid:-Set(1, 'a' = Grid:-Get(0, a));
Grid:-Get(1, a);
                               2

So, this doesn't use Send or Receive at all.

Please read the help page ?ProgrammingGuide,Chapter15. It is an entire book chapter (in a Maple worksheet) on the packages Threads and Grid.

@mmcdara Since traperror has been deprecated and replaced by try ... catch ... end try (so long ago that I can't recall ever using traperror), I would assume that the errors handled by try are a superset of those handled by traperror, but I'm not 100% sure of that.

As of Maple 2019 (I think), try ... end try can be used inside (1D-input) expressions like traperror can, so I don't see any reason to ever use traperror.

@Ali Hassani You'll get a quicker Answer if you tell me your version. This particular Question is not difficult, but I don't want to waste time posting examples that won't work with your version.

Please do not re-ask unanswered Questions in a separate thread; they'll simply be deleted and anger the Moderators. Please do not use the Posts section for Questions. If you want to increase the visibility of your Question, either editing the Question itself or posting a Reply to it will raise it to the top of the "Recent conversations" stack.

Note that there are only about 20 people here who regularly answer Questions, and they all do it voluntarily, even those who work for Maplesoft.

Your Question is somewhat obscure and requires a somewhat lengthy Answer. I will Answer it. Be patient.

Before I answer, I'd like to know what Maple version (such as "Maple 2020") you're using. For all future Questions, please put your Maple version in the header.

@nm Yes, the problem is the difference between local and global evaluation rules. So why is it a problem if you need to use eval? Or, you could compare to 'NULL' rather than to NULL as in

boo:= proc() 'NULL' end proc:
foo:= proc() local b:= boo(); evalb(b='NULL') end proc:
foo();
                              true

However, in the bigger picture, I do agree with both Acer and Joe: Returning FAIL or a Record or a table is a better choice. 

@emendes You asked:

• Would catch: #any other error be the answer for the errors I mentioned in my answer to @acer?

Yes, if you're willing to write a block of code under that catch: that'll do something reasonable (such as return FAIL) for all catchable errors.

• 1) If there is an error, catch will caught it, right?

Mostly yes. All catchable errors will be caught. Not all errors are catchable, but the vast majority are.

• 2) If there is an error in line 2 for instance, all commands in line3 to line 4 will not be evaluated, right? 

Yes, without exception.

@janhardo In general, the answer is no because there are fundamental theoretical limitations. Look up "Richardson's Theorem" (for example, in Wikipedia).

On the other hand, if you're willing to sacrifice some efficiency for user friendliness, and you're willing to accept an occasional FAIL as a non-answer, you could wrap all conditionals with is and not use evalb. Richardson's Theorem says that it's impossible to eliminate all FAILs.

@acer Yes, that's exactly how I envisioned it. It both resets the counter and avoids the need for the if t=x... statement. Admittedly, the ancient syntax (such as lack of keyword parameters) is awkward.

@acer Could the same thing be accomplished using the 2nd and 3rd arguments to `tools/genglobal`, the exceptions and the reset flag?

The help-page example that you're working on is flawed in a ridiculously ironic way because floor is not threadsafe. The expression

floor((j-i)/2) + i

should be replaced with

iquo(i+j, 2)

which is simpler, more efficient, and threadsafe.