Dear Monks,
maybe I'm just plain stupid here, but I can't help thinking about it.
Most of use probably use a more or less advanced editor while programming perl (and other languages) and we love the syntax-highlighting (aka font-lock) and indention mechanisms. And then from time to time there is an error in the editors machine, like a wrong highlighting after a complex regexp (e.g. put a unescaped '#' into a perl regexp and view with xemacs) or some problems with indention after a POD (xemacs, too; I just don't know any other editors well enough to get to their errors).

Wouldn't it be nice if the language itself would provide an interface to it's parse tree (am I using the word correctly here?), the structure and information of the programm. The language itself probably knows all the secrets/semantics and syntax it has and if it would be able to export this another application could be importing it.

I could think of an XMLish way of representing a language; s.th. like:

<programm language="perl" filename="hello_world.pl"> <scope name="global"> <function-definition name="hello" args="none"> <text> print "Hello world\n"; </text> </function-definition> <text> hello(); </text> </scope> </programm>
(probably the tag text would better be named code but you know about PM's code-Tags ;-)

And then there would be some kind of stylesheet which could provide a description of how to show that programm-code.

Well, as I said, maybe I'm just plain stupid here and don't think very far, but still this strikes me as a good idea: let the language export their information so that the editor developers don't have to keep in pace... What do you think?

Regards... Stefan
you begin bashing the string with a +42 regexp of confusion

Replies are listed 'Best First'.
Re: Parse Tree Export (as XML?)
by premchai21 (Curate) on Sep 18, 2001 at 00:40 UTC

    Lisp already does something like this, where almost everything is a list.

    Note however that your example is not quite fully XMLized. I would spell that:

    <program> <function name="hello" prototype=""> <call function="print"> <argument><string data="Hello world\n"/> </argument></call></function> <call function="hello"></call> </program>

    But note that this is a lot harder to type and read than

    #!/usr/bin/perl sub hello { print "Hello world\n" } hello();

    So one would not want to enter code as XML. I agree that having access to the parse tree would be good, through perl itself -- once the program was parsed perl would, given an appropriate option, spit out the parse tree in some form. I'm not sure that that form should optimally be XML, though, but it's a possibility.