AST Macros?

[deadalnix]

Le 05/06/2012 11:02, foobar a écrit :
> On Tuesday, 5 June 2012 at 07:08:19 UTC, Don Clugston wrote:
>> On 04/06/12 20:46, Jacob Carlborg wrote:
>>> On 2012-06-04 10:03, Don Clugston wrote:
>>>
>>>> AST macros were discussed informally on the day after the conference,
>>>> and it quickly became clear that the proposed ones were nowhere near
>>>> powerful enough. Since that time nobody has come up with another
>>>> proposal, as far as I know.
>>>
>>> I think others have suggested doing something similar like Nemerle,
>>> Scala or Nimrod.
>>>
>>
>> Yes but only in very vague terms -- not in any more words than that.
>> When I look at the Nimrod docs, it basically seems to be nothing more
>> than "expose the compiler internal data structures". Which is
>> extremely easy to do but causes a heap of problems in the long term.
>
> This argument was raised before. That "heap of problems" is as vague as
> the proposed AST system(s).
> As far as I can tell, that heap of problems is mainly about making it
> harder to make internal breaking changes since the compiler is no longer
> a black box.
>
> Now, I'd argue that having a stable API for those compiler internals in
> needed anyway. Besides the obvious benefits of a more modular design
> that better encapsulates the different layers of the compilation
> process, it allows us to implement a compiler as a set of libraries
> which benefits the tool ecosystem, IDEs, text-editors, lint tools, etc.
> Thools which could reuse subsets of these libraries (e.g. think of
> Clang's design and how it allowed for the vim auto-complete plugin).
>
> Even _without_ the AST macros I think it's a worthy goal to pursuit, AST
> macros simply make the outcome that much sweeter.

Indeed. I'm working toward this goal.