January 23, 2013
On Wednesday, 23 January 2013 at 07:57:10 UTC, Andrei Alexandrescu wrote:
> 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.
>

Can he or you explain why ?

> 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.
>

2 things here.

First, that is why people used to say about templates. D shows that this isn't a fatality.

Secondly, this is true that AST macro is probably harder to understand. In fact, it is not expected that most programmer use it (or at least not before I'm retired as a dev). I don't even think any experienced dev should use it on a daily basis.

However, it opens so much doors. First, no need for a custom compiler to test new features. Anyone can download source code and start using some new features. We can actually integrate field tested stuff in the language. Every D compiler can get the new feature as well.

If a feature is controversial, I can include in in my project, but not in D in general.

An example of such new feature is the iteration mechanism proposed here.

However, I do think that attribute was a key piece for such mechanism, and has been handled the most backward possible way. So clean AST macro may have been impaired here.

Anyway, I do strongly feel like we should stop adding more stuff now. Too much stuff is here already, some already start to misbehave together. It is probably time to consolidate the language, and keep that kind of stuff for a later version.

After all, many language live without most of the feature D have.
January 23, 2013
On Wed, Jan 23, 2013 at 09:38:01AM +0100, deadalnix wrote: [...]
> Anyway, I do strongly feel like we should stop adding more stuff now. Too much stuff is here already, some already start to misbehave together. It is probably time to consolidate the language, and keep that kind of stuff for a later version.
> 
> After all, many language live without most of the feature D have.

Yeah, as I said elsewhere in this forum, D tends to work wonderfully well when features are used in isolation, but once you start combining them, you quickly tread into unexplored territory, compiler holes, etc.. It's fun and cool to add new features, I'll agree, but it's really time for us to focus on using what we already have and iron out all the wrinkles so that we can have a product that we are proud of.


T

-- 
"No, John.  I want formats that are actually useful, rather than over-featured megaliths that address all questions by piling on ridiculous internal links in forms which are hideously over-complex." -- Simon St. Laurent on xml-dev
January 23, 2013
On Wednesday, 23 January 2013 at 15:36:16 UTC, H. S. Teoh wrote:
> On Wed, Jan 23, 2013 at 09:38:01AM +0100, deadalnix wrote:
> [...]
>> Anyway, I do strongly feel like we should stop adding more stuff
>> now. Too much stuff is here already, some already start to misbehave
>> together. It is probably time to consolidate the language, and keep
>> that kind of stuff for a later version.
>> 
>> After all, many language live without most of the feature D have.
>
> Yeah, as I said elsewhere in this forum, D tends to work wonderfully
> well when features are used in isolation, but once you start combining
> them, you quickly tread into unexplored territory, compiler holes, etc..
> It's fun and cool to add new features, I'll agree, but it's really time
> for us to focus on using what we already have and iron out all the
> wrinkles so that we can have a product that we are proud of.
>
>
> T

D is already so feature rich. As cool as all these ideas are, at this stage it's hardly a priority.

Also, having a high feature introduction rate with a low usage rate means that we lose the benefit of the practical hindsight that has provided so much useful information thus far (from c++, c, java etc.)
January 23, 2013
On Wed, 2013-01-23 at 02:57 -0500, Andrei Alexandrescu wrote: […]
> 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.

AST transforms are working wonderfully well in Groovy. This is the tool that is allowing there to be static type checking and static compilation of Groovy code amongst a whole load of other things.

Macros in Scala are a bit more of a mixed blessing, not because they are not a useful tool but because of the reaction of the community.  All in all I suspect they will be fine.

[…]
> 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.

There is no doubt that AST transforms in Groovy is not something the application programmer would spend time on unless they knew what they were doing. It isn't a trivial API. However it is straightforward once you know ASTs.
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


January 23, 2013
On 1/23/13 2:08 PM, Russel Winder wrote:
> There is no doubt that AST transforms in Groovy is not something the
> application programmer would spend time on unless they knew what they
> were doing. It isn't a trivial API. However it is straightforward once
> you know ASTs.

Given the richness of today's D, I'd say AST macros are not part of the mythical plan.

Andrei
January 23, 2013
On 2013-01-23 08:57, Andrei Alexandrescu wrote:

> 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.

I was talking about functions running at compile time. In D that's handled by an interpreter which doesn't support the full language. It also behaves differently from the "regular" language. Bugs occur in the CTFE interpreter which doesn't occur in the regular compiler.

In Scala it _is_ the regular compiler that handles both the CTFE and the regular code. A bug in the regular compiler will show up during CTFE as well.

BTW, how do you make a string mixin hygienic?

-- 
/Jacob Carlborg
January 23, 2013
On Wed, 2013-01-23 at 15:15 -0500, Andrei Alexandrescu wrote: […]
> Given the richness of today's D, I'd say AST macros are not part of the mythical plan.

Works for me.

The issue is only whether there is an idiomatic expression for a given style. For me currently D has everything I need that C++ makes difficult.

The difficult tension for me is JVM vs. native. On the JVM I have Groovy, Scala, (Ceylon, Kotlin, JRuby, Jython, Clojure), even Java, which is an interesting milieu. Natively there is  C, C++, D, Clay, Rust, Haskell which makes for fun tensions.

The core problem is how to make D appealing to C and C++ programmers.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


January 23, 2013
On 1/23/13 3:29 PM, Jacob Carlborg wrote:
> On 2013-01-23 08:57, Andrei Alexandrescu wrote:
>
>> 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.
>
> I was talking about functions running at compile time. In D that's
> handled by an interpreter which doesn't support the full language.

It's a subset. That's a better thing than _another_ language.

> It
> also behaves differently from the "regular" language.

To the smallest extent possible.

> Bugs occur in the
> CTFE interpreter which doesn't occur in the regular compiler.

Not an argument.

> In Scala it _is_ the regular compiler that handles both the CTFE and the
> regular code. A bug in the regular compiler will show up during CTFE as
> well.

Agreed this is a good thing for Scala, it takes advantage of the jit infrastructure.

> BTW, how do you make a string mixin hygienic?

By passing fresh names as arguments into the function creating it. We don't have a strong story there.


Andrei
January 24, 2013
> The difficult tension for me is JVM vs. native. On the JVM I have
> Groovy, Scala, (Ceylon, Kotlin, JRuby, Jython, Clojure), even Java,
> which is an interesting milieu. Natively there is  C, C++, D, Clay,
> Rust, Haskell which makes for fun tensions.
>

There is also Nimrod which has 'yield' and AST macros ...
January 24, 2013
On Wednesday, 23 January 2013 at 21:50:39 UTC, Andrei Alexandrescu wrote:
>> In Scala it _is_ the regular compiler that handles both the CTFE and the
>> regular code. A bug in the regular compiler will show up during CTFE as
>> well.
>
> Agreed this is a good thing for Scala, it takes advantage of the jit infrastructure.
>

SDC does something similar with LLVM JIT capabilities.