[Python-ideas] Needing help to change the grammar

[spir]

Le Sat, 18 Apr 2009 23:52:49 +1000,
Nick Coghlan <ncoghlan at gmail.com> s'exprima ainsi:

> (moving discussion to Python Ideas)
> 
> (Context for py-ideas: a teacher in Brazil is working on a Python
> language variant that uses Portuguese rather than English-based
> keywords. This is intended for use in teaching introductory programming
> lessons, not as a professional development tool)
> 
> Glenn Linderman wrote:
> > import pt_BR
> > 
> > An implementation along that line, except for things like reversing the
> > order of "not" and "is", would allow the next national language
> > customization to be done by just recoding the pt_BR module, renaming to
> > pt_it or pt_fr or pt_no and translating a bunch of strings, no?
> > 
> > Probably it would be sufficient to allow for one language at a time, per
> > module.
> 
> Making that work would actually require something like the file encoding
> cookie that is detected at the parsing stage. Otherwise the parser and
> compiler would choke on the unexpected keywords long before the
> interpreter reached the stage of attempting to import anything.
> 
> Adjusting the parser to accept different keyword names would be even
> more difficult though, since changing the details of the grammar
> definition is a lot more invasive than just changing the encoding of the
> file being read.

> Cheers,
> Nick.
> 

Maybe I don't really understand the problem, or am overlooking obvious issues. If the question is only to have a national language variant of python, there are certainly numerous easier methods than tweaking the parser to make it flexible enough to be natural language-aware.

Why not simply have a preprocessing func that translates back to standard/english python using a simple dict? For practicle everyday work, this may done by:
* assigning a special extension (eg .pybr) to the 'special' source code files,
* associating this extension to the preprocessing program...
* that would pass the back-translated .py source to python.

[A more general solution would be to introduce a customization layer/interface in a python-aware editor. Sources would always been stored in standard format. At load-time, they would be translated according to a currently active config, that, indeed, would only affect developper input-output (the principle is thus analog to syntax-highlighting).
* Any developper can edit any source according to his/her own preferences.
* Python does not need to care about that.
* Customization can be lexical (keywords, builtins, signs) but also touch a certain amount of syntax.
The issue here is that the editor parser (for syntax highlighting and numerous nice features) has to be made flexible enough to cope with this customization.]

Denis
------
la vita e estrany