On 25/04/2008, Yigal Chripun <yigal100@gmail.com> wrote:
> if the compiler provides hooks for the attribute writers than an
>  attribute would have meaning for the compiler.

I don't agree. I think Walter's right. An attribute is a contract, and only the compiler is in a position to enforce that code complies with contracts.

For example, suppose I wanted an attribute that meant "this function does not modify static members" - what kind of "hooks" would make it possible to enforce that contract, if it were not built into the compiler?

Walter Bright schrieb:
> Michel Fortin wrote:
>> I presume "aborts, crashes, or hangs" should also include "asserts". 
> 
> Yes. An assert is an error that is not recoverable, so there is no need for stack unwinding.

Perhaps to get the stack trace?

Frank Benoit wrote:
> Walter Bright schrieb:
>> Michel Fortin wrote:
>>> I presume "aborts, crashes, or hangs" should also include "asserts". 
>>
>> Yes. An assert is an error that is not recoverable, so there is no need for stack unwinding.
> 
> Perhaps to get the stack trace?

Getting a stack trace doesn't require actually unwinding the stack, just looking at it.

Janice Caron wrote:
> On 25/04/2008, Yigal Chripun <yigal100@gmail.com> wrote:
>> if the compiler provides hooks for the attribute writers than an
>>  attribute would have meaning for the compiler.
> 
> I don't agree. I think Walter's right. An attribute is a contract, and only the compiler is in a position to enforce that code complies with contracts.
> 
> For example, suppose I wanted an attribute that meant "this function does not modify static members" - what kind of "hooks" would make it possible to enforce that contract, if it were not built into the compiler?

if I understand you correctly, you want a function that receives an instance of some class and an attribute that makes sure that the above function does not modify any static members (data members) of that instance.

I'm not sure how the compiler can verify that at all due to polymorphism - the dynamic type of the instance will be known only at run-time.

maybe something like the following can work:
you should be able to get a list of all the static members of an
instance via introspection and for each of those, you'd need to check in
your attribute implementation that the old value (before executing the
function body) is the same as the one after executing the function body.
what if there was a way to "keep" the old value? than you'd throw an
exception if (old(var) != var).

I don't understand how this can be checked by the compiler at all (even if the attribute is not user defined) without analyzing the entire code of the program. if you compile only one module the compiler does not know if there are derived classes that add more static data members.

I'm not sure I'm correct on all of this so please point out errors.

somewhat confused,
Yigal

On 25/04/2008, Yigal Chripun <yigal100@gmail.com> wrote:
> if I understand you correctly, you want

No, I was merely postulating. It's not something I want, it was merely an example of something the compiler could do that a library add-on couldn't.

>  I'm not sure how the compiler can verify that at all due to polymorphism
>  - the dynamic type of the instance will be known only at run-time.

Who cares? If I'm going to invent an arbitrary attribute, I can define it to do anything I want. Besides, structs have a "this", but not polymorphism, so the compiler could certainly check in the case of structs.

To give an even sillier example, a compiler could introduce a function attribute that meant "this function will not modify any variable starting with the letter x". I don't see how an add-on could do that through hooks.

Yigal Chripun wrote:
> BTW, what information does the compiler extract from an attribute?

With nothrow, for example, it can verify that the code inside the function cannot propagate an exception outside of it. I have no idea how you could do that with a user defined attribute.

Frank Benoit wrote:
> Walter Bright schrieb:
>> Michel Fortin wrote:
>>> I presume "aborts, crashes, or hangs" should also include "asserts". 
>>
>> Yes. An assert is an error that is not recoverable, so there is no need for stack unwinding.
> 
> Perhaps to get the stack trace?

Sure, but that isn't "recovering" from the error. It's just collecting diagnostic information.

Janice Caron wrote:
> On 25/04/2008, Yigal Chripun <yigal100@gmail.com> wrote:
>> if I understand you correctly, you want
> 
> No, I was merely postulating. It's not something I want, it was merely an example of something the compiler could do that a library add-on couldn't.
> 
>>  I'm not sure how the compiler can verify that at all due to polymorphism
>>  - the dynamic type of the instance will be known only at run-time.
> 
> Who cares? If I'm going to invent an arbitrary attribute, I can define it to do anything I want. Besides, structs have a "this", but not polymorphism, so the compiler could certainly check in the case of structs.
> 
> To give an even sillier example, a compiler could introduce a function attribute that meant "this function will not modify any variable starting with the letter x". I don't see how an add-on could do that through hooks.

I don't understand what you're trying to say here...
anyway, I've searched the Java docs to see How Java works with
annotations.I've found [1] which is a reflective API for build-time.
This API provides information about the source code of a program.

java 5 had a tool called apt that as of java 6 is part of the compiler, it runs annotation processors on the code. (these are Java programs that use the APIs in [1] and [2] and generate new source files)

[1]http://java.sun.com/javase/6/docs/jdk/api/apt/mirror/overview-summary.html [2]http://java.sun.com/javase/6/docs/technotes/guides/apt/index.html

--Yigal

Walter Bright wrote:
> Janice Caron wrote:
>> So I guess my question is, in what circumstance would "nothrow" be
>> helpful? And is it helpful /enough/ to warrant "polluting" all library
>> code with "nothrow" annotations?
> 
> "nothrow" is, as you say, a contract. It specifies that a function must return normally (unless it aborts, crashes, or hangs). Such annotations:
> 
> 1. improves the API documentation
> 2. enables significantly better code generation (if you use a lot of scope statements and struct destructors)
> 3. nothrow can be very useful in building up transactions, because you know that the components cannot fail
> 4. destructors cannot throw exceptions (because they are already in one). Andrei has proposed a method to deal with this, but it is as yet unimplemented.
> 
> For more info, see http://www.gotw.ca/gotw/082.htm and http://www.boost.org/community/exception_safety.html

It's a usability argument that Janice is making. She isn't saying that nothrow lacks benefits.

On Fri, 25 Apr 2008 14:10:23 -0700, Walter Bright <newshound1@digitalmars.com> wrote:

>Yigal Chripun wrote:
>> BTW, what information does the compiler extract from an attribute?
>
>With nothrow, for example, it can verify that the code inside the function cannot propagate an exception outside of it. I have no idea how you could do that with a user defined attribute.

Like in .NET. And the proposed syntax was taken from C#. A number of intrinsic attributes are treated specially by the  IL compiler. For example, DllImport, Obsolete, MarshalAs, StructLayout etc. .NET has a nice extensible attribute system. User defined attributes can be inspected through reflection at run-time.  I guess, D could allow to do that at compile time as well.