On 2013-11-12 09:00, Andrei Alexandrescu wrote:

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

I absolutely do not. But when I read this:

"An argument for macros would have to do a
lot more than 'we don't need __FILE__ etc. anymore'"

I find it hard to believe anything else.

http://forum.dlang.org/thread/bwsofbnigfbrxwouiobj@forum.dlang.org?page=8#post-l5p5b8:241kju:241:40digitalmars.com

-- 
/Jacob Carlborg

On 11/12/13 12:02 AM, Jacob Carlborg wrote:
> 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

Yes. So I said. I don't get why you'd provide a link - it's in my text that you quote. Indeed, we shouldn't replace existing features.

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

Fine.

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

So how could we express a "no" that doesn't annoy you in the extreme? In case the answer would be "you haven't explained why", allow me to retort.

I've mentioned the argument before: at this point we should focus on quality of implementation and making good use of the features we have. In fact I am repeating myself: http://goo.gl/1thq1j. As has been publicly known for a while now, our strategy has been to improve quality and to double down on the assets we have. People ask for a roadmap, and what's missing from a roadmap is as important as what's there.

This is a strategy that Walter and I agree with, have been transparent about, and that may work or not, with various degrees of success. Reasonable people may disagree what the best step moving forward should be, but at some point some step must be made and we can't adopt your strategy, with which we disagree, as our strategy, just to be nice and not offend your sensibility. (I'm using "we" here because Walter and I discussed this at large.) There must be a way to say "no" that doesn't offend you. Please advise what that is.


Andrei

On 11/12/13 12:09 AM, Jacob Carlborg wrote:
> On 2013-11-12 09:00, Andrei Alexandrescu wrote:
>
>> Yes. Don't assume whoever disagrees with you is misinformed.
>
> I absolutely do not. But when I read this:
>
> "An argument for macros would have to do a
> lot more than 'we don't need __FILE__ etc. anymore'"
>
> I find it hard to believe anything else.
>
> http://forum.dlang.org/thread/bwsofbnigfbrxwouiobj@forum.dlang.org?page=8#post-l5p5b8:241kju:241:40digitalmars.com

It's very simple. Timon got into that part as if it were important. I pointed out it's not important.

Andrei

On 2013-11-12 09:13, Andrei Alexandrescu wrote:

> So how could we express a "no" that doesn't annoy you in the extreme? In
> case the answer would be "you haven't explained why", allow me to retort.
>
> I've mentioned the argument before: at this point we should focus on
> quality of implementation and making good use of the features we have.
> In fact I am repeating myself: http://goo.gl/1thq1j. As has been
> publicly known for a while now, our strategy has been to improve quality
> and to double down on the assets we have. People ask for a roadmap, and
> what's missing from a roadmap is as important as what's there.
>
> This is a strategy that Walter and I agree with, have been transparent
> about, and that may work or not, with various degrees of success.
> Reasonable people may disagree what the best step moving forward should
> be, but at some point some step must be made and we can't adopt your
> strategy, with which we disagree, as our strategy, just to be nice and
> not offend your sensibility. (I'm using "we" here because Walter and I
> discussed this at large.) There must be a way to say "no" that doesn't
> offend you. Please advise what that is.

Thank you for the explanation. I do understand your and Walter's position in this.

Just giving a short reason, to accompany the "no" with helps a lot. It doesn't need to be as long as the explanation above, just a sentence, like:

"no, at this time we don't want to make such a big change, we're trying to stabilize".

This is not just for me. I'm hoping proposal from others also can get a fair reason to why the "no".

-- 
/Jacob Carlborg

On 2013-11-12 09:14, Andrei Alexandrescu wrote:

> It's very simple. Timon got into that part as if it were important. I
> pointed out it's not important.

Ok, fair enough. I'm sorry for wrongly interpreting it.

-- 
/Jacob Carlborg

On 11/12/13 12:31 AM, Jacob Carlborg wrote:
> Just giving a short reason, to accompany the "no" with helps a lot. It
> doesn't need to be as long as the explanation above, just a sentence, like:
>
> "no, at this time we don't want to make such a big change, we're trying
> to stabilize".
>
> This is not just for me. I'm hoping proposal from others also can get a
> fair reason to why the "no".

OK, thanks. I'll do my best to improve on that in the future.

Andrei

On 2013-11-12 09:37, Andrei Alexandrescu wrote:

> OK, thanks. I'll do my best to improve on that in the future.

Thanks again. Sorry for being frustrated.

-- 
/Jacob Carlborg

On 11/4/2013 11:27 PM, Brian Schott wrote:
> Seriously. We don't have a real grammar for D. We have the language spec on
> dlang.org, but it isn't complete, consistent, or updated when the language
> changes. Want examples? I have a tracker for them here:
> http://d.puremagic.com/issues/show_bug.cgi?id=10233

Thank you, Brian, for finding and reporting these issues.

On 11/12/2013 09:14 AM, Andrei Alexandrescu wrote:
> On 11/12/13 12:09 AM, Jacob Carlborg wrote:
>> ...
>>
>> "An argument for macros would have to do a
>> lot more than 'we don't need __FILE__ etc. anymore'"
>>
>> ...
>
> It's very simple.  Timon got into that part as if it were important. I pointed out it's 
not important.
> ..

This is a misrepresentation. I'll just answer that post.

On 11/11/2013 12:37 AM, Andrei Alexandrescu wrote:
> On 11/10/13 3:21 PM, Timon Gehr wrote:
>> On 11/10/2013 11:43 PM, Andrei Alexandrescu wrote:
>>>>
>>>> It seems we could even get rid of __FILE__,__LINE__,__MODULE__ with AST
>>>> macros.
>>>
>>> This would be a very small advantage. The special variables hardly cause
>>> any trouble.
>>>
>>> Andrei
>>
>> The trouble is that there are too few of them to (efficiently) reflect
>> all the information about the calling context one may be interested in.
>> I don't see the point in adding them one after another in an
>> unprincipled ad-hoc fashion instead of actually thinking up a good API
>> coupled with some more expressive power.
>
> But the API would add them in exactly the same rote manner.

No, it would be (close to) exhaustive from the beginning. That is the point. I assume the problem is that there have not yet been very specific proposals.

> I really don't see an advantage here.

It's the difference between having an universal language, and a language that has a finite and fixed set of words (without any methods of combination).


> An argument for macros would have to do a
> lot more than "we don't need __FILE__ etc. anymore".
> ...

Obviously, but I was not making this argument, and as far as I can see nobody else was either.