January 22, 2013
On Tuesday, 22 January 2013 at 05:51:16 UTC, Philippe Sigaud wrote:
> On Tue, Jan 22, 2013 at 2:55 AM, deadalnix <deadalnix@gmail.com> wrote:
>> On Monday, 21 January 2013 at 19:23:19 UTC, Jacob Carlborg wrote:
>
>>> I know people don't like it but I have to say, this seems it could be a
>>> job for AST macros.
>>
>> I was thinking the same thing, but don't wanted to bug people. Indeed, it is
>> the perfect job for AST macro. I can concur now that you mentioned it xD
>
> Would any of you be so kind as to propose another definition for AST
> macros here ?
>
> http://wiki.dlang.org/Commonly-Used_Acronyms

Well, AST macro don't exists in D, so it will probably be subject to controversy, but let me add something here.
January 22, 2013
On 2013-01-22 04:43, Daniel Murphy wrote:

> AST macros are just compiler support pushed into user code/libraries.
> Exposing the AST to the user is a huge task and forces any supporting
> compiler to use a fixed AST representation.

Would that be so bad idea, to have a fixed AST representation? The AST presented for the user doesn't need to be the same as the compiler uses internally.

It's the same as any library function. You can easily change the implementation as long as the signature and behavior is the same.

-- 
/Jacob Carlborg
January 22, 2013
On 01/21/2013 08:00 PM, Nick Sabalausky wrote:
> On Mon, 21 Jan 2013 11:48:58 +0100
> "deadalnix" <deadalnix@gmail.com> wrote:
>...
>> Why can't this be done in D ? What are the major problems ?
>
> I don't know whether or not it can be done in D. ...

Why not? I have essentially done it and posted it here.
Also, there is nothing feasible that 'cannot be done' in D, because D can host arbitrarily complex embedded languages.
January 22, 2013
"Jacob Carlborg" <doob@me.com> wrote in message news:kdlfhr$1676$1@digitalmars.com...
> Would that be so bad idea, to have a fixed AST representation? The AST presented for the user doesn't need to be the same as the compiler uses internally.
>
> It's the same as any library function. You can easily change the implementation as long as the signature and behavior is the same.
>
> -- 
> /Jacob Carlborg

It depends how much information is in the AST you give the user.  Just syntax?  Types?  Full semantic information?

Of course you can transform the internal AST to the user AST, but the more information the closer this gets to forcing the compiler to use the user AST, or support two ASTs internally.


January 22, 2013
On 2013-01-22 12:00, Daniel Murphy wrote:

> It depends how much information is in the AST you give the user.  Just
> syntax?  Types?  Full semantic information?
>
> Of course you can transform the internal AST to the user AST, but the more
> information the closer this gets to forcing the compiler to use the user
> AST, or support two ASTs internally.

I watched a talk about AST macros in Scala. He said it was a fairly small change to the compiler to implement. Around 1k lines of code. The AST introspection was already there in the form of runtime reflection.

I don't expect it to be as easy to do in DMD. Although Don has said it would be pretty easy to expose the internal AST to the user.

-- 
/Jacob Carlborg
January 22, 2013
On Tuesday, 22 January 2013 at 05:51:16 UTC, Philippe Sigaud wrote:
> On Tue, Jan 22, 2013 at 2:55 AM, deadalnix <deadalnix@gmail.com> wrote:
>> On Monday, 21 January 2013 at 19:23:19 UTC, Jacob Carlborg wrote:
>
>>> I know people don't like it but I have to say, this seems it could be a
>>> job for AST macros.
>>
>> I was thinking the same thing, but don't wanted to bug people. Indeed, it is
>> the perfect job for AST macro. I can concur now that you mentioned it xD
>
> Would any of you be so kind as to propose another definition for AST
> macros here ?
>
> http://wiki.dlang.org/Commonly-Used_Acronyms

AST macros is CTFE done right :)
January 22, 2013
On Tuesday, 22 January 2013 at 12:14:26 UTC, Max Samukha wrote:
> On Tuesday, 22 January 2013 at 05:51:16 UTC, Philippe Sigaud wrote:
>> On Tue, Jan 22, 2013 at 2:55 AM, deadalnix <deadalnix@gmail.com> wrote:
>>> On Monday, 21 January 2013 at 19:23:19 UTC, Jacob Carlborg wrote:
>>
>>>> I know people don't like it but I have to say, this seems it could be a
>>>> job for AST macros.
>>>
>>> I was thinking the same thing, but don't wanted to bug people. Indeed, it is
>>> the perfect job for AST macro. I can concur now that you mentioned it xD
>>
>> Would any of you be so kind as to propose another definition for AST
>> macros here ?
>>
>> http://wiki.dlang.org/Commonly-Used_Acronyms
>
> AST macros is CTFE done right :)

That is completely nonsensial.
January 22, 2013
On 1/22/13 7:14 AM, Max Samukha wrote:
> On Tuesday, 22 January 2013 at 05:51:16 UTC, Philippe Sigaud wrote:
>> On Tue, Jan 22, 2013 at 2:55 AM, deadalnix <deadalnix@gmail.com> wrote:
>>> On Monday, 21 January 2013 at 19:23:19 UTC, Jacob Carlborg wrote:
>>
>>>> I know people don't like it but I have to say, this seems it could be a
>>>> job for AST macros.
>>>
>>> I was thinking the same thing, but don't wanted to bug people.
>>> Indeed, it is
>>> the perfect job for AST macro. I can concur now that you mentioned it xD
>>
>> Would any of you be so kind as to propose another definition for AST
>> macros here ?
>>
>> http://wiki.dlang.org/Commonly-Used_Acronyms
>
> AST macros is CTFE done right :)

Not at all, I'd say. CTFE has a much lower cost of learning - you only need to know which subset of D is allowed. Maybe you meant code mixins?

Andrei
January 23, 2013
On 2013-01-22 20:51, Andrei Alexandrescu wrote:

> Not at all, I'd say. CTFE has a much lower cost of learning - you only
> need to know which subset of D is allowed. Maybe you meant code mixins?

To be able to use AST macros one needs CTFE. One needs functions to manipulate the AST during compile time. As far as I understand it, in Scala they just create a new instance of the compiler, during compilation, and just like that they have access to the whole language during compilation.

In D it feels like a feature first need to be implemented in the regular compiler. Then it needs to be duplicated to be able to be used as CTFE.

Example, in Scala if you throw an exception during compile time it will be handled properly and generate a compile error. What happens if you do the same in D? It won't run the function during compile time?

Techincally you can generate an empty AST just to be able to run a bunch of functions during compile time. This would be no higher cost of learning than CTFE in D.

-- 
/Jacob Carlborg
January 23, 2013
On 1/23/13 2:28 AM, Jacob Carlborg wrote:
> On 2013-01-22 20:51, Andrei Alexandrescu wrote:
>
>> Not at all, I'd say. CTFE has a much lower cost of learning - you only
>> need to know which subset of D is allowed. Maybe you meant code mixins?
>
> To be able to use AST macros one needs CTFE. One needs functions to
> manipulate the AST during compile time. As far as I understand it, in
> Scala they just create a new instance of the compiler, during
> compilation, and just like that they have access to the whole language
> during compilation.

Martin Odersky confessed to me being quite worried about the possible community reaction to the introduction of AST macros. I haven't kept close tabs to see how it's turning out.

> In D it feels like a feature first need to be implemented in the regular
> compiler. Then it needs to be duplicated to be able to be used as CTFE.
>
> Example, in Scala if you throw an exception during compile time it will
> be handled properly and generate a compile error. What happens if you do
> the same in D? It won't run the function during compile time?
>
> Techincally you can generate an empty AST just to be able to run a bunch
> of functions during compile time. This would be no higher cost of
> learning than CTFE in D.

I completely disagree. (Sorry to foul you twice.) All AST macro systems I've studied are considerably difficult to understand and use effectively. By comparison, string macros are brutal and unstructured but the kind of thing all programmer worth their salt can get done.


Andrei