Simple Parsing: Tuning Spoken Lua Readouts in a Screen Reader

[Veli-Pekka Tätilä <vtatila@...>]

Hi, I'm new here and have a question on simple parsing of Lua, but before 
that a brief intro. If you'd like to skip the intro search for question. I'm 
a legally blind Uni student and mostly a Perl programmer. I encountered Lua 
recently inthe the latest version of Dolphin SUpernova, a Windows screen 
reader and magnifier that's popular in Europe, theyre using Lua Plus 5.1.x 
for scripting the screen reader itself for app specifics, when the 
competition uses their own horrible languages or VbScript.

I feel Lua was a great choice not only for its learnability and dynamic 
typing but also because it is a very nice language to read with a speech 
synthesizer naively line by line. I reckon this wasn't part of the design 
criteria but more like a happy accident, plus a result of avoiding 
TIMTOWTDI, <grin>. An order of magnitude nicer than Perl, and mostly beating 
Ruby and Python, since there is less syntax variety to be expencted and no 
forced indentation that's just a silly visual artifact with speech, from a 
blind user point of view.

I've read the PIL book on-line and the more I learn about Lua the more I 
like it. NOt sure how common a view this is, but to me it is mostly a 
rethought, syntactically cleaner core of what's nice in Perl without the 
text processing bias and with superb lernability. Plus the stuff I like but 
isn't there such as map, grep and push, is very easy to code. Take OOP for 
example, Lua manages the objects are just hashes idea perfectly and requires 
much less language user magic for doing inheritance, operator overloading, 
symbol tables, packages and so on. Just meta tables compared to ISA, 
overload, type globs, bless and the rest of the lot.

Question:
Though Lua code is certainly nice with speech, I'd like to prototype the 
feasibility of the idea of making it even more so using screen reader 
scripting. I'm not yet part of the firm doing the reader, just an end user. 
For testing this, I'd need a simple, SAX-like preferrably small and pure Lua 
parser that's easy to use and provides event callbacks like this is a: 
statement, operator +, ,method call, argument  3 foo of call, string 
literal, list assignment etc... Nothing fancy knowing when basic ssyntax 
structures start and end, and having the code processed left to right would 
be good enough for my needs at this point. Yet even for this, many syntax 
highlighting modules are too basic. Any recommendations?

Most of the Lua parsers I've found Leg, luaparse and yueliang are either not 
well documented, go way over my head or are overkill in features for this 
purpose. The self-containedness requirement is mostly due to me simply 
wishing to put the parser and a screen reader script of mine in an app 
specific folder, and being able to use the code straight away in the screen 
reader for my text editor. My own feeble attempt at a very simple hand-coded 
recursive descent parser failed miserably due to the grammar being 
left-recursive and for operator precedence issues. Is there a reworked 
grammar somewhere that doesn't include the left-recursion in the definition 
of expression? Even so I doubt I'll ever get my own parser hack working 
properly, <embarassed smile>.

Finally, as to what could be done to make the language more speech friendly 
at the screen reader level, the basic problem is that the reader has no idea 
of what it is reading. THus is says * as star, .. as period period., ( as 
left paren etc... And in complex statements the code is hard to master 
mentally, unless you cursor word by word. Straight app specific dictionary 
substitutions wouldn't get any context, whether brackets are in table 
constructors or indexing, for example, and would break the reading of string 
literals at any rate.

But if the reader understood Lua via a parser you could do: proper names for 
operators by context, breaks between statements, explicit numbering of items 
in long list assignments and function calls, not reading parentheses and 
braces in calls and constructors but indicating them in words - these are 
ideas that come to mind very first. e.g. for
print("Hello world")
"call print 1 <pause> 1 <pause> string hello world end <long pause>, in 
stead of the useual
print left paren quotes hello world quotes right paren. -- no pauses
Another thing I routinely do in comments but which could be spoken is what 
an end is ending e.g. end function, end while, end anonymous. and so on. Oh 
yes, and Lua patterns would require their own parser at some point in the 
far future.

Here's a slightly Apple-script inspired example table of what kind of 
operator naming I thought might be nice:

local t = {["+"] = "plus", ["-"] = "minus", ["*"] = "times",
["/"] = "per", ["%"] = "modulo", ["<"] = "before", ["<="] = "at most",
["=="] = "equals", "not equal to", [">"] = "after", [">="] = "at least",
["^"] = "to the power of", [".."] = "joined", ["and"] = "and",
["or"] = "or" }
} -- table

There might be yet another way to go about this, too. If there's a Lua 
disassembler, one could actually have a read out of what Lua sees during it 
parsing the code on the fly. rather than reading the actual code. However, 
this would get rid of all comments and I'm not sure, since I am not familiar 
with any internals, how CLEARLY the byte code corresponds to the statements 
in the source file i.e. is it easy to understand and how much things get 
optimized. THat is sometimes a problem in Perl's error messages and the 
deparse module.

At any rate I'd be greatful for any suggestions on how to go about tuning 
the speech reading in terms of parsing. At the moment I'm merely interested 
in testing how well a smarter speech readout of Lua could work. rather than 
doing a full-blown implementation that's ready to use for other users just 
yet.

--
With kind regards Veli-Pekka Tätilä