On Thursday, 29 November 2012 at 14:17:40 UTC, Andrei Alexandrescu wrote:
>
> I think this entire approach is unprincipled (aside from solving a problem that's not urgent and not important).

Could you explain how did you determine its urgency and importance please?

> Andrei

On 11/29/12 10:17 AM, Max Samukha wrote:
> On Thursday, 29 November 2012 at 14:17:40 UTC, Andrei Alexandrescu wrote:
>>
>> I think this entire approach is unprincipled (aside from solving a
>> problem that's not urgent and not important).
>
> Could you explain how did you determine its urgency and importance please?

We have solved instances of the problem in the standard library. Please no more trick questions, thanks.

Andrei

On 27 November 2012 21:42, Walter Bright <newshound2@digitalmars.com> wrote:
> On 11/27/2012 10:37 PM, Iain Buclaw wrote:
>>
>> As far as I can tell, it's all just metadata known at compile-time only.  Nothing is written in the resultant binaries or object files produced.
>
>
> That's right. However, you can use CTFE to read those UDAs and generate results that are embedded into the object files.
>

I also see that the information is available in the codegen stage too (toElem) - I suppose this may open a door to implement compiler-specific UDAs:

["gcc.flatten"]
int foobar()
{
}


Or maybe not.... :o)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 29 November 2012 11:18, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:
> When I first read about D's CTFE capabilities, I imagined a full-fledged computing environment both at compile-time and at run-time. I thought the aim was to provide a language which can compile into its own source code, which in turn can compile into a binary. Right now I understand, that it's not the case. I certainly have no right to complain, so all I can say is that I had too high hopes. Despite a few broken hopes, D remain the #1 champion among languages.
>
>

A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Iain Buclaw:

> suppose this may open a door to implement
> compiler-specific UDAs:
>
> ["gcc.flatten"]
> int foobar()
> {
> }

Maybe an enum is better:

[GccFlags.flatten]
int foobar() {
}

Bye,
bearophile

On Thursday, 29 November 2012 at 15:23:32 UTC, Andrei Alexandrescu wrote:
> On 11/29/12 10:17 AM, Max Samukha wrote:
>> On Thursday, 29 November 2012 at 14:17:40 UTC, Andrei Alexandrescu wrote:
>>>
>>> I think this entire approach is unprincipled (aside from solving a
>>> problem that's not urgent and not important).
>>
>> Could you explain how did you determine its urgency and importance please?
>
> We have solved instances of the problem in the standard library. Please no more trick questions, thanks.

The standard library does not represent the bulk of D code. Requirements for client code are different from those for the standard library. Please don't base your opinion of importance exclusively on the experience of a limited group of D users.

>
> Andrei

On 11/29/12 12:07 PM, Max Samukha wrote:
> On Thursday, 29 November 2012 at 15:23:32 UTC, Andrei Alexandrescu wrote:
>> On 11/29/12 10:17 AM, Max Samukha wrote:
>>> On Thursday, 29 November 2012 at 14:17:40 UTC, Andrei Alexandrescu
>>> wrote:
>>>>
>>>> I think this entire approach is unprincipled (aside from solving a
>>>> problem that's not urgent and not important).
>>>
>>> Could you explain how did you determine its urgency and importance
>>> please?
>>
>> We have solved instances of the problem in the standard library.
>> Please no more trick questions, thanks.
>
> The standard library does not represent the bulk of D code. Requirements
> for client code are different from those for the standard library.
> Please don't base your opinion of importance exclusively on the
> experience of a limited group of D users.

There are plenty of patterns for solving order of initialization issues in libraries, known since time immemorial. Requiring a library initialization call would be the simplest (albeit not the most elegant). The Monostate and Singleton patterns also come to mind.

This is just not something that has no solution. Better solutions are always welcome, but keeping a baseline is always useful.


Andrei

On Thursday, 29 November 2012 at 16:51:31 UTC, Iain Buclaw wrote:
> On 27 November 2012 21:42, Walter Bright <newshound2@digitalmars.com> wrote:
>> On 11/27/2012 10:37 PM, Iain Buclaw wrote:
>>>
>>> As far as I can tell, it's all just metadata known at compile-time
>>> only.  Nothing is written in the resultant binaries or object files
>>> produced.
>>
>>
>> That's right. However, you can use CTFE to read those UDAs and generate
>> results that are embedded into the object files.
>>
>
> I also see that the information is available in the codegen stage too
> (toElem) - I suppose this may open a door to implement
> compiler-specific UDAs:
>
> ["gcc.flatten"]
> int foobar()
> {
> }
>
>
> Or maybe not.... :o)

Cowabunga ! String as attribute again.

On Thursday, 29 November 2012 at 17:35:43 UTC, Andrei Alexandrescu wrote:
> On 11/29/12 12:07 PM, Max Samukha wrote:
>> On Thursday, 29 November 2012 at 15:23:32 UTC, Andrei Alexandrescu wrote:
>>> On 11/29/12 10:17 AM, Max Samukha wrote:
>>>> On Thursday, 29 November 2012 at 14:17:40 UTC, Andrei Alexandrescu
>>>> wrote:
>>>>>
>>>>> I think this entire approach is unprincipled (aside from solving a
>>>>> problem that's not urgent and not important).
>>>>
>>>> Could you explain how did you determine its urgency and importance
>>>> please?
>>>
>>> We have solved instances of the problem in the standard library.
>>> Please no more trick questions, thanks.
>>
>> The standard library does not represent the bulk of D code. Requirements
>> for client code are different from those for the standard library.
>> Please don't base your opinion of importance exclusively on the
>> experience of a limited group of D users.
>
> There are plenty of patterns for solving order of initialization issues in libraries, known since time immemorial. Requiring a library initialization call would be the simplest (albeit not the most elegant). The Monostate and Singleton patterns also come to mind.

We know about singleton/monostate, and it is the initialization call that we want to avoid. If the patterns worked for us we'd use them.

Elegance is important. We came to D for it. Otherwise, we would stick to the inelegance of other languages. D gave us an opportunity to use something better but that something tends to break just before the homestretch.

>
> This is just not something that has no solution. Better solutions are always welcome, but keeping a baseline is always useful.
>
>
> Andrei

On 11/29/12 2:35 PM, Max Samukha wrote:
> On Thursday, 29 November 2012 at 17:35:43 UTC, Andrei Alexandrescu wrote:
>> On 11/29/12 12:07 PM, Max Samukha wrote:
>>> On Thursday, 29 November 2012 at 15:23:32 UTC, Andrei Alexandrescu
>>> wrote:
>>>> On 11/29/12 10:17 AM, Max Samukha wrote:
>>>>> On Thursday, 29 November 2012 at 14:17:40 UTC, Andrei Alexandrescu
>>>>> wrote:
>>>>>>
>>>>>> I think this entire approach is unprincipled (aside from solving a
>>>>>> problem that's not urgent and not important).
>>>>>
>>>>> Could you explain how did you determine its urgency and importance
>>>>> please?
>>>>
>>>> We have solved instances of the problem in the standard library.
>>>> Please no more trick questions, thanks.
>>>
>>> The standard library does not represent the bulk of D code. Requirements
>>> for client code are different from those for the standard library.
>>> Please don't base your opinion of importance exclusively on the
>>> experience of a limited group of D users.
>>
>> There are plenty of patterns for solving order of initialization
>> issues in libraries, known since time immemorial. Requiring a library
>> initialization call would be the simplest (albeit not the most
>> elegant). The Monostate and Singleton patterns also come to mind.
>
> We know about singleton/monostate, and it is the initialization call
> that we want to avoid. If the patterns worked for us we'd use them.

You can't say that. They do work don't they.

> Elegance is important. We came to D for it. Otherwise, we would stick to
> the inelegance of other languages. D gave us an opportunity to use
> something better but that something tends to break just before the
> homestretch.

Totally agreed. But then I look at "shared" and there's really no comparison in terms of importance and urgency.


Andrei