Re: Ada 'hello world' for Android; success!

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 04.11.11 13:18, Stephen Leake wrote:

> In current OpenToken, we have 'procedure Parse' instead of 'procedure
> Produce_Subprograms'; the rest is the same. I gather
> 'Produce_Subprograms' generates Ada code, that must then be compiled.

Yes.

> I'm not clear what the benefit of this is over the current OpenToken
> approach.

Meant only to be a possible alternative, its implementation is trivial,
and it automatically reuses mechanisms such as a stack that
a traditional computer features as a built-in. :-)

The given method is exhaustive, if that's needed, it's there.
If there are no loops in the grammar itself (such as left recursion),
then the length of input determines the number of recursive
calls for this method, too, so use of stack space has a known
maximum.

From a programmer's perspective, the method shown will pass tokens
to handlers. Writers of SAX style content handlers will recognize
the scheme and find it familiar, I think.

Following are some ideas that I would find fairly easy to add
to the resulting parsers, to make them more useful, more efficient,
or even more powerful.
Are they equally easy to add to, for example, bottom up parsers?

1. A simple extension, using functions as subprograms, allows more
control: Start another rule (call another subprogram) only if the
previous one (a function) has returned False. IOW, parsing does
not need to be exhaustive.  (A variation can use non-local
transfer of control, i.e. exception handlers added to subprograms
where desired.)
<hack>Let r be the return value, then f(r) is the next rule.
Assumption: this choice is not to be determined by the grammer
alone if modeling it accordingly would be awkward.</hack>

2. Or keep some state information along the way that can be
queried for (pseudo-)context, making the grammar less static,
and react to input:  Only if rule R (m) has hit token T (j)
before, assume that the parser should now choose rule R (k).
The conditionals would be added to the generated code,
thus specializing the parsing process. OK, a.k.a hacking.
But see "Fence", next.

3. Or introduce pseudo-symbols such as "Fence" that have no
meaning in the language but will have an effect on backtracking:
backwards motion stops at a "Fence".
  (Another possible pseudo-symbol is "User-Input".)

4. One can use (or misuse?) the mechanism to perform lexical
scanning. A first run produces tokens from a sub-grammar describing
the language in terms of lexemes only.

The basic mechanism never changes, and the number of topics
from which the parsers' logic can be understood is, I think,
pleasantly small.