On Sep 18, 12:23 pm, "Edward K. Ream" <[email protected]> wrote:
> The energy continues. If anything, it is increasing. Perhaps the > increase has come from confronting doubts head on. [big snip] > That's enough for now. I can hear the fool saying, "so what, why > should anyone care?" I'll discuss the bigger picture in the next > reply. In the short term, the new work makes it much easier for me to study people's code. The improved c-to-python command will properly indent C programs, then render them into pseudo-python that is much easier to study. In addition, the work suggests new commands: convert-functions- to-class, convert-to-pep8-names and beautify-c-code. The longer term view is that these tools are part of a grand strategy: to convert entire C programs to Python. As examples, we might want either swig or Blender to be Python programs primarily, with C confined to defining Python extension modules. In swig's case, no C extension at all would be needed. Instantly the fool has two objections: 1. Why should we want to convert C programs that work into Python? 2. Converting C Programs to Python is (ahem) a fool's errand: you'll never make the new programs as reliable as the old. There is some merit to both objections, but they are not the entire story. To repeat what I said in the previous post, It would make no sense at all to rewrite code that is a) "frozen" and b) usable as is. However, there are many cases where one or both do not apply. For instance, the swig program is under active development. It is hardly frozen. It's an extremely important program, related to the grand strategy of converting C programs to Python. Thus, swig would benefit greatly by the clarity that being written in Python would provide. In fact, there is a strategy for *reliably* converting C programs to Python: ensure that all tests (unit test and otherwise) that pass in C also pass in Python. This strategy is "interesting" in the sense that it will require further invention, especially in those instances where *per-function* unit tests do not already exist for the C functions. Even as it is, the strategy is valuable: A. It is a way around the (provable) theorem that it is impossible to determine whether two programs are equivalent. The theorem may be true, but it is (obviously) possible to determine whether two programs produce the same outputs for the same inputs. In practice, getting all tests to agree will usually suffice. B. The strategy suggests whole new lines of research, namely how to create and compare sets of unit tests. C. The strategy suggests that the quality of *existing* tests of C programs determines the feasibility of converting the program to Python. The better the tests, the more feasible a conversion project is likely to be. To summarize, paying attention to the fool has *increased* my energy level, suggested new smallish tools, and opened up new areas of research. This is all I have to say now about the grand strategic issues. I'm going to start work on all the nifty tools that are now begging to be completed... Edward P.S. One reason I am interested in swig is that it an extremely sophisticated type analyzer for C. I want to understand this analysis in detail, and it would be much easier for me (and, presumably, for David Beazley, swig's author) to understand and play with the code if it were written in Python. Indeed, just removing the Python cruft often suggests important improvements, but a bigger win comes from having something vastly more powerful data structures than C++'s pathetic data structures. The bigger win of all would come from playing with an *executable* copy of swig from within Leo. EKR -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
