View mode: basic / threaded / horizontal-split · Log in · Help
January 22, 2013
Re: Internal and external iteration, fibers
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
Re: Internal and external iteration, fibers
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
Re: Internal and external iteration, fibers
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
Re: Internal and external iteration, fibers
"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
Re: Internal and external iteration, fibers
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
Re: Internal and external iteration, fibers
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
Re: Internal and external iteration, fibers
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
Re: Internal and external iteration, fibers
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
Re: Internal and external iteration, fibers
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
Re: Internal and external iteration, fibers
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
1 2 3 4 5 6
Top | Discussion index | About this forum | D home