On Mon, Nov 26, 2012 at 11:45:52AM +0100, Emmanuel wrote:
> Hi,
Thanks to Emmanuel for having take time to send an email
(we are close colleagues working on the same floor in the
same building, so we usually interact face to face)
> I'm trying to use MELT to handle information provided by GCC
> internals during compilation.
> It would be nice to have an emacs mode dedicated to MELT – whose
> syntax is LISP like recognizing all symbols provided by the standard
> library.
The standard emacs mode for Lisp works quite well on MELT.
It only forgets to highlight some important MELT macro-symbols
You could improve your Emacs mode for MELT with its lisp-mode-hook variable
See
http://stackoverflow.com/a/10672354/841108
The ugly details probably depend upon your particular version of Emacs.
For the MELT standard library, you are perhaps wishing a tool like etags.
> Yet MELT is specially dedicated for handling GCC internals (gimples,
> trees, basic blocks, edges...) which seem to be
> called "stuff" in MELT context, while the MELT values are just
> called "values". It would be useful to introduce
> converters (stuff -> values) and (values -> stuff) as it would make
> the syntax lighter and to design the MELT emacs mode (to come) so
> that it
> highlights the distinction between "stuff" and "values".
Actually, what Emmanuel rightly dislike is that when we have to code
(let (
(:tree t (tree_content tv))
)
we are saying twice that we want some tree.
I am thinking that I could improve the MELT language so that the default ctype of bindings in let expressions
would be derived from the expression binding the variable, so that we could code simply
(let (
(t (tree_content tv))
)
in other words, the default c-type for let binding is up to now :value; we could introduce
perhaps a new c-type annotation :auto so that
(let (
(:auto t (tree_content tv))
)
would mean bind t to the result of (tree_content tv) and guess the c-type of t
from the c-type of the expression (tree_content tv) and we could decide that :auto is the
implicit annotation in let bindings.
I could also improve MELT with another construct:
(box X)
which will use the c-type of X to decide to call the appropriate boxing construct
like make_tree make_gimple make_edge etc.. We probably want also a
(constbox X)
and introduce constant discriminators like discr_const_tree etc...
Do you (any person on the list) think that my suggestions would improve MELT???
Cheers
--
Basile STARYNKEVITCH
http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile:
+33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***