On 11/10/13 11:55 PM, Jacob Carlborg wrote:
> On 2013-11-10 23:49, Andrei Alexandrescu wrote:
>
>> The way I see this is, these preexisting features (which shan't be
>> thrown away) diminish the motivation for adding another feature.
>
> I think the opposite. It shows how powerful macros are and that they
> will most likely be able to implement other new features that haven't
> been proposed yet.
>
> Adding a bunch of new features to the language instead of taking a step
> back and thinking if something else can be added that implement these
> features and many more shows bad judgement.

No need to be snarky about it. The point here is that there is significant difficulty to remove features that already exist and are useful, which changes the game considerably.

Andrei

On 11/11/13 12:00 AM, Jacob Carlborg wrote:
> On 2013-11-11 02:54, Andrei Alexandrescu wrote:
>
>> What do you have in mind? I find it difficult to grab e.g. the file and
>> the line unless there's some plumbing in the language that allows you to.
>
> The language just need to provide a way to introspect the AST. If we're
> talking about a specific API I can think of something like this:
>
> macro foo (Context context, Ast!(string) str)
> {
>      auto line = context.caller.line;
>      auto file = context.caller.file;
> }
>
> foo("asd");

So... there is rote addition to the context.caller structure. It's just spelled differently. No?

Andrei

On Tuesday, 12 November 2013 at 02:34:52 UTC, Andrei Alexandrescu wrote:
> No need to be snarky about it. The point here is that there is significant difficulty to remove features that already exist and are useful, which changes the game considerably.
>
> Andrei

That is true. However, please understand that this is extremely frustrating to have a lot of gadget features that solve a specific issue when much more generic solutions exists, and when these gadgets actually makes it more difficult to introduce the proper features.

If we put aside the AST macro thing (granted we have a swiss army knife of gadgets for many of its typical uses cases), several other skeleton don't want to stay in the closet.

If I has to pick 2:
tail qualified type parameter are one. It is impossible to have a use defined type that behave as slices/pointers. That is showstopper for a proper collection library. I have only ugly solution to propose to that now. Lately, I was plying with thing along the lines of struct S[T] { auto foo() const[T] { ... } } I'm afraid that what already exist in that area makes things quite difficult.

The lack of qualifier for ownership, which makes concurrency and interface between manual memory management and GC tedious. For that one, isolated seems the way to go.

These same issue continue to pop up in many different forms (for instance, see Kenji's DIP, where he is trying to hack around some gadget to unique postblit work).

On 11/11/13 9:11 PM, deadalnix wrote:
> On Tuesday, 12 November 2013 at 02:34:52 UTC, Andrei Alexandrescu wrote:
>> No need to be snarky about it. The point here is that there is
>> significant difficulty to remove features that already exist and are
>> useful, which changes the game considerably.
>>
>> Andrei
>
> That is true. However, please understand that this is extremely
> frustrating to have a lot of gadget features that solve a specific issue
> when much more generic solutions exists, and when these gadgets actually
> makes it more difficult to introduce the proper features.

Frustration is inappropriate. Probably "bummed" would be more fit for the situation. (Which I am not, but that's a different story; I personally don't think macros are all they're cracked to be.)

We did not have a macro-based solution when D was being invented, and I don't think there's a lot of glory in seeing patterns for doing things differently after the language has been in use for a while. There's a whole water under the bridge between now and then.

> If we put aside the AST macro thing (granted we have a swiss army knife
> of gadgets for many of its typical uses cases), several other skeleton
> don't want to stay in the closet.
>
> If I has to pick 2:
> tail qualified type parameter are one. It is impossible to have a use
> defined type that behave as slices/pointers. That is showstopper for a
> proper collection library. I have only ugly solution to propose to that
> now. Lately, I was plying with thing along the lines of struct S[T] {
> auto foo() const[T] { ... } } I'm afraid that what already exist in that
> area makes things quite difficult.
>
> The lack of qualifier for ownership, which makes concurrency and
> interface between manual memory management and GC tedious. For that one,
> isolated seems the way to go.
>
> These same issue continue to pop up in many different forms (for
> instance, see Kenji's DIP, where he is trying to hack around some gadget
> to unique postblit work).

Our goals for the time being are to improve stability, close gaps in the type system, and make good use of features in code. To the extent we can't do what we want to do, the topics you mention are fit.


Andrei

On Tuesday, 12 November 2013 at 05:58:02 UTC, Andrei Alexandrescu wrote:
>> If I has to pick 2:
>> tail qualified type parameter are one. It is impossible to have a use
>> defined type that behave as slices/pointers. That is showstopper for a
>> proper collection library. I have only ugly solution to propose to that
>> now. Lately, I was plying with thing along the lines of struct S[T] {
>> auto foo() const[T] { ... } } I'm afraid that what already exist in that
>> area makes things quite difficult.
>>
>> The lack of qualifier for ownership, which makes concurrency and
>> interface between manual memory management and GC tedious. For that one,
>> isolated seems the way to go.
>>
>> These same issue continue to pop up in many different forms (for
>> instance, see Kenji's DIP, where he is trying to hack around some gadget
>> to unique postblit work).
>
> Our goals for the time being are to improve stability, close gaps in the type system, and make good use of features in code. To the extent we can't do what we want to do, the topics you mention are fit.
>
>
> Andrei

Yes, as much as I'd like to have macro, I don't think this is the right time now. Closing the gaps is more important.

On 2013-11-12 03:34, Andrei Alexandrescu wrote:

> No need to be snarky about it. The point here is that there is
> significant difficulty to remove features that already exist and are
> useful, which changes the game considerably.

I'm really trying to be as humble as I can but you're not making it easy.

I have not said we should remove any of the existing features. I'm trying to show that several already existing features could have been implemented using macros if they existed early in the development. It should show that it is a powerful feature and can hopefully be used to solve new ides with library code instead changing the languages.

-- 
/Jacob Carlborg

On 2013-11-12 03:35, Andrei Alexandrescu wrote:

> So... there is rote addition to the context.caller structure. It's just
> spelled differently. No?

Have you seen the other posts? Have even read the proposal? If you think that I just want a different syntax for __LINE__ and __FILE__ you're way, way off. That's just an extremely small part of the proposal. __LINE__ and __FILE__ would not be removed.

-- 
/Jacob Carlborg

On 11/11/13 11:46 PM, Jacob Carlborg wrote:
> On 2013-11-12 03:34, Andrei Alexandrescu wrote:
>
>> No need to be snarky about it. The point here is that there is
>> significant difficulty to remove features that already exist and are
>> useful, which changes the game considerably.
>
> I'm really trying to be as humble as I can but you're not making it easy.
>
> I have not said we should remove any of the existing features. I'm
> trying to show that several already existing features could have been
> implemented using macros if they existed early in the development. It
> should show that it is a powerful feature and can hopefully be used to
> solve new ides with library code instead changing the languages.

Fine, although a sense of futility is hard to shake seeing as we won't replace those existing features. I think a much stronger point would be made if the power of the feature were demonstrated on problems not accessible with the existing ones.

About DIP 50: I will say "no" but please do not take it personally. It's great there is discussion about this, and I encourage it, but at this time I think we should make no plans to add macros to D.


Andrei

On 11/11/13 11:50 PM, Jacob Carlborg wrote:
> On 2013-11-12 03:35, Andrei Alexandrescu wrote:
>
>> So... there is rote addition to the context.caller structure. It's just
>> spelled differently. No?
>
> Have you seen the other posts?

Yes. Don't assume whoever disagrees with you is misinformed.

> Have even read the proposal?

Yes.

> If you think
> that I just want a different syntax for __LINE__ and __FILE__ you're
> way, way off. That's just an extremely small part of the proposal.
> __LINE__ and __FILE__ would not be removed.

This is putting words in my mouth.


Andrei

On 2013-11-12 08:52, Andrei Alexandrescu wrote:

> Fine, although a sense of futility is hard to shake seeing as we won't
> replace those existing features. I think a much stronger point would be
> made if the power of the feature were demonstrated on problems not
> accessible with the existing ones.

You just said we shouldn't replace existing features.

"The point here is that there is
significant difficulty to remove features that already exist"

http://forum.dlang.org/thread/bwsofbnigfbrxwouiobj@forum.dlang.org?page=9#post-l5s44b:242c36:241:40digitalmars.com

> About DIP 50: I will say "no" but please do not take it personally. It's
> great there is discussion about this, and I encourage it, but at this
> time I think we should make no plans to add macros to D.

I don't think we should add macros now either. This proposal is far from ready. If Martin hadn't suggested I should create a DIP, I wouldn't have, at least now at this time.

BTW, just saying "no" doesn't help a bit. You could just have said "foo". That's extremely annoying. You're shooting down very many suggestions/proposal/ideas with just a "no", or the more elaborated answer "no, never going to happen".

On the other hand when you have a proposal it should be consider pre-approved and is a more of a FYI.

-- 
/Jacob Carlborg