On Tue, 2011-06-21 at 22:30 +0200, Basile Starynkevitch wrote: > On Tue, 21 Jun 2011 15:34:51 -0400 > David Malcolm <dmalc...@redhat.com> wrote: > > I'm aware of MELT - as I understand it, it's a Lisp variant. > > Yes. However, I do have in the works an infix syntax of MELT called > MILT. But it would just be an infix/prefix syntax of exactly the same > language (more precisely, of a large subset of MELT). I mean that every > syntactic construct in MELT will have its infix/prefix equivalent (e.g. > MELT operations starting with + will be additive infix, etc..). > > I don't think that MELT lispy syntax matters that much. For the few > users of MELT, the main issue is understand the details of GCC internal > representations (Gimple & Tree, notably), not MELT syntax. I'm sure > your Python hackers will have the same issue: understanding GCC details > is hard (much harder than learning how to code in Python or in MELT).
FWIW, I think I disagree with some of the above. For me, one of the core "ideas" behind python is that syntax matters a great deal - code is read more times than it's written, so the readability of code to humans is important. Whether this is a good tradeoff, and the meaning of "readability" is a deeply personal thing, of course - Python is my favorite language, but others have different preferences. There's also a limit to how much "cognitive load" I can cope with at once: learning a new domain of types and objects is one thing, learning a new (to me) language and runtime at the same time adds to the burden. I know lots of handy tricks for debugging Python code, which is helpful to me when dealing with an unfamiliar problem domain (such as seeing GCC's insides for the first time). I certainly agree with you that understanding GCC's internals is a difficult hurdle for new contributors to overcome. I'm still on that journey... Currently I've documented my Python API from the perspective of the Python classes and objects. However, it just struck me that this could be improved by adding a description from the perspective of the source language - provide snippets of C/C++/etc code demonstrating an element of syntax, and show for each one what the resulting IR looks like as tree/gimple instances. I may do this for my Python plugin; maybe it's a good idea for the other plugins? (and perhaps for GCC's own devel docs?) [... snip (further language discussion) ...] > > [Plus I'm using this code to analyse python's .c code, so I selfishly > > hope that other python fans will want to help; by using python as the > > extension language I hope I'll be more likely to get more contributors]. > > I actually dreamed that some Python C binding guru would make a MELT > extension to analyze such things. Again, the issue is understanding GCC > internals (mostly Gimple & Tree representations), and being able to > specify a GCC pass doing such analysis. This also requires a deep > understanding of Python -> C binding rules. [FWIW, I'm a CPython committer, and I know the Python->C binding rules well (I hope!); but not to rehash all the above I greatly prefer to work in Python itself. (sorry)] Thanks for the feedback; I hope this is helpful Dave
