Follow-up Comment #9, task #5082 (project administration): To be read in conjunction with comment #8
Hi, Here are some clarifications to issues pointed out by a member of a Hindawi related discussion group regarding comment #8, with respect to the last paragraph: (these are my replies to his queries and some which you could possibly have.) The final para of comment #8 was: > Finally, as about Hindawi being *complete* - well, I say > *complete* because I have *implemented* or *originally* (*not* > forked) localised even *lex* and *yacc*. So we can now have > *any* programming language written in Indian languages (Hindi, > Bangla, Gujrati, Tamil, Kannada, etc.) This method can also be > extended to *every* other human language, but my *personal* > focus is on the India languages *for now*. First, the reference to *lex* here is a reference to the standard family of *lexical analyser generation tools* or more appropriately the standard *pattern action language lex*, which automate the task of construction of lexical analysers. This includes *GNU flex* and for all purposes the compiler for the *lex language*, as mentioned here, is *flex* and not the original *lex*, which (probably) is a proprietary program originally written by Eric Schmidt and Mike Lesk, as per the wiki page http://en.wikipedia.org/wiki/Lex Please note that Aho, Sethi and Ullman (author of the "Dragon" book - Compilers: Principles, Techniques and Tools) refer to the tool or program as "the Lex compiler", and to its input specification as "the Lex language" (pg 105, sec 3.5, 13th Indian reprint). I choose to adhere to their definition and refer to the *lex language* by the term *lex*. Similarly, the reference to *yacc* is a reference to the standard family of *parser generation tools*, which include *GNU bison*. Original *AT&T yacc*, developed by Stephen C. Johnson, is *not* proprietary any more as an open source version of the *original* AT&T yacc is now available with the standard distributions of Plan 9 and OpenSolaris, as per the wiki page http://en.wikipedia.org/wiki/Yacc However, for all purposes here, by yacc I refer to the *program* gnu bison which accepts *the input specification* for yacc. Link to the original yacc source code distributed under Common Development and Distribution License http://cvs.opensolaris.org/source/xref/on/usr/src/cmd/sgs/yacc/ Secondly, since I am refering to *flex*, *yacc* and *bison* programs here, I need to clarify another point, which possibly relates to *forking*. I have *not* performed any source code modification on these programs. If (and whenever) I modify the source for these programs I shall be very happy to submit the diffs to the *original* authors for inclusion in the original sources. Then what have I done and why do I say that I have *implemented* or *originally* (*not* forked) localised even *lex* and *yacc*? I have *originally* localised *the language lex* and *the input specification for yacc* to Indian languages (and similarly for at least one language belonging to each of the definitive programming paradigms, but we are only discussing lex and yacc here, as there may be some confusion regarding their proprietary nature or concerning the issue of forking). Lex and yacc languages are called "Shaili Shabda" (the language lex in Hindi, Bangla, Gujrati etc.; Shabda means word, which is used here to imply "token") and "Shaili Vyaaka" (the input specification for yacc in Hindi, Bangla, Gujrati etc.; it is also called Shaili Vyaakaran in full; Vyaakaran means grammar). These are *original* because, obviously, these are *not* copied or forked from any other programming system, and *no* other similar system exists, to the best of my knowledge. What I mean by *implemented* is that I have implemented the languages Shaili Shabda and Shaili Vyaaka, as decribed above along with other vernacular languages. The current implementation of the tools for these languages is as a front-end compiler. This is similar to the way in which C++ was first implemented as a front-end compiler to C, called CFront. These front-end compilers generate intermediate code which can be accepted by various back-ends. For my distribution of Hindawi, I have choosen GCC as back-end. Someone else may choose some other back-end, as GPL allows them to do so. The benefits of having seperate front-ends and back-ends for compilers certainly do not need to be over-emphasised! (With issues such as optimisation, a new optimising compiler would not be worth the effort when we already have GCC as a state-of-the-art optimising compiler as a back-end.) Third, there is a issue that flex and bison could themselves be localised to support Indian languages. Well, yes, but how much, without a major rewrite? Let me try to explain this, though I am not sure that I can recollect every practical problem I faced. We can certainly write a lexer with flex which accepts 8-bit Indic code, but for even a moderate sized programming language, this 8-bit lexer would be tremendously huge if optimised for speed, and very slow if optimised for size. I tried this with flex initially, but when it kept crashing for a moderate set of tokens for Indic programming languages, I decided to adopt a new approach. I could have continued with modifying flex, but the effort required would be orders of magnitude greater, requiring changes to internal structures and much more. Along with this, consider the fact that Shabda and Vyaak are not intended as replacements for lex and yacc. These are intended to support Indic programming languages. Hence, even the action statements and other stuff such as buffer funtions, error handlers, startup-code etc. are to be written in Indic programming languages (in this case Shaili Guru, which is the C programming language localised to Indian languages), hence a new language was inevitable. Similar reasons can be stated for yacc as well. Regards, Abhishek Choudhary _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/task/?func=detailitem&item_id=5082> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/
