www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP6: Attributes

reply Ary Borenszweig <ary esperanto.org.ar> writes:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
Aug 01 2009
next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Ary Borenszweig escribió:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

Ouch. I meant: DIP6: Annotations.
Aug 01 2009
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sat, Aug 01, 2009 at 04:29:28PM -0300, Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

What's the difference between this and a keyword? It seems to be a keyword with a different name. For this annotation thing to be really useful, I'd think it should be well, dynamic for lack of a better word. You can just list them on an item, then inspect them later in templates: magic int a; [...] auto annotations = __traits(annotations, a); assert(annotations[0] == "magic"); // now you can do whatever with this I wished I had something like this before, but I forgot why.... But if you aren't proposing something like that being possible, then what's the point of the to a keyword? It doesn't seem to be any different. -- Adam D. Ruppe http://arsdnet.net
Aug 01 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Adam D. Ruppe escribió:
 On Sat, Aug 01, 2009 at 04:29:28PM -0300, Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

What's the difference between this and a keyword? It seems to be a keyword with a different name.

A keyword means changing the lexer, the parser and the semantic analysis. Annotations means only changing the semantic analysis (ok, changing the lexer and parser also, but just the first time to implement annotations). And if the first stage is implemented, what you describe below could also be implemented. As the DIP says, the advantage is also reducing the huge amount of keywords that exist now in the language.
 For this annotation thing to be really useful, I'd think it should be well,
 dynamic for lack of a better word.
 
 You can just list them on an item, then inspect them later in templates:
 
  magic int a;
 [...]
 
 auto annotations = __traits(annotations, a);
 
 assert(annotations[0] == "magic"); // now you can do whatever with this
 
 
 I wished I had something like this before, but I forgot why....
 
 
 
 But if you aren't proposing something like that being possible, then what's
 the point of the   to a keyword? It doesn't seem to be any different.

I could have included that in the DIP. But you have to start with small things, simple things, and evolve from that point. The DIP is just about how to start introducing annotations in the language with minimal changes to what exists now.
Aug 01 2009
prev sibling next sibling parent aarti_pl <aarti interia.pl> writes:
Ary Borenszweig pisze:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

Nice! This proposal seems to be really better (more general and extensible) than any property proposal before. BR Marcin Kuszczak (aarti_pl)
Aug 01 2009
prev sibling next sibling parent reply Tim Matthews <tim.matthews7 gmail.com> writes:
On Sat, 01 Aug 2009 16:29:28 -0300
Ary Borenszweig <ary esperanto.org.ar> wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

Are pragmas not already here for this?
Aug 01 2009
parent Robert Fraser <fraserofthenight gmail.com> writes:
Tim Matthews wrote:
 On Sat, 01 Aug 2009 16:29:28 -0300
 Ary Borenszweig <ary esperanto.org.ar> wrote:
 
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

Are pragmas not already here for this?

Nope, they're for compiler-specific extensions
Aug 01 2009
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

I think annotations are a good idea, but turning keywords already in the language into annotations seems kinda pointless & would kill backwards compatibility. In C#/Java some things are modifiers while others are annotations -- and with good reason. IMO, the focus of annotations should be mostly on things _external_ to the compiler. So, serializability, thread safety, etc. Really, I think annotations should be for compile-time reflection (so like someone else said __traits(annotations, symbol) should return a tuple of annotation structs.
Aug 01 2009
next sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Robert Fraser wrote:
 Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

I think annotations are a good idea, but turning keywords already in the language into annotations seems kinda pointless & would kill backwards compatibility. In C#/Java some things are modifiers while others are annotations -- and with good reason. IMO, the focus of annotations should be mostly on things _external_ to the compiler. So, serializability, thread safety, etc. Really, I think annotations should be for compile-time reflection (so like someone else said __traits(annotations, symbol) should return a tuple of annotation structs.

Seconded. Annotations sound like a useful feature especially if they can be created and manipulated by the programmer, which would require syntactic distinction. I never did much care for java's annotation syntax, but I do think turning most if not all of the keywords mentioned into annotations is a good idea, at least behind the scenes. Off the top of my head, it could solve the function <-> delegate ref parameter problem.
Aug 01 2009
prev sibling parent reply Max Samukha <spambox d-coding.com> writes:
On Sat, 01 Aug 2009 15:24:26 -0700, Robert Fraser
<fraserofthenight gmail.com> wrote:

Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

I think annotations are a good idea, but turning keywords already in the language into annotations seems kinda pointless & would kill backwards compatibility. In C#/Java some things are modifiers while others are annotations -- and with good reason. IMO, the focus of annotations should be mostly on things _external_ to the compiler. So, serializability, thread safety, etc. Really, I think annotations should be for compile-time reflection (so like someone else said __traits(annotations, symbol) should return a tuple of annotation structs.

Please not a tuple of structs but a tuple of tuples. One should be able to specify types and aliases as annotation parameters.
Aug 02 2009
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Max Samukha wrote:
 On Sat, 01 Aug 2009 15:24:26 -0700, Robert Fraser
 <fraserofthenight gmail.com> wrote:
 
 Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

language into annotations seems kinda pointless & would kill backwards compatibility. In C#/Java some things are modifiers while others are annotations -- and with good reason. IMO, the focus of annotations should be mostly on things _external_ to the compiler. So, serializability, thread safety, etc. Really, I think annotations should be for compile-time reflection (so like someone else said __traits(annotations, symbol) should return a tuple of annotation structs.

Please not a tuple of structs but a tuple of tuples. One should be able to specify types and aliases as annotation parameters.

I wish that's work, but Tuples flatten themselves.
Aug 02 2009
parent Max Samukha <spambox d-coding.com> writes:
On Sun, 02 Aug 2009 07:54:49 -0700, Robert Fraser
<fraserofthenight gmail.com> wrote:

Max Samukha wrote:
 On Sat, 01 Aug 2009 15:24:26 -0700, Robert Fraser
 <fraserofthenight gmail.com> wrote:
 
 Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

language into annotations seems kinda pointless & would kill backwards compatibility. In C#/Java some things are modifiers while others are annotations -- and with good reason. IMO, the focus of annotations should be mostly on things _external_ to the compiler. So, serializability, thread safety, etc. Really, I think annotations should be for compile-time reflection (so like someone else said __traits(annotations, symbol) should return a tuple of annotation structs.

Please not a tuple of structs but a tuple of tuples. One should be able to specify types and aliases as annotation parameters.

I wish that's work, but Tuples flatten themselves.

Yes, but we can define a non-flattening tuple: template CannedTuple(A...) { alias A tuple; } Then we can have tuples of tuples: alias Tuple!(CannedTuple!(...), CannedTuple!(...), ...) annotations; // I guess, the first element should be the annotation name? enum annotationName = annotations[0].tuple[0]; We already can emulate custom attributes with mixins, though this requires template trickery that sometimes is overwhelming. So some syntax sugar would be welcome.
Aug 02 2009
prev sibling next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Ary Borenszweig, el  1 de agosto a las 16:29 me escribiste:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

Please, try to post at least the abstract of the DIP with the link, so people can easily know what is it about =) And when writing a DIP, try to make the abstract a little more descriptive. From an abstract you should be able to tell what the DIP is about (in this case explain what an annotation is at least). A oneliner is not good enough, that's just a title, not an abstract. If it's too hard to explain, try to provide a link to somewhere else where the terms are described. The rationale can be a little more descriptive too. What are the advantages of removing keywords for example? Use NG posts links if you have some problems documented there, for example. Try not to explain your opinion in DIPs. They are not NG posts, they should provide facts and be as objective as possible. Even when that's pretty hard, saying "I prefer Java's one because ..." is excessively subjective. Avoid doing that. You can express the same by saying something like "Java syntax has the advantage of ..." for example. A section called "Other thoughts" is not very serious either. If you are not yet convinced about something in the DIP, post it in the announcement post in the NG so it can be discussed and added later to the DIP when the idea is in better shape. Please, don't take this personally, I just want DIPs to be high quality, otherwise they will never be taken seriously. =) I've added this information in a Recommendations subsection to the DIP1, see: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP1#Recommendations I'll address the DIP itself in another post ;) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- HOMBRE DESNUDO AMENAZA A LOS VECINOS CON UNA "KATANA" DESDE SU BALCON -- Crónica TV
Aug 01 2009
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Leandro Lucarella, el  1 de agosto a las 20:28 me escribiste:
 Ary Borenszweig, el  1 de agosto a las 16:29 me escribiste:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

Please, try to post at least the abstract of the DIP with the link, so people can easily know what is it about =)

BTW, you forgot to link the DIP to the DIPs index: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs It's linked now... =) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Home, home again. I like to be here when I can. When I come home cold and tired It's good to warm my bones beside the fire.
Aug 01 2009
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Leandro Lucarella escribió:
 Ary Borenszweig, el  1 de agosto a las 16:29 me escribiste:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

Please, try to post at least the abstract of the DIP with the link, so people can easily know what is it about =) And when writing a DIP, try to make the abstract a little more descriptive. From an abstract you should be able to tell what the DIP is about (in this case explain what an annotation is at least). A oneliner is not good enough, that's just a title, not an abstract. If it's too hard to explain, try to provide a link to somewhere else where the terms are described. The rationale can be a little more descriptive too. What are the advantages of removing keywords for example? Use NG posts links if you have some problems documented there, for example. Try not to explain your opinion in DIPs. They are not NG posts, they should provide facts and be as objective as possible. Even when that's pretty hard, saying "I prefer Java's one because ..." is excessively subjective. Avoid doing that. You can express the same by saying something like "Java syntax has the advantage of ..." for example. A section called "Other thoughts" is not very serious either. If you are not yet convinced about something in the DIP, post it in the announcement post in the NG so it can be discussed and added later to the DIP when the idea is in better shape. Please, don't take this personally, I just want DIPs to be high quality, otherwise they will never be taken seriously. =) I've added this information in a Recommendations subsection to the DIP1, see: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP1#Recommendations I'll address the DIP itself in another post ;)

Hola Leandro, I've updated the DIP page with your recommendations. I agree with all of them. Please, can someone (pst, bearophile) check that what I found as decorators in Pyhton are what we are calling annotations here? Thanks!
Aug 01 2009
next sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Ary Borenszweig wrote:
 Leandro Lucarella escribió:
 Ary Borenszweig, el  1 de agosto a las 16:29 me escribiste:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

Please, try to post at least the abstract of the DIP with the link, so people can easily know what is it about =) And when writing a DIP, try to make the abstract a little more descriptive. From an abstract you should be able to tell what the DIP is about (in this case explain what an annotation is at least). A oneliner is not good enough, that's just a title, not an abstract. If it's too hard to explain, try to provide a link to somewhere else where the terms are described. The rationale can be a little more descriptive too. What are the advantages of removing keywords for example? Use NG posts links if you have some problems documented there, for example. Try not to explain your opinion in DIPs. They are not NG posts, they should provide facts and be as objective as possible. Even when that's pretty hard, saying "I prefer Java's one because ..." is excessively subjective. Avoid doing that. You can express the same by saying something like "Java syntax has the advantage of ..." for example. A section called "Other thoughts" is not very serious either. If you are not yet convinced about something in the DIP, post it in the announcement post in the NG so it can be discussed and added later to the DIP when the idea is in better shape. Please, don't take this personally, I just want DIPs to be high quality, otherwise they will never be taken seriously. =) I've added this information in a Recommendations subsection to the DIP1, see: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP1#Recommendations I'll address the DIP itself in another post ;)

Hola Leandro, I've updated the DIP page with your recommendations. I agree with all of them. Please, can someone (pst, bearophile) check that what I found as decorators in Pyhton are what we are calling annotations here? Thanks!

They aren't. Decorators are deep crazy magic. As I recall, mydecorator def myfunc(argsnjunk): pass transforms all calls to myfunc to a call to a function you defined somewhere named mydecorator, which takes a function and its arguments as parameters and returns a function which is expected to call the function with its arguments. Then the returned function gets called. Very nifty for a wide variety of things.
Aug 01 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Ary Borenszweig, el  2 de agosto a las 00:07 me escribiste:
 Leandro Lucarella escribió:
Ary Borenszweig, el  1 de agosto a las 16:29 me escribiste:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

people can easily know what is it about =) And when writing a DIP, try to make the abstract a little more descriptive. From an abstract you should be able to tell what the DIP is about (in this case explain what an annotation is at least). A oneliner is not good enough, that's just a title, not an abstract. If it's too hard to explain, try to provide a link to somewhere else where the terms are described. The rationale can be a little more descriptive too. What are the advantages of removing keywords for example? Use NG posts links if you have some problems documented there, for example. Try not to explain your opinion in DIPs. They are not NG posts, they should provide facts and be as objective as possible. Even when that's pretty hard, saying "I prefer Java's one because ..." is excessively subjective. Avoid doing that. You can express the same by saying something like "Java syntax has the advantage of ..." for example. A section called "Other thoughts" is not very serious either. If you are not yet convinced about something in the DIP, post it in the announcement post in the NG so it can be discussed and added later to the DIP when the idea is in better shape. Please, don't take this personally, I just want DIPs to be high quality, otherwise they will never be taken seriously. =) I've added this information in a Recommendations subsection to the DIP1, see: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP1#Recommendations I'll address the DIP itself in another post ;)

Hola Leandro, I've updated the DIP page with your recommendations. I agree with all of them.

Thanks! -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- "Somos testigos de Jaimito, venimos a traer la salvación, el mundo va a desaparecer, somos testigos de Jaimito!". Nos enyoguizamos... Así que "somos testigos"? Te dejo el culo hecho un vino, y la conch'itumá, y la conch'itumá! -- Sidharta Kiwi
Aug 02 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Ary Borenszweig, el  1 de agosto a las 16:29 me escribiste:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

I really think that D should support some kind of annotations. I think it's a good idea to add them in stages. I could add that in the first stage, old-style attributes/whatever (override, deprecated, etc.) should be accepted too (i.e. without the leading ). Then people complaining about backward compatibility can be happy (me included; hey! I'll add them to D1.1 too! ;). New syntax can make use of annotations though (hello properties!). I think annotations in D can reach their peak of utility when AST macros get implemented. I think it would be great being able to "register" annotation handlers to the compiler to do arbitrary transformations to the code. You could even move a big part of the compiler implementation to library code using annotations and AST macros. But this have to come in other stages for sure. I think changing the FE to allow annotation syntax wouldn't be very hard (I'm guessing, I never hacked the DMDFE myself). Maybe someone who played with the FE can make a quick patch as a proof of concepts, even if the implementation ignores the annotations completely for now it can be a good start. I think the "Other thoughts" section should be official part of the proposal if there is any intention to move most of the current attribute keywords to annotations. About the version(X) {} else {}, first, version(!X) could be supported as an ugly hack =P. A more generic approach could be to support annotations returns. Annotations could return void (in which case the else statement is a *semantic* error) or bool (in which case the else statement is supported). The problem with this is that statements should be target for annotations too, so one can do: deprecated void foo() { version(Foo) writeln("foo"); } Maybe this one should be delayed for a second stage of annotations =) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- CHINO ATRAPA COTORRAS -- Crónica TV
Aug 01 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Aug 1, 2009 at 11:27 PM, Ellery
Newcomer<ellery-newcomer utulsa.edu> wrote:
 They aren't. Decorators are deep crazy magic. As I recall,

  mydecorator
 def myfunc(argsnjunk):
 =A0 =A0pass

 transforms all calls to myfunc to a call to a function you defined
 somewhere named mydecorator, which takes a function and its arguments as
 parameters and returns a function which is expected to call the function
 with its arguments. Then the returned function gets called.

Close, but not quite. What instead happens is that this gets transformed into something like: myfunc =3D mydecorator()(lambda(argsnjunk): pass) That is, mydecorator() returns a callable; that callable takes the function that you're defining as its argument, potentially modifies or transforms it, then returns either the same function or anything else, which is finally stored in myfunc. Calls to myfunc are not transformed at all; all that has happened is that the decorator has intercepted the function definition, and might have replaced the original function with a new one.
Aug 01 2009
prev sibling next sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

I like this. Metadata is a very useful thing.
Aug 02 2009
prev sibling next sibling parent reply grauzone <none example.net> writes:
Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

The next step would be to introduce user defined annotations. I propose this: //-------------- //declaring a user defined annotation type annotation struct MyAnnotation { int x; char[] y; SubAnnotation sub; } struct SubAnnotation { int x; } //use the annotation on SomeType MyAnnotation(123, "456", SubAnnotation(789)) class SomeType { } //reading user defined annotations void foo() { foreach (t; __traits(getAnnotations, SomeType) { //t is a value of the annotation type //SomeType is only annotated with MyAnnotation static assert(is(typeof(t) == MyAnnotation)); //can read out the annotation values assert(t.y == "456"); } } //-------------- Using annotation on a type introduces the type name into the annotation namespace. This means the type can be used as annotation on other types. The annotation declaration is parsed as if you'd define a compile time constant using the expression following the , e.g. "const c = MyAnnotation(123, [...]);" This means the is actually just followed by an expression, that actually uses opCall() (in this case opCall is autogenerated by the compiler). The expression is evaluated using CTFE. Note that compile time annotations (like override, property) still can collide with user defined types, but only if those types are marked by annotation. (Actually, compile time annotations can be normal types declared in object.d.) __traits(getAnnotations, SomeType) returns a tuple containing the values of all annotations applied to a type. In other words, the result of the CTFE execution of each annotation. Any thoughts? PS: I wouldn't use annotations for all attribute keywords (like override, final, pure, ...). Some keywords should be left as they are. Only seldom used and/or new keywords should be introduced as annotations (for example deprecated or __gshared [there's a type on the DIP page btw.]). PPS: shoudl annotations follow the normal D attribute syntax? E.g. allow this: someannotation declaration; someannotation { declaration1; declaration2; } someannotation: declaration1; declaration2;
Aug 02 2009
parent reply yigal chripun <yigal100 gmail.com> writes:
grauzone Wrote:

 Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

The next step would be to introduce user defined annotations. I propose this: //-------------- //declaring a user defined annotation type annotation struct MyAnnotation { int x; char[] y; SubAnnotation sub; } struct SubAnnotation { int x; } //use the annotation on SomeType MyAnnotation(123, "456", SubAnnotation(789)) class SomeType { } //reading user defined annotations void foo() { foreach (t; __traits(getAnnotations, SomeType) { //t is a value of the annotation type //SomeType is only annotated with MyAnnotation static assert(is(typeof(t) == MyAnnotation)); //can read out the annotation values assert(t.y == "456"); } } //-------------- Using annotation on a type introduces the type name into the annotation namespace. This means the type can be used as annotation on other types. The annotation declaration is parsed as if you'd define a compile time constant using the expression following the , e.g. "const c = MyAnnotation(123, [...]);" This means the is actually just followed by an expression, that actually uses opCall() (in this case opCall is autogenerated by the compiler). The expression is evaluated using CTFE. Note that compile time annotations (like override, property) still can collide with user defined types, but only if those types are marked by annotation. (Actually, compile time annotations can be normal types declared in object.d.) __traits(getAnnotations, SomeType) returns a tuple containing the values of all annotations applied to a type. In other words, the result of the CTFE execution of each annotation. Any thoughts? PS: I wouldn't use annotations for all attribute keywords (like override, final, pure, ...). Some keywords should be left as they are. Only seldom used and/or new keywords should be introduced as annotations (for example deprecated or __gshared [there's a type on the DIP page btw.]). PPS: shoudl annotations follow the normal D attribute syntax? E.g. allow this: someannotation declaration; someannotation { declaration1; declaration2; } someannotation: declaration1; declaration2;

this is a good start but as already noted by others, you can't specify types with structs. we also can't use type tuples cause of the auto flatten behavior. the type tuple issue needs to be fixed and perhaps we can introduce type variables. something like: type t = int; other thoughts on the subject: the user should be able to specify the lifetime of the annotations, compile-time vs. run-time.
Aug 03 2009
parent reply grauzone <none example.net> writes:
yigal chripun wrote:
 this is a good start but as already noted by others, you can't specify types
with structs. we also can't use type tuples cause of the auto flatten behavior. 

And why can't we use structs? Unless I've missed something, it wasn't explained in this thread.
Aug 03 2009
parent reply Kagamin <spam here.lot> writes:
grauzone Wrote:

 yigal chripun wrote:
 this is a good start but as already noted by others, you can't specify types
with structs. we also can't use type tuples cause of the auto flatten behavior. 

And why can't we use structs? Unless I've missed something, it wasn't explained in this thread.

inheritance?
Aug 03 2009
parent grauzone <none example.net> writes:
Kagamin wrote:
 grauzone Wrote:
 
 yigal chripun wrote:
 this is a good start but as already noted by others, you can't specify types
with structs. we also can't use type tuples cause of the auto flatten behavior. 

explained in this thread.

inheritance?

You want to inherit annotations? What for?
Aug 03 2009
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

This looks like a solution in search of a problem. What's the problem being solved?
Aug 03 2009
next sibling parent reply grauzone <none example.net> writes:
Don wrote:
 Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

This looks like a solution in search of a problem. What's the problem being solved?

Attaching additional data to types, that can't be specified otherwhere. This should help with metaprogramming-like stuff. For example serialization. How do you specify that a field shouldn't be part of the serialized data? Java has an extra keyword attribute like "transient" (comes from before attributes were introduced). C# uses what we call annotation in this thread. How would you do this in D?
Aug 03 2009
next sibling parent reply Don <nospam nospam.com> writes:
grauzone wrote:
 Don wrote:
 Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

This looks like a solution in search of a problem. What's the problem being solved?

Attaching additional data to types, that can't be specified otherwhere. This should help with metaprogramming-like stuff. For example serialization. How do you specify that a field shouldn't be part of the serialized data? Java has an extra keyword attribute like "transient" (comes from before attributes were introduced). C# uses what we call annotation in this thread. How would you do this in D?

I agree that there doesn't seem to be a nice way at present. One possibility would be to establish a naming convention for transient fields -- a Ruby-style solution, I guess. But are annotations actually an ideal solution for this problem? Presumably, you'll have to specify that somewhere else anyway. I mean, during reading it will need to either be initialized separately after serialisation (like opPostBlit, perhaps?), or else remain uninitialized. Serialisation seems to be _extremely_ similar to construction. I'm not sure that annotations capture that. D has much more powerful metaprogramming than C# or Java, so my intuition and hope is that we shouldn't need to adopt hacks from those weaker languages. The annotation syntax in C# and Java looks like an ugly hack to me. Purely a subjective opinion, of course, but it seems really out of place in a C-family language.
Aug 03 2009
next sibling parent Kagamin <spam here.lot> writes:
Don Wrote:

 I agree that there doesn't seem to be a nice way at present. One 
 possibility would be to establish a naming convention for transient 
 fields -- a Ruby-style solution, I guess.
 
 But are annotations actually an ideal solution for this problem?
 Presumably, you'll have to specify that somewhere else anyway. I mean, 
 during reading it will need to either be initialized separately after 
 serialisation (like opPostBlit, perhaps?), or else remain uninitialized. 
 Serialisation seems to be _extremely_ similar to construction. I'm not 
 sure that annotations capture that.
 
 D has much more powerful metaprogramming than C# or Java, so my 
 intuition and hope is that we shouldn't need to adopt hacks from those 
 weaker languages. The annotation syntax in C# and Java looks like an 
 ugly hack to me. Purely a subjective opinion, of course, but it seems 
 really out of place in a C-family language.

Here you considered functionality of only one attribute, XmlIgnoreAttribute. XML serialization in .net framework uses 17 attributes. For example you can serialize a field as an XML element or an XML attribute, how do you plan to handle this?
Aug 03 2009
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Don escribió:
 grauzone wrote:
 Don wrote:
 Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

This looks like a solution in search of a problem. What's the problem being solved?

Attaching additional data to types, that can't be specified otherwhere. This should help with metaprogramming-like stuff. For example serialization. How do you specify that a field shouldn't be part of the serialized data? Java has an extra keyword attribute like "transient" (comes from before attributes were introduced). C# uses what we call annotation in this thread. How would you do this in D?

I agree that there doesn't seem to be a nice way at present. One possibility would be to establish a naming convention for transient fields -- a Ruby-style solution, I guess. But are annotations actually an ideal solution for this problem? Presumably, you'll have to specify that somewhere else anyway. I mean, during reading it will need to either be initialized separately after serialisation (like opPostBlit, perhaps?), or else remain uninitialized. Serialisation seems to be _extremely_ similar to construction. I'm not sure that annotations capture that. D has much more powerful metaprogramming than C# or Java, so my intuition and hope is that we shouldn't need to adopt hacks from those weaker languages. The annotation syntax in C# and Java looks like an ugly hack to me. Purely a subjective opinion, of course, but it seems really out of place in a C-family language.

Attributes has many, many other uses. Appart from serialization, you could specify how a field is stored in a database. How a method maps to an http request (post, get, which parameters to bind to the request, etc.). Whether a method should do security checks before executing. Whether a method should be run as a test, and what's the expected exception to be thrown. [insert your usage here]
Aug 03 2009
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Ary Borenszweig, el  3 de agosto a las 11:14 me escribiste:
annotation syntax in C# and Java looks like an ugly hack to me. Purely a 
subjective opinion, of course, but it seems really out of place in a C-family 
language.

Attributes has many, many other uses. Appart from serialization, you could specify how a field is stored in a database. How a method maps to an http request (post, get, which parameters to bind to the request, etc.). Whether a method should do security checks before executing. Whether a method should be run as a test, and what's the expected exception to be thrown. [insert your usage here]

It's easy to support some sort of primitive-explicit AOP[1] too. It's very used in Python. For example I've implemented the synchronized "attribute" in Python using decorators (annotations). [1] http://en.wikipedia.org/wiki/Aspect-oriented_programming -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- I love las minifaldas on Esmeralda And the sexy porteños trying to pick up the Argenteenagers. How nice, the Argenteenagers Tomando sol in the primavera de Buenos Aires...
Aug 03 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Ary Borenszweig wrote:
 Don escribió:
 grauzone wrote:
 Don wrote:
 Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

This looks like a solution in search of a problem. What's the problem being solved?

Attaching additional data to types, that can't be specified otherwhere. This should help with metaprogramming-like stuff. For example serialization. How do you specify that a field shouldn't be part of the serialized data? Java has an extra keyword attribute like "transient" (comes from before attributes were introduced). C# uses what we call annotation in this thread. How would you do this in D?

I agree that there doesn't seem to be a nice way at present. One possibility would be to establish a naming convention for transient fields -- a Ruby-style solution, I guess. But are annotations actually an ideal solution for this problem? Presumably, you'll have to specify that somewhere else anyway. I mean, during reading it will need to either be initialized separately after serialisation (like opPostBlit, perhaps?), or else remain uninitialized. Serialisation seems to be _extremely_ similar to construction. I'm not sure that annotations capture that. D has much more powerful metaprogramming than C# or Java, so my intuition and hope is that we shouldn't need to adopt hacks from those weaker languages. The annotation syntax in C# and Java looks like an ugly hack to me. Purely a subjective opinion, of course, but it seems really out of place in a C-family language.

Attributes has many, many other uses. Appart from serialization, you could specify how a field is stored in a database. How a method maps to an http request (post, get, which parameters to bind to the request, etc.). Whether a method should do security checks before executing. Whether a method should be run as a test, and what's the expected exception to be thrown. [insert your usage here]

Great, you've answered my question. That should be in the DIP, instead of the vague stuff that's in there now -- the existing DIP is about replacing keywords, which is very unconvincing. (It doesn't work, actually -- the name mangling is important for most of the keywords mentioned).
Aug 03 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Don wrote:
 Ary Borenszweig wrote:
 Don escribió:
 grauzone wrote:
 Don wrote:
 Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

This looks like a solution in search of a problem. What's the problem being solved?

Attaching additional data to types, that can't be specified otherwhere. This should help with metaprogramming-like stuff. For example serialization. How do you specify that a field shouldn't be part of the serialized data? Java has an extra keyword attribute like "transient" (comes from before attributes were introduced). C# uses what we call annotation in this thread. How would you do this in D?

I agree that there doesn't seem to be a nice way at present. One possibility would be to establish a naming convention for transient fields -- a Ruby-style solution, I guess. But are annotations actually an ideal solution for this problem? Presumably, you'll have to specify that somewhere else anyway. I mean, during reading it will need to either be initialized separately after serialisation (like opPostBlit, perhaps?), or else remain uninitialized. Serialisation seems to be _extremely_ similar to construction. I'm not sure that annotations capture that. D has much more powerful metaprogramming than C# or Java, so my intuition and hope is that we shouldn't need to adopt hacks from those weaker languages. The annotation syntax in C# and Java looks like an ugly hack to me. Purely a subjective opinion, of course, but it seems really out of place in a C-family language.

Attributes has many, many other uses. Appart from serialization, you could specify how a field is stored in a database. How a method maps to an http request (post, get, which parameters to bind to the request, etc.). Whether a method should do security checks before executing. Whether a method should be run as a test, and what's the expected exception to be thrown. [insert your usage here]

Great, you've answered my question. That should be in the DIP, instead of the vague stuff that's in there now -- the existing DIP is about replacing keywords, which is very unconvincing. (It doesn't work, actually -- the name mangling is important for most of the keywords mentioned).

But the DIP I wrote isn't about general-purpose annotations. It's just the first step. Are "pure" and "nothrow" part of the mangling? Or which are? I thought not. Can you overload a pure and a not-pure function with the same parameter count and types? Anyway, I'll write some more about attributes in the abstract or rationale.
Aug 03 2009
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Steven Schveighoffer, el  3 de agosto a las 11:53 me escribiste:
But the DIP I wrote isn't about general-purpose annotations. It's just the 
first step. Are "pure" and "nothrow" part of the mangling? Or which are? I 
thought not. Can you overload a pure and a not-pure function with the same 
parameter count and types?

Yes, they have to be. There are reasons besides overloading for including other attributes in the naming. For example, if a function is pure, then becomes unpure, you don't existing code that is expecting a pure function to link against it. In other words, the linker is dumb. It only knows how to match symbols, so you have to embed into the symbols the important pieces of the interface that you want the linker to consider important. To answer Don's point, there is nothing saying that the compiler can't read attributes and change its behavior. Of course, those would have to be builtin attributes. My opinion on removing existing keywords is -- don't. There's little to no gain. Let that ship sail, and concentrate on future keyword proposals.

I think old keywords can be maintained for backward compatibility but deprecated (allowing using both "naked" keywords or "annotations"), favoring the usage of annoatations where sensible. In a far far future, the old keywords can be removed if annotations prove to be a success. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Novocaine for the soul you better give me something to fill the hole before I sputter out
Aug 03 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Steven Schveighoffer wrote:
 On Mon, 03 Aug 2009 11:42:33 -0400, Ary Borenszweig 
 <ary esperanto.org.ar> wrote:
 
 Don wrote:
 Ary Borenszweig wrote:
 Don escribió:
 grauzone wrote:
 Don wrote:
 Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

This looks like a solution in search of a problem. What's the problem being solved?

Attaching additional data to types, that can't be specified otherwhere. This should help with metaprogramming-like stuff. For example serialization. How do you specify that a field shouldn't be part of the serialized data? Java has an extra keyword attribute like "transient" (comes from before attributes were introduced). C# uses what we call annotation in this thread. How would you do this in D?

I agree that there doesn't seem to be a nice way at present. One possibility would be to establish a naming convention for transient fields -- a Ruby-style solution, I guess. But are annotations actually an ideal solution for this problem? Presumably, you'll have to specify that somewhere else anyway. I mean, during reading it will need to either be initialized separately after serialisation (like opPostBlit, perhaps?), or else remain uninitialized. Serialisation seems to be _extremely_ similar to construction. I'm not sure that annotations capture that. D has much more powerful metaprogramming than C# or Java, so my intuition and hope is that we shouldn't need to adopt hacks from those weaker languages. The annotation syntax in C# and Java looks like an ugly hack to me. Purely a subjective opinion, of course, but it seems really out of place in a C-family language.

Attributes has many, many other uses. Appart from serialization, you could specify how a field is stored in a database. How a method maps to an http request (post, get, which parameters to bind to the request, etc.). Whether a method should do security checks before executing. Whether a method should be run as a test, and what's the expected exception to be thrown. [insert your usage here]

instead of the vague stuff that's in there now -- the existing DIP is about replacing keywords, which is very unconvincing. (It doesn't work, actually -- the name mangling is important for most of the keywords mentioned).

But the DIP I wrote isn't about general-purpose annotations. It's just the first step. Are "pure" and "nothrow" part of the mangling? Or which are? I thought not. Can you overload a pure and a not-pure function with the same parameter count and types?

Yes, they have to be. There are reasons besides overloading for including other attributes in the naming. For example, if a function is pure, then becomes unpure, you don't existing code that is expecting a pure function to link against it. In other words, the linker is dumb. It only knows how to match symbols, so you have to embed into the symbols the important pieces of the interface that you want the linker to consider important.

A question: in C#/Java, can you have annotations on function pointer and delegate declarations? void foo( int delegate(int) pure dg) { ... } What would this look like with annotations? (The underlying question is, how do annotations interact with the type system?)
 To answer Don's point, there is nothing saying that the compiler can't 
 read attributes and change its behavior.  Of course, those would have to 
 be builtin attributes.

Yes, but then they're just keywords, with an in front. You'd just be kidding yourself if you think you've reduced the keyword count.
 My opinion on removing existing keywords is -- don't.  There's little to 
 no gain.  Let that ship sail, and concentrate on future keyword proposals.
 
 -Steve

Aug 04 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Don wrote:
 ...
 
 A question: in C#/Java, can you have annotations on function pointer and
 delegate declarations?
 
 void foo( int delegate(int) pure dg) {
   ...
 }
 What would this look like with annotations?

Well, Java doesn't HAVE delegates and C# doesn't (AFAIK) allow you to define them inline; they have a special declaration syntax that can't be used in an expression. C# would probably look something like: namespace Blech { [Pure] public delegate int Moo(int); public class Urk { public static void foo(Moo dg) { ... } } }
 (The underlying question is, how do annotations interact with the type
 system?)

I don't think they form part of the type; they're just sort of attached to that particular declaration.
 To answer Don's point, there is nothing saying that the compiler can't
 read attributes and change its behavior.  Of course, those would have
 to be builtin attributes.

Yes, but then they're just keywords, with an in front. You'd just be kidding yourself if you think you've reduced the keyword count.

I suspect the reasoning goes like this: * I want attributes. Walter doesn't see the use. * Walter complains about adding keywords. * I can make keywords look like attributes, and then I get attributes! :P
 My opinion on removing existing keywords is -- don't.  There's little
 to no gain.  Let that ship sail, and concentrate on future keyword
 proposals.

 -Steve


Aug 04 2009
next sibling parent reply grauzone <none example.net> writes:
Daniel Keep wrote:
 Yes, but then they're just keywords, with an   in front. You'd just be
 kidding yourself if you think you've reduced the keyword count.

I suspect the reasoning goes like this: * I want attributes. Walter doesn't see the use. * Walter complains about adding keywords. * I can make keywords look like attributes, and then I get attributes! :P

The idea is just stolen from C#/Java. I guess the idea is that 1. keywords/annotations are in a different namespace and 2. even compile time "keyword" annotations can be handled as normal identifiers. The second point means introducing a new keyword is like declaring a new identifier in object.d. But it would also allow users shadowing annotation "keywords" by defining their own annotations, which might be a problem or not.
Aug 04 2009
parent yigal chripun <yigal100 gmail.com> writes:
grauzone Wrote:

 Daniel Keep wrote:
 Yes, but then they're just keywords, with an   in front. You'd just be
 kidding yourself if you think you've reduced the keyword count.

I suspect the reasoning goes like this: * I want attributes. Walter doesn't see the use. * Walter complains about adding keywords. * I can make keywords look like attributes, and then I get attributes! :P

The idea is just stolen from C#/Java. I guess the idea is that 1. keywords/annotations are in a different namespace and 2. even compile time "keyword" annotations can be handled as normal identifiers. The second point means introducing a new keyword is like declaring a new identifier in object.d. But it would also allow users shadowing annotation "keywords" by defining their own annotations, which might be a problem or not.

IIRC, in C# you can use keywords as identifiers. int if = 3; // this is a variable called "if" the in C# is a way to tell the parser - "don't treat this as a keyword".
Aug 04 2009
prev sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:

 Don wrote:
 ...
 
 A question: in C#/Java, can you have annotations on function pointer and
 delegate declarations?
 
 void foo( int delegate(int) pure dg) {
   ...
 }
 What would this look like with annotations?

Well, Java doesn't HAVE delegates and C# doesn't (AFAIK) allow you to define them inline; they have a special declaration syntax that can't be used in an expression.

C#: List<int> ls; ls.Sort((x, y) => y - x); or ls.Sort((x, y) => { int a; a = y; a -= x; return a; });
Aug 04 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Sergey Gromov wrote:
 Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:
 
 Don wrote:
 ...

 A question: in C#/Java, can you have annotations on function pointer and
 delegate declarations?

 void foo( int delegate(int) pure dg) {
   ...
 }
 What would this look like with annotations?

define them inline; they have a special declaration syntax that can't be used in an expression.

C#: List<int> ls; ls.Sort((x, y) => y - x); or ls.Sort((x, y) => { int a; a = y; a -= x; return a; });

That's not a delegate type, that's a delegate literal.
Aug 04 2009
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Tue, 04 Aug 2009 22:46:22 +1000, Daniel Keep wrote:

 Sergey Gromov wrote:
 Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:
 
 Don wrote:
 ...

 A question: in C#/Java, can you have annotations on function pointer and
 delegate declarations?

 void foo( int delegate(int) pure dg) {
   ...
 }
 What would this look like with annotations?

define them inline; they have a special declaration syntax that can't be used in an expression.

C#: List<int> ls; ls.Sort((x, y) => y - x); or ls.Sort((x, y) => { int a; a = y; a -= x; return a; });

That's not a delegate type, that's a delegate literal.

Sorry, you said: "C# doesn't ... allow you to define them (delegates) inline". Delegate literal *is* an inline definition of a delegate. What you say now is that C# doesn't allow to define a delegate type inside a function which is definitely true and is very annoying.
Aug 04 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Sergey Gromov wrote:
 Tue, 04 Aug 2009 22:46:22 +1000, Daniel Keep wrote:
 
 Sergey Gromov wrote:
 Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:

 Don wrote:
 ...

 A question: in C#/Java, can you have annotations on function pointer and
 delegate declarations?

 void foo( int delegate(int) pure dg) {
   ...
 }
 What would this look like with annotations?

define them inline; they have a special declaration syntax that can't be used in an expression.

List<int> ls; ls.Sort((x, y) => y - x); or ls.Sort((x, y) => { int a; a = y; a -= x; return a; });


Sorry, you said: "C# doesn't ... allow you to define them (delegates) inline". Delegate literal *is* an inline definition of a delegate. What you say now is that C# doesn't allow to define a delegate type inside a function which is definitely true and is very annoying.

Have you seen the Func delegates? They are exactly for that. The above example would be: void foo(Func<int, int> dg) { ... }
Aug 04 2009
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Tue, 04 Aug 2009 11:58:27 -0300, Ary Borenszweig wrote:

 Sergey Gromov wrote:
 Tue, 04 Aug 2009 22:46:22 +1000, Daniel Keep wrote:
 
 Sergey Gromov wrote:
 Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:

 Don wrote:
 ...

 A question: in C#/Java, can you have annotations on function pointer and
 delegate declarations?

 void foo( int delegate(int) pure dg) {
   ...
 }
 What would this look like with annotations?

define them inline; they have a special declaration syntax that can't be used in an expression.

List<int> ls; ls.Sort((x, y) => y - x); or ls.Sort((x, y) => { int a; a = y; a -= x; return a; });


Sorry, you said: "C# doesn't ... allow you to define them (delegates) inline". Delegate literal *is* an inline definition of a delegate. What you say now is that C# doesn't allow to define a delegate type inside a function which is definitely true and is very annoying.

Have you seen the Func delegates? They are exactly for that. The above example would be: void foo(Func<int, int> dg) { ... }

Func defines a delegate with one argument and a non-void return. There are lots of others like Action, Predicate, Comparator etc. which you must either remember or look up every time you need a specific delegate signature.
Aug 04 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Sergey Gromov wrote:
 Tue, 04 Aug 2009 11:58:27 -0300, Ary Borenszweig wrote:
 
 Sergey Gromov wrote:
 Tue, 04 Aug 2009 22:46:22 +1000, Daniel Keep wrote:

 Sergey Gromov wrote:
 Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:

 Don wrote:
 ...

 A question: in C#/Java, can you have annotations on function pointer and
 delegate declarations?

 void foo( int delegate(int) pure dg) {
   ...
 }
 What would this look like with annotations?

define them inline; they have a special declaration syntax that can't be used in an expression.

List<int> ls; ls.Sort((x, y) => y - x); or ls.Sort((x, y) => { int a; a = y; a -= x; return a; });


inline". Delegate literal *is* an inline definition of a delegate. What you say now is that C# doesn't allow to define a delegate type inside a function which is definitely true and is very annoying.

The above example would be: void foo(Func<int, int> dg) { ... }

Func defines a delegate with one argument and a non-void return. There are lots of others like Action, Predicate, Comparator etc. which you must either remember or look up every time you need a specific delegate signature.

Ah, I didn't know you can't do something like Func<void, int>. So there could just be two things to remember: Func and Action. Also you have Func<T1, T2, TResult>, Func<T1, T2, T3, TResult>, so it's not just one argument. I just tried casting one delegate type to another one with the same signature and it doesn't work. So you are right, you need to remember Predicate, Comparator, etc. :-(
Aug 04 2009
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
Don Wrote:

 To answer Don's point, there is nothing saying that the compiler can't 
 read attributes and change its behavior.  Of course, those would have to 
 be builtin attributes.

Yes, but then they're just keywords, with an in front. You'd just be kidding yourself if you think you've reduced the keyword count.

The problem with keywords is they're global. Why do you think there is module std.string, but there isn't core.stdc.wchar? It's because string is not a keyword, while wchar is. And annotations are also identifiers (though predefined, like Object) rather than keywords.
Aug 04 2009
parent Don <nospam nospam.com> writes:
Kagamin wrote:
 Don Wrote:
 
 To answer Don's point, there is nothing saying that the compiler can't 
 read attributes and change its behavior.  Of course, those would have to 
 be builtin attributes.

kidding yourself if you think you've reduced the keyword count.

The problem with keywords is they're global. Why do you think there is module std.string, but there isn't core.stdc.wchar? It's because string is not a keyword, while wchar is. And annotations are also identifiers (though predefined, like Object) rather than keywords.

No, that's only one of the problems with keywords. Prefixing all new keywords with __ solves the same problem, and it's no more ugly than prefixing with . But it doesn't solve the other keyword problems.
Aug 04 2009
prev sibling next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Don escribió:
 Steven Schveighoffer wrote:
 On Mon, 03 Aug 2009 11:42:33 -0400, Ary Borenszweig 
 <ary esperanto.org.ar> wrote:

 Don wrote:
 Ary Borenszweig wrote:
 Don escribió:
 grauzone wrote:
 Don wrote:
 Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

This looks like a solution in search of a problem. What's the problem being solved?

Attaching additional data to types, that can't be specified otherwhere. This should help with metaprogramming-like stuff. For example serialization. How do you specify that a field shouldn't be part of the serialized data? Java has an extra keyword attribute like "transient" (comes from before attributes were introduced). C# uses what we call annotation in this thread. How would you do this in D?

I agree that there doesn't seem to be a nice way at present. One possibility would be to establish a naming convention for transient fields -- a Ruby-style solution, I guess. But are annotations actually an ideal solution for this problem? Presumably, you'll have to specify that somewhere else anyway. I mean, during reading it will need to either be initialized separately after serialisation (like opPostBlit, perhaps?), or else remain uninitialized. Serialisation seems to be _extremely_ similar to construction. I'm not sure that annotations capture that. D has much more powerful metaprogramming than C# or Java, so my intuition and hope is that we shouldn't need to adopt hacks from those weaker languages. The annotation syntax in C# and Java looks like an ugly hack to me. Purely a subjective opinion, of course, but it seems really out of place in a C-family language.

Attributes has many, many other uses. Appart from serialization, you could specify how a field is stored in a database. How a method maps to an http request (post, get, which parameters to bind to the request, etc.). Whether a method should do security checks before executing. Whether a method should be run as a test, and what's the expected exception to be thrown. [insert your usage here]

instead of the vague stuff that's in there now -- the existing DIP is about replacing keywords, which is very unconvincing. (It doesn't work, actually -- the name mangling is important for most of the keywords mentioned).

But the DIP I wrote isn't about general-purpose annotations. It's just the first step. Are "pure" and "nothrow" part of the mangling? Or which are? I thought not. Can you overload a pure and a not-pure function with the same parameter count and types?

Yes, they have to be. There are reasons besides overloading for including other attributes in the naming. For example, if a function is pure, then becomes unpure, you don't existing code that is expecting a pure function to link against it. In other words, the linker is dumb. It only knows how to match symbols, so you have to embed into the symbols the important pieces of the interface that you want the linker to consider important.

A question: in C#/Java, can you have annotations on function pointer and delegate declarations? void foo( int delegate(int) pure dg) { ... } What would this look like with annotations? (The underlying question is, how do annotations interact with the type system?)

In C# (and they were going to add it to Java) you can annotate a lof of things: declarations, statements, function arguments. I don't know if expressions. So you could do: void foo( pure int delegate(int) dg) { } but that'll mark as pure the argument dg, not the type of dg. That doesn't mean there shouldn't be a way to annotate types.
Aug 04 2009
prev sibling parent reply grauzone <none example.net> writes:
Steven Schveighoffer wrote:
 For the record, I'm not really keen on using annotations for 
 *everything* as some people have suggested.  They have good uses, but I 

Me neither, but I think they'd be a worthy feature. Of course, there are far more pressing issues, but if Walter has time to introduce const/immutable/pure, then why not annotations?
 don't think it's worth adding them until we can have full reflection 
 capabilities so we can get at elements of code and therefore get the 
 annotations associated with it.  I see much more usefulness for 
 annotations as reflection hints than as a replacement for keywords.

But we already have full reflection. It's called __traits. You can build a serialization library or "proper" (user friendly?) reflection on top of it.
Aug 04 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> wrote:
 
 Steven Schveighoffer wrote:
 don't think it's worth adding them until we can have full reflection 
 capabilities so we can get at elements of code and therefore get the 
 annotations associated with it.  I see much more usefulness for 
 annotations as reflection hints than as a replacement for keywords.

But we already have full reflection. It's called __traits. You can build a serialization library or "proper" (user friendly?) reflection on top of it.

I think you are the 1 millionth person to say it, and yet we still do not have a "user friendly" reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now.

The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it. For example, I myself didn't know about __traits(allMembers) until it was mentioned in this group. That's why I'd defined defineEnum, which now is a relic replaced by the appropriate mechanism, contributed to by Shin Fujishiro. I know exactly how to go about a reflection system, but I simply haven't gotten around to it. Here's an initial shot: starting with std.variant, implement a function "call": class A { int foo() { return 42; } } ... auto v = Variant(new A); writeln(*v.call("foo").peek!int()); That should print 42. This is eminently doable with what we have now, and could then be extended to multiple arguments etc. with the appropriate amount of sweat. The way to implement this would be to use __traits(allMembers) in the templated constructor to store a hash that maps strings to delegates. The delegates take no argument and return Variant. During construction you can figure which members can be invoked with no arguments by using e.g. is(typeof(...)) and initialize the hash appropriately. In the call() function, you look up the string and fire the delegate. Andrei
Aug 04 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> wrote:

 Steven Schveighoffer wrote:
 don't think it's worth adding them until we can have full 
 reflection capabilities so we can get at elements of code and 
 therefore get the annotations associated with it.  I see much more 
 usefulness for annotations as reflection hints than as a 
 replacement for keywords.

But we already have full reflection. It's called __traits. You can build a serialization library or "proper" (user friendly?) reflection on top of it.

do not have a "user friendly" reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now.

The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it.

That's understandable, nobody can expect a language as young as D to have everything. But in reality, I think the *theory* that everything is there to build a reflection system is only proven when it actually happens. I'm sure when the enterprising person or persons go to develop it, they will find pieces missing from the static reflection system.

Exactly. I'm absolutely sure there are quite a few things needed here and there. I can assure you I'll push hard for those.
 So my point is that adding annotations before reflection works and is 
 implemented makes little sense to me, because the usage of them will be 
 crippled by the fact that reflection isn't complete.
 
 What I'd like to see is something like this possible:
 
 void foo (int timeout, string bar, float f = 4.0);
 
 void foo(int timeout);
 
 call!(foo)("timeout=5,bar=\"hello\"");
 
 Taking into account the default value of f, what the parameters are 
 named, and which overload to call.  I could certainly do it with C#.

This is interesting. It means we'd need reflection for parameter names, which currently does not exist. Andrei
Aug 04 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> wrote:

 Steven Schveighoffer wrote:
 don't think it's worth adding them until we can have full 
 reflection capabilities so we can get at elements of code and 
 therefore get the annotations associated with it.  I see much more 
 usefulness for annotations as reflection hints than as a 
 replacement for keywords.

But we already have full reflection. It's called __traits. You can build a serialization library or "proper" (user friendly?) reflection on top of it.

do not have a "user friendly" reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now.

The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it.

That's understandable, nobody can expect a language as young as D to have everything. But in reality, I think the *theory* that everything is there to build a reflection system is only proven when it actually happens. I'm sure when the enterprising person or persons go to develop it, they will find pieces missing from the static reflection system.

Exactly. I'm absolutely sure there are quite a few things needed here and there. I can assure you I'll push hard for those.
 So my point is that adding annotations before reflection works and is 
 implemented makes little sense to me, because the usage of them will 
 be crippled by the fact that reflection isn't complete.

 What I'd like to see is something like this possible:

 void foo (int timeout, string bar, float f = 4.0);

 void foo(int timeout);

 call!(foo)("timeout=5,bar=\"hello\"");

 Taking into account the default value of f, what the parameters are 
 named, and which overload to call.  I could certainly do it with C#.

This is interesting. It means we'd need reflection for parameter names, which currently does not exist.

Why do it with strings? Why not call!(foo)(5, "hello") with varaidic args?
Aug 04 2009
next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 13:44:46 -0400, Ary Borenszweig 
 <ary esperanto.org.ar> wrote:
 
 Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 What I'd like to see is something like this possible:

 void foo (int timeout, string bar, float f = 4.0);

 void foo(int timeout);

 call!(foo)("timeout=5,bar=\"hello\"");

 Taking into account the default value of f, what the parameters are 
 named, and which overload to call.  I could certainly do it with C#.

names, which currently does not exist.

Why do it with strings? Why not call!(foo)(5, "hello") with varaidic args?

Ok, say foo is: void foo(string bar, int timeout)

What's the difference?
Aug 04 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ary Borenszweig wrote:
 Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> wrote:

 Steven Schveighoffer wrote:
 don't think it's worth adding them until we can have full 
 reflection capabilities so we can get at elements of code and 
 therefore get the annotations associated with it.  I see much 
 more usefulness for annotations as reflection hints than as a 
 replacement for keywords.

But we already have full reflection. It's called __traits. You can build a serialization library or "proper" (user friendly?) reflection on top of it.

do not have a "user friendly" reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now.

The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it.

That's understandable, nobody can expect a language as young as D to have everything. But in reality, I think the *theory* that everything is there to build a reflection system is only proven when it actually happens. I'm sure when the enterprising person or persons go to develop it, they will find pieces missing from the static reflection system.

Exactly. I'm absolutely sure there are quite a few things needed here and there. I can assure you I'll push hard for those.
 So my point is that adding annotations before reflection works and is 
 implemented makes little sense to me, because the usage of them will 
 be crippled by the fact that reflection isn't complete.

 What I'd like to see is something like this possible:

 void foo (int timeout, string bar, float f = 4.0);

 void foo(int timeout);

 call!(foo)("timeout=5,bar=\"hello\"");

 Taking into account the default value of f, what the parameters are 
 named, and which overload to call.  I could certainly do it with C#.

This is interesting. It means we'd need reflection for parameter names, which currently does not exist.

Why do it with strings? Why not call!(foo)(5, "hello") with varaidic args?

Well some don't like to need to remember the order of arguments. Andrei
Aug 04 2009
next sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Andrei Alexandrescu schrieb:
 Ary Borenszweig wrote:
 call!(foo)(5, "hello")

 with varaidic args?

Well some don't like to need to remember the order of arguments. Andrei

Assigning the argument by name instead of order has two other benefits, i can think of... 1. on the call side, it is documented for what the given values are used. 2. it may be possible to let all parameters have default values and for example just give a value for the last parameter. This is not possible with just the parameter order.
Aug 04 2009
parent Benji Smith <dlanguage benjismith.net> writes:
Frank Benoit wrote:
 Andrei Alexandrescu schrieb:
 Ary Borenszweig wrote:
 call!(foo)(5, "hello")

 with varaidic args?

Andrei

Assigning the argument by name instead of order has two other benefits, i can think of... 1. on the call side, it is documented for what the given values are used. 2. it may be possible to let all parameters have default values and for example just give a value for the last parameter. This is not possible with just the parameter order.

But these aren't issues with reflection. These are just the same function calling rules applied elsewhere in the language: 1) If you want to call a function: you must know its name. 2) If you want to pass parameters: you must know the correct order. I can't imagine a circumstance where someone uses reflection to call a function and knows how to create the correct set of arguments, but doesn't know what order to put them in. --benji
Aug 04 2009
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu wrote:
 Ary Borenszweig wrote:
 Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> 
 wrote:

 Steven Schveighoffer wrote:
 don't think it's worth adding them until we can have full 
 reflection capabilities so we can get at elements of code and 
 therefore get the annotations associated with it.  I see much 
 more usefulness for annotations as reflection hints than as a 
 replacement for keywords.

But we already have full reflection. It's called __traits. You can build a serialization library or "proper" (user friendly?) reflection on top of it.

still do not have a "user friendly" reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now.

The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it.

That's understandable, nobody can expect a language as young as D to have everything. But in reality, I think the *theory* that everything is there to build a reflection system is only proven when it actually happens. I'm sure when the enterprising person or persons go to develop it, they will find pieces missing from the static reflection system.

Exactly. I'm absolutely sure there are quite a few things needed here and there. I can assure you I'll push hard for those.
 So my point is that adding annotations before reflection works and 
 is implemented makes little sense to me, because the usage of them 
 will be crippled by the fact that reflection isn't complete.

 What I'd like to see is something like this possible:

 void foo (int timeout, string bar, float f = 4.0);

 void foo(int timeout);

 call!(foo)("timeout=5,bar=\"hello\"");

 Taking into account the default value of f, what the parameters are 
 named, and which overload to call.  I could certainly do it with C#.

This is interesting. It means we'd need reflection for parameter names, which currently does not exist.

Why do it with strings? Why not call!(foo)(5, "hello") with varaidic args?

Well some don't like to need to remember the order of arguments.

But that's a way totally different thing discussed here. First you need to introduce argument names when invoking a function. void foo(int timeout, string bar) { .. } Can be used as: foo(timeout=5, bar="100") (with some other syntax, of course) Once you have that, you could do: call!(foo)(timeout=5, bar="100") Voilà!
Aug 04 2009
next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Ary Borenszweig wrote:
 Andrei Alexandrescu wrote:
 Ary Borenszweig wrote:
 Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> 
 wrote:

 Steven Schveighoffer wrote:
 don't think it's worth adding them until we can have full 
 reflection capabilities so we can get at elements of code and 
 therefore get the annotations associated with it.  I see much 
 more usefulness for annotations as reflection hints than as a 
 replacement for keywords.

But we already have full reflection. It's called __traits. You can build a serialization library or "proper" (user friendly?) reflection on top of it.

still do not have a "user friendly" reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now.

The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it.

That's understandable, nobody can expect a language as young as D to have everything. But in reality, I think the *theory* that everything is there to build a reflection system is only proven when it actually happens. I'm sure when the enterprising person or persons go to develop it, they will find pieces missing from the static reflection system.

Exactly. I'm absolutely sure there are quite a few things needed here and there. I can assure you I'll push hard for those.
 So my point is that adding annotations before reflection works and 
 is implemented makes little sense to me, because the usage of them 
 will be crippled by the fact that reflection isn't complete.

 What I'd like to see is something like this possible:

 void foo (int timeout, string bar, float f = 4.0);

 void foo(int timeout);

 call!(foo)("timeout=5,bar=\"hello\"");

 Taking into account the default value of f, what the parameters are 
 named, and which overload to call.  I could certainly do it with C#.

This is interesting. It means we'd need reflection for parameter names, which currently does not exist.

Why do it with strings? Why not call!(foo)(5, "hello") with varaidic args?

Well some don't like to need to remember the order of arguments.

But that's a way totally different thing discussed here.

Sorry, not totally different. What I'm saying is: one thing at a time.
Aug 04 2009
prev sibling next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 15:56:16 -0400, Ary Borenszweig 
 <ary esperanto.org.ar> wrote:
 
 Andrei Alexandrescu wrote:
  Well some don't like to need to remember the order of arguments.

But that's a way totally different thing discussed here. First you need to introduce argument names when invoking a function. void foo(int timeout, string bar) { .. } Can be used as: foo(timeout=5, bar="100") (with some other syntax, of course) Once you have that, you could do: call!(foo)(timeout=5, bar="100") Voilà!

It could also be accomplished via a fully implemented reflection library, which is my side topic for this thread branch :P For instance you could do this exact thing in C#, even though C# doesn't support named parameters.

Aaaaaaah... I see now. :)
Aug 04 2009
prev sibling next sibling parent Rainer Deyke <rainerd eldwood.com> writes:
Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 15:56:16 -0400, Ary Borenszweig
 <ary esperanto.org.ar> wrote:
 foo(timeout=5, bar="100")

library, which is my side topic for this thread branch :P

No. The names of positional arguments are an implementation detail, and should not be exposed via reflection. Named arguments are different from positional arguments and require separate language support. Consider the ambiguity caused by function overloading: void f(int x, string y); void f(string y, int x); f(x = 1, y = ""); Consider the implications of function pointers: void f(int x, int y); void g(int y, int x); (cond ? &f : &g)(x = 1, y = 2); -- Rainer Deyke - rainerd eldwood.com
Aug 04 2009
prev sibling parent John C <johnch_atms hotmail.com> writes:
Steven Schveighoffer wrote:
 
 For instance you could do this exact thing in C#, even though C# doesn't 
 support named parameters.

But they're coming: http://msdn.microsoft.com/en-us/library/dd264739(VS.100).aspx
Aug 04 2009
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 8/4/09 19:20, Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> wrote:

 Steven Schveighoffer wrote:
 don't think it's worth adding them until we can have full
 reflection capabilities so we can get at elements of code and
 therefore get the annotations associated with it. I see much more
 usefulness for annotations as reflection hints than as a
 replacement for keywords.

But we already have full reflection. It's called __traits. You can build a serialization library or "proper" (user friendly?) reflection on top of it.

do not have a "user friendly" reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now.

The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it.

That's understandable, nobody can expect a language as young as D to have everything. But in reality, I think the *theory* that everything is there to build a reflection system is only proven when it actually happens. I'm sure when the enterprising person or persons go to develop it, they will find pieces missing from the static reflection system.

Exactly. I'm absolutely sure there are quite a few things needed here and there. I can assure you I'll push hard for those.
 So my point is that adding annotations before reflection works and is
 implemented makes little sense to me, because the usage of them will
 be crippled by the fact that reflection isn't complete.

 What I'd like to see is something like this possible:

 void foo (int timeout, string bar, float f = 4.0);

 void foo(int timeout);

 call!(foo)("timeout=5,bar=\"hello\"");

 Taking into account the default value of f, what the parameters are
 named, and which overload to call. I could certainly do it with C#.

This is interesting. It means we'd need reflection for parameter names, which currently does not exist. Andrei

It kind of exists: void foo (int bar); const str = typeof(&func).stringof; "str" will contain the parameter names. See: http://tango.pastebin.com/m129241b0 for an example.
Aug 04 2009
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 8/4/09 18:55, Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> wrote:

 Steven Schveighoffer wrote:
 don't think it's worth adding them until we can have full
 reflection capabilities so we can get at elements of code and
 therefore get the annotations associated with it. I see much more
 usefulness for annotations as reflection hints than as a
 replacement for keywords.

But we already have full reflection. It's called __traits. You can build a serialization library or "proper" (user friendly?) reflection on top of it.

not have a "user friendly" reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now.

The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it.

That's understandable, nobody can expect a language as young as D to have everything. But in reality, I think the *theory* that everything is there to build a reflection system is only proven when it actually happens. I'm sure when the enterprising person or persons go to develop it, they will find pieces missing from the static reflection system. So my point is that adding annotations before reflection works and is implemented makes little sense to me, because the usage of them will be crippled by the fact that reflection isn't complete. What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)("timeout=5,bar=\"hello\""); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. -Steve

You mean like this: http://tango.pastebin.com/m129241b0 ? /Jacob Carlborg
Aug 04 2009
next sibling parent Jacob Carlborg <doob me.com> writes:
On 8/5/09 00:22, Jacob Carlborg wrote:
 On 8/4/09 18:55, Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> wrote:

 Steven Schveighoffer wrote:
 don't think it's worth adding them until we can have full
 reflection capabilities so we can get at elements of code and
 therefore get the annotations associated with it. I see much more
 usefulness for annotations as reflection hints than as a
 replacement for keywords.

But we already have full reflection. It's called __traits. You can build a serialization library or "proper" (user friendly?) reflection on top of it.

not have a "user friendly" reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now.

The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it.

That's understandable, nobody can expect a language as young as D to have everything. But in reality, I think the *theory* that everything is there to build a reflection system is only proven when it actually happens. I'm sure when the enterprising person or persons go to develop it, they will find pieces missing from the static reflection system. So my point is that adding annotations before reflection works and is implemented makes little sense to me, because the usage of them will be crippled by the fact that reflection isn't complete. What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)("timeout=5,bar=\"hello\""); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. -Steve

You mean like this: http://tango.pastebin.com/m129241b0 ? /Jacob Carlborg

Forgot to say: this works in D1 with dmd, gdc and ldc. /Jacob Carlborg
Aug 04 2009
prev sibling parent Don <nospam nospam.com> writes:
Jacob Carlborg wrote:
 On 8/4/09 18:55, Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> wrote:

 Steven Schveighoffer wrote:
 don't think it's worth adding them until we can have full
 reflection capabilities so we can get at elements of code and
 therefore get the annotations associated with it. I see much more
 usefulness for annotations as reflection hints than as a
 replacement for keywords.

But we already have full reflection. It's called __traits. You can build a serialization library or "proper" (user friendly?) reflection on top of it.

not have a "user friendly" reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now.

The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it.

That's understandable, nobody can expect a language as young as D to have everything. But in reality, I think the *theory* that everything is there to build a reflection system is only proven when it actually happens. I'm sure when the enterprising person or persons go to develop it, they will find pieces missing from the static reflection system. So my point is that adding annotations before reflection works and is implemented makes little sense to me, because the usage of them will be crippled by the fact that reflection isn't complete. What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)("timeout=5,bar=\"hello\""); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. -Steve

You mean like this: http://tango.pastebin.com/m129241b0 ? /Jacob Carlborg

static assert(jacobCarlbord.ninjaLevel == BlackBelt);
Aug 05 2009
prev sibling parent KennyTM~ <kennytm gmail.com> writes:
Don wrote:
 Ary Borenszweig wrote:
 Don escribió:
 grauzone wrote:
 Don wrote:
 Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

This looks like a solution in search of a problem. What's the problem being solved?

Attaching additional data to types, that can't be specified otherwhere. This should help with metaprogramming-like stuff. For example serialization. How do you specify that a field shouldn't be part of the serialized data? Java has an extra keyword attribute like "transient" (comes from before attributes were introduced). C# uses what we call annotation in this thread. How would you do this in D?

I agree that there doesn't seem to be a nice way at present. One possibility would be to establish a naming convention for transient fields -- a Ruby-style solution, I guess. But are annotations actually an ideal solution for this problem? Presumably, you'll have to specify that somewhere else anyway. I mean, during reading it will need to either be initialized separately after serialisation (like opPostBlit, perhaps?), or else remain uninitialized. Serialisation seems to be _extremely_ similar to construction. I'm not sure that annotations capture that. D has much more powerful metaprogramming than C# or Java, so my intuition and hope is that we shouldn't need to adopt hacks from those weaker languages. The annotation syntax in C# and Java looks like an ugly hack to me. Purely a subjective opinion, of course, but it seems really out of place in a C-family language.

Attributes has many, many other uses. Appart from serialization, you could specify how a field is stored in a database. How a method maps to an http request (post, get, which parameters to bind to the request, etc.). Whether a method should do security checks before executing. Whether a method should be run as a test, and what's the expected exception to be thrown. [insert your usage here]

Great, you've answered my question. That should be in the DIP, instead of the vague stuff that's in there now -- the existing DIP is about replacing keywords, which is very unconvincing. (It doesn't work, actually -- the name mangling is important for most of the keywords mentioned).

The compiler can recognize special annotations and put them to the name mangling. It may even mangle general purpose annotations.
Aug 03 2009
prev sibling next sibling parent Don <nospam nospam.com> writes:
Steven Schveighoffer wrote:
 On Mon, 03 Aug 2009 09:26:21 -0400, Don <nospam nospam.com> wrote:
 
 grauzone wrote:
 Don wrote:
 Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

This looks like a solution in search of a problem. What's the problem being solved?




[snip]
 Annotations are useful in many ways, but without full reflection 
 capabilities, they are restricted to things that can read them via 
 source code, and so they are no better than comments.

This is a very, very important observation, and I think it belongs in the DIP. It means that it probably doesn't make much sense to implement annotations without also having an intention to implement full-blown reflection.
Aug 03 2009
prev sibling parent Benji Smith <dlanguage benjismith.net> writes:
Steven Schveighoffer wrote:
 Annotations have more usages than just how to serialize.  Some uses I've 
 seen in C#:
 
 * hints to an IDE about a GUI component (what it does, what properties 
 to allow setting via the visual builder)
 * hints to the debugger about when to skip debugging certain functions 
 (to avoid stepping into mundane crap such as property getters).
 * hints to another program about which classes would be interesting when 
 dynamically loading a library

In Actionscript (and the Flex framework), one very handy use of annotations is to mark a public field as "bindable". class MyClass { [Bindable] public var MyField:int = 0; } In this example, whenever the "MyField" value is updated, a property-change event will be send to all listeners. The XML-based Flex framework uses those annotations to create (unidirectional or bidirectional) bindings between variables. <Window> <HSlider id="mySlider"/> <Image source="..." width="{mySlider.value}" height="{mySlider.value}" /> </Window> This creates a window with two controls, a horizontal numeric slider and an image. Whenever the user drags the slider control, the width and height of the image automatically update themselves. The reason this works is that the "value" field of the "HSlider" object is marked with the "Bindable" annotation. The compiler silently converts the field into a property getter/setter pair, and the setter sends out property-change events whenever called. (Good thing Actionscript properties exist, with a syntax identical to normal fields, or else the automatic data binding wouldn't work!) The cool thing that makes this work is that the compiler can perform code transformation based on the existence of various annotations. --benji
Aug 03 2009
prev sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
grauzone wrote:
 Don wrote:
 Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

This looks like a solution in search of a problem. What's the problem being solved?

Attaching additional data to types, that can't be specified otherwhere. This should help with metaprogramming-like stuff. For example serialization. How do you specify that a field shouldn't be part of the serialized data? Java has an extra keyword attribute like "transient" (comes from before attributes were introduced). C# uses what we call annotation in this thread. How would you do this in D?

struct Foo { int serialise_me, dont_serialise_me, or_me; alias Tuple!("dont_serialise_me", "or_me") IgnoreForSerialisation; } Or, if you'd rather have a less hacky interface: struct Foo { int serialise_me, dont_serialise_me, or_me; mixin IgnoreForSerialisation!("dont_serialise_me", "or_me"); }
Aug 03 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Daniel Keep wrote:
 
 grauzone wrote:
 Don wrote:
 Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

being solved?

This should help with metaprogramming-like stuff. For example serialization. How do you specify that a field shouldn't be part of the serialized data? Java has an extra keyword attribute like "transient" (comes from before attributes were introduced). C# uses what we call annotation in this thread. How would you do this in D?

struct Foo { int serialise_me, dont_serialise_me, or_me; alias Tuple!("dont_serialise_me", "or_me") IgnoreForSerialisation; } Or, if you'd rather have a less hacky interface: struct Foo { int serialise_me, dont_serialise_me, or_me; mixin IgnoreForSerialisation!("dont_serialise_me", "or_me"); }

I can imagine this also: struct Foo { char[] one; int two; float three; mixin SerializeAsXmlElement!("one", "desiredNameForOne", "two", "desiredNameForTwo"); mixin SerializeAsXmlAttribute!("three", "desiredNameForThree"); } That looks great. And as your struct grows, you have to scroll down to see how an element is serialized. And if you want to change how an element is serialized you scroll down and move two strings from one point to another. I also wonder *how* is that mixed template implemented, it probably adds some fields or things to that struct. How about this: struct Foo { XmlElement("desiredNameForOne"); char[] one; XmlElement("desiredNameForTwo"); int two; XmlAttribute("desiredNameForThree"); float three; } Which one looks nicer and more understandable to you? How do you change a property to be serialized as an element to an attribute? You just change "XmlElement" to "XmlAttribute" and that's it. Your approach also is no DRY: you have to name the fields again. It might throw awful compiler errors for template code when you mistype something. If you rename a field you must also remember to rename the serialization mixin.
Aug 03 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Ary Borenszweig wrote:
 Daniel Keep wrote:
 grauzone wrote:
 ...
 For example serialization. How do you specify that a field shouldn't be
 part of the serialized data? Java has an extra keyword attribute like
 "transient" (comes from before attributes were introduced). C# uses what
 we call annotation in this thread. How would you do this in D?

struct Foo { int serialise_me, dont_serialise_me, or_me; alias Tuple!("dont_serialise_me", "or_me") IgnoreForSerialisation; } Or, if you'd rather have a less hacky interface: struct Foo { int serialise_me, dont_serialise_me, or_me; mixin IgnoreForSerialisation!("dont_serialise_me", "or_me"); }

... That looks great. And as your struct grows, you have to scroll down to see how an element is serialized. And if you want to change how an element is serialized you scroll down and move two strings from one point to another. I also wonder *how* is that mixed template implemented, it probably adds some fields or things to that struct.

"How would you do this in D?" I was answering the question.
 How about this:
 
 struct Foo {
 
      XmlElement("desiredNameForOne");
     char[] one;
 
      XmlElement("desiredNameForTwo");
     int two;
 
      XmlAttribute("desiredNameForThree");
     float three;
 }
 
 Which one looks nicer and more understandable to you? How do you change
 a property to be serialized as an element to an attribute? You just
 change "XmlElement" to "XmlAttribute" and that's it.

Which one works right now and doesn't require you first spend at least a year convincing Walter that it's useful, then convincing him it's necessary, followed by six months of continuous bike-shedding by the community before Walter gives up and implements something that somehow manages to piss off everyone who was arguing for it, largely because it wasn't the exact syntax they wanted? Which one have I been successfully using in a project of mine for over two and a half years now thanks to it also working in crusty old D1? Who's the one with a working struct->xml parser template based on it?
 Your approach also is no DRY: you have to name the fields again. It
 might throw awful compiler errors for template code when you mistype
 something. If you rename a field you must also remember to rename the
 serialization mixin.

It's odd; I can't find the part of my post where I said this was perfect and the ideal solution! My newsreader must be truncating my messages...
Aug 03 2009
prev sibling parent reply Max Samukha <spambox d-coding.com> writes:
On Tue, 04 Aug 2009 01:30:29 +1000, Daniel Keep
<daniel.keep.lists gmail.com> wrote:

grauzone wrote:
 Don wrote:
 Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

This looks like a solution in search of a problem. What's the problem being solved?

Attaching additional data to types, that can't be specified otherwhere. This should help with metaprogramming-like stuff. For example serialization. How do you specify that a field shouldn't be part of the serialized data? Java has an extra keyword attribute like "transient" (comes from before attributes were introduced). C# uses what we call annotation in this thread. How would you do this in D?

struct Foo { int serialise_me, dont_serialise_me, or_me; alias Tuple!("dont_serialise_me", "or_me") IgnoreForSerialisation; } Or, if you'd rather have a less hacky interface: struct Foo { int serialise_me, dont_serialise_me, or_me; mixin IgnoreForSerialisation!("dont_serialise_me", "or_me"); }

You can even use a mixin per member: struct Foo { mixin Persistent!("field", "field-as-it-is-named-in-db"); int field; mixin Persistent!("field2"); mixin Serializable!("field2"); int field2; } It would be nice (and that is unlikely to happen) if the compiler could rewrite struct Foo { Persistent("db_field") Serializable int field; } to struct Foo { int field; mixin Persistent!("field", "db_field"); mixin Serializable!("field"); }
Aug 03 2009
parent grauzone <none example.net> writes:
Max Samukha wrote:
 It would be nice (and that is unlikely to happen) if the compiler
 could rewrite
 
 struct Foo
 {
      Persistent("db_field")
      Serializable
     int field;
 }
 
 to
 
 struct Foo
 {
     int field;
     mixin Persistent!("field", "db_field");
     mixin Serializable!("field");
 }
 

It'd be even nicer if it wouldn't require ridiculous hacks from you to read out the annotation data again. E.g. right now, that Serializable mixin would define something like "const bool field_serializeable = true;", and you'd need to use CTFE string concatenation (better hope the compiler's GC is enabled) and is() to define/read the data. Very clumsy and hackish, although it would work. For me, making these things simpler is the whole point of annotations. Looks like we have three basic things that annotations could be used for: 1. alternative namespace for keywords 2. associate arbitrary, user defined metadata with types and fields 3. macro madness (using the approach found in Python)
Aug 03 2009
prev sibling next sibling parent Kagamin <spam here.lot> writes:
Don Wrote:

 Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

This looks like a solution in search of a problem. What's the problem being solved?

Lack of power. People today want powerful language. With attributes you can arbitrarily extend metadata, see AttributeTargets enumeration http://msdn.microsoft.com/en-us/library/system.attributetargets.aspx
Aug 03 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 03 Aug 2009 09:26:21 -0400, Don <nospam nospam.com> wrote:

 grauzone wrote:
 Don wrote:
 Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

This looks like a solution in search of a problem. What's the problem being solved?

otherwhere. This should help with metaprogramming-like stuff. For example serialization. How do you specify that a field shouldn't be part of the serialized data? Java has an extra keyword attribute like "transient" (comes from before attributes were introduced). C# uses what we call annotation in this thread. How would you do this in D?

I agree that there doesn't seem to be a nice way at present. One possibility would be to establish a naming convention for transient fields -- a Ruby-style solution, I guess. But are annotations actually an ideal solution for this problem? Presumably, you'll have to specify that somewhere else anyway. I mean, during reading it will need to either be initialized separately after serialisation (like opPostBlit, perhaps?), or else remain uninitialized. Serialisation seems to be _extremely_ similar to construction. I'm not sure that annotations capture that.

Typically, items excluded from serialization are left uninitialized, or initialized via default initializers. These types of items usually don't make sense to restore anyways, like file handles, or cached lookup data.
 D has much more powerful metaprogramming than C# or Java, so my  
 intuition and hope is that we shouldn't need to adopt hacks from those  
 weaker languages. The annotation syntax in C# and Java looks like an  
 ugly hack to me. Purely a subjective opinion, of course, but it seems  
 really out of place in a C-family language.

Annotations have more usages than just how to serialize. Some uses I've seen in C#: * hints to an IDE about a GUI component (what it does, what properties to allow setting via the visual builder) * hints to the debugger about when to skip debugging certain functions (to avoid stepping into mundane crap such as property getters). * hints to another program about which classes would be interesting when dynamically loading a library On that last one, I wrote an editor that would create xml files indicating how to call constructors of certain types in an executable. I tagged the types with attributes that described what they do, and how to display them in the editor (for example, is an integer a bitmask? if so, display a set of checkboxes with these names). Then when I would add classes to the executable, I did not have to update the editor. Annotations are useful in many ways, but without full reflection capabilities, they are restricted to things that can read them via source code, and so they are no better than comments. -Steve
Aug 03 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 03 Aug 2009 11:42:33 -0400, Ary Borenszweig <ary esperanto.org.ar>  
wrote:

 Don wrote:
 Ary Borenszweig wrote:
 Don escribió:
 grauzone wrote:
 Don wrote:
 Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

This looks like a solution in search of a problem. What's the problem being solved?

Attaching additional data to types, that can't be specified otherwhere. This should help with metaprogramming-like stuff. For example serialization. How do you specify that a field shouldn't be part of the serialized data? Java has an extra keyword attribute like "transient" (comes from before attributes were introduced). C# uses what we call annotation in this thread. How would you do this in D?

I agree that there doesn't seem to be a nice way at present. One possibility would be to establish a naming convention for transient fields -- a Ruby-style solution, I guess. But are annotations actually an ideal solution for this problem? Presumably, you'll have to specify that somewhere else anyway. I mean, during reading it will need to either be initialized separately after serialisation (like opPostBlit, perhaps?), or else remain uninitialized. Serialisation seems to be _extremely_ similar to construction. I'm not sure that annotations capture that. D has much more powerful metaprogramming than C# or Java, so my intuition and hope is that we shouldn't need to adopt hacks from those weaker languages. The annotation syntax in C# and Java looks like an ugly hack to me. Purely a subjective opinion, of course, but it seems really out of place in a C-family language.

Attributes has many, many other uses. Appart from serialization, you could specify how a field is stored in a database. How a method maps to an http request (post, get, which parameters to bind to the request, etc.). Whether a method should do security checks before executing. Whether a method should be run as a test, and what's the expected exception to be thrown. [insert your usage here]

of the vague stuff that's in there now -- the existing DIP is about replacing keywords, which is very unconvincing. (It doesn't work, actually -- the name mangling is important for most of the keywords mentioned).

But the DIP I wrote isn't about general-purpose annotations. It's just the first step. Are "pure" and "nothrow" part of the mangling? Or which are? I thought not. Can you overload a pure and a not-pure function with the same parameter count and types?

Yes, they have to be. There are reasons besides overloading for including other attributes in the naming. For example, if a function is pure, then becomes unpure, you don't existing code that is expecting a pure function to link against it. In other words, the linker is dumb. It only knows how to match symbols, so you have to embed into the symbols the important pieces of the interface that you want the linker to consider important. To answer Don's point, there is nothing saying that the compiler can't read attributes and change its behavior. Of course, those would have to be builtin attributes. My opinion on removing existing keywords is -- don't. There's little to no gain. Let that ship sail, and concentrate on future keyword proposals. -Steve
Aug 03 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 03 Aug 2009 19:53:21 +0400, Steven Schveighoffer  =

<schveiguy yahoo.com> wrote:

 On Mon, 03 Aug 2009 11:42:33 -0400, Ary Borenszweig  =

 <ary esperanto.org.ar> wrote:

 Don wrote:
 Ary Borenszweig wrote:
 Don escribi=C3=B3:
 grauzone wrote:
 Don wrote:
 Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

This looks like a solution in search of a problem. What's the =







 problem being solved?

Attaching additional data to types, that can't be specified =






 otherwhere. This should help with metaprogramming-like stuff.

 For example serialization. How do you specify that a field  =






 shouldn't be part of the serialized data? Java has an extra keywo=






 attribute like
 "transient" (comes from before attributes were introduced). C# us=






 what we call annotation in this thread. How would you do this in =






 I agree that there doesn't seem to be a nice way at present. One  =





 possibility would be to establish a naming convention for transien=





 fields -- a Ruby-style solution, I guess.

 But are annotations actually an ideal solution for this problem?
 Presumably, you'll have to specify that somewhere else anyway. I  =





 mean, during reading it will need to either be initialized  =





 separately after serialisation (like opPostBlit, perhaps?), or els=





 remain uninitialized. Serialisation seems to be _extremely_ simila=





 to construction. I'm not sure that annotations capture that.

 D has much more powerful metaprogramming than C# or Java, so my  =





 intuition and hope is that we shouldn't need to adopt hacks from  =





 those weaker languages. The annotation syntax in C# and Java looks=





 like an ugly hack to me. Purely a subjective opinion, of course, b=





 it seems really out of place in a C-family language.

Attributes has many, many other uses. Appart from serialization, yo=




 could specify how a field is stored in a database. How a method map=




 to an http request (post, get, which parameters to bind to the  =




 request, etc.). Whether a method should do security checks before  =




 executing. Whether a method should be run as a test, and what's the=




 expected exception to be thrown. [insert your usage here]




 instead of the vague stuff that's in there now -- the existing DIP i=



 about replacing keywords, which is very unconvincing. (It doesn't  =



 work, actually -- the name mangling is important for most of the  =



 keywords mentioned).

But the DIP I wrote isn't about general-purpose annotations. It's jus=


 the first step. Are "pure" and "nothrow" part of the mangling? Or whi=


 are? I thought not. Can you overload a pure and a not-pure function  =


 with the same parameter count and types?

Yes, they have to be. There are reasons besides overloading for =

 including other attributes in the naming.

 For example, if a function is pure, then becomes unpure, you don't  =

 existing code that is expecting a pure function to link against it.

 In other words, the linker is dumb.  It only knows how to match symbol=

 so you have to embed into the symbols the important pieces of the  =

 interface that you want the linker to consider important.

 To answer Don's point, there is nothing saying that the compiler can't=

 read attributes and change its behavior.  Of course, those would have =

 be builtin attributes.

 My opinion on removing existing keywords is -- don't.  There's little =

 no gain.  Let that ship sail, and concentrate on future keyword  =

 proposals.

 -Steve

Compiler could embed some kind of a hash from attributes in a mangled na= me.
Aug 03 2009
prev sibling next sibling parent Benji Smith <dlanguage benjismith.net> writes:
Don wrote:
 Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

This looks like a solution in search of a problem. What's the problem being solved?

Keyword proliferation for a zillion tiny features? Annotations would help with that very nicely. --benji
Aug 03 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 04 Aug 2009 03:03:12 -0400, Don <nospam nospam.com> wrote:

 A question: in C#/Java, can you have annotations on function pointer and  
 delegate declarations?

 void foo( int delegate(int) pure dg) {
    ...
 }
 What would this look like with annotations?

 (The underlying question is, how do annotations interact with the type  
 system?)

I'm not familiar with Java annotations, it's been a while since I used Java. In C#, you would not use an attribute as a type modifier, the attributes are attached to a declaration (e.g. a class, member, function parameter). So basically, an attribute can modify how the compiler treats something, but it doesn't allow you to define new types with it. I suppose you could use it that way, but I think it would be better to just use it as hints and information, not an integral part of the type system. When you have runtime reflection, you can query for attributes on almost anything, but they are usually descriptors, and don't affect type matching. The only places I've used it are as hints to other things reading my compiled objects. For example, SerializableAttribute is used by serializers to know what to serialize and what not to serialize. If pure weren't part of the function signature, but simply a way to compile a function, then it would be fine as an annotation. A good usage for annotation, for example, would be scope, since it simply indicates where the compiler should put things, and doesn't affect types or signatures.
 To answer Don's point, there is nothing saying that the compiler can't  
 read attributes and change its behavior.  Of course, those would have  
 to be builtin attributes.

Yes, but then they're just keywords, with an in front. You'd just be kidding yourself if you think you've reduced the keyword count.

keywords are global, that was one of Walter's main points against adding a keyword for properties. Since annotations necessarily have a different syntax than normal symbols, you don't have to worry about avoiding those words. Others have also said that adding a builtin annotation would be easier because it doesn't affect the parser. For the record, I'm not really keen on using annotations for *everything* as some people have suggested. They have good uses, but I don't think it's worth adding them until we can have full reflection capabilities so we can get at elements of code and therefore get the annotations associated with it. I see much more usefulness for annotations as reflection hints than as a replacement for keywords. -Steve
Aug 04 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> wrote:

 Steven Schveighoffer wrote:
 don't think it's worth adding them until we can have full reflection  
 capabilities so we can get at elements of code and therefore get the  
 annotations associated with it.  I see much more usefulness for  
 annotations as reflection hints than as a replacement for keywords.

But we already have full reflection. It's called __traits. You can build a serialization library or "proper" (user friendly?) reflection on top of it.

I think you are the 1 millionth person to say it, and yet we still do not have a "user friendly" reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now. -Steve
Aug 04 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> wrote:

 Steven Schveighoffer wrote:
 don't think it's worth adding them until we can have full reflection  
 capabilities so we can get at elements of code and therefore get the  
 annotations associated with it.  I see much more usefulness for  
 annotations as reflection hints than as a replacement for keywords.

But we already have full reflection. It's called __traits. You can build a serialization library or "proper" (user friendly?) reflection on top of it.

not have a "user friendly" reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now.

The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it.

That's understandable, nobody can expect a language as young as D to have everything. But in reality, I think the *theory* that everything is there to build a reflection system is only proven when it actually happens. I'm sure when the enterprising person or persons go to develop it, they will find pieces missing from the static reflection system. So my point is that adding annotations before reflection works and is implemented makes little sense to me, because the usage of them will be crippled by the fact that reflection isn't complete. What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)("timeout=5,bar=\"hello\""); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. -Steve
Aug 04 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 04 Aug 2009 13:44:46 -0400, Ary Borenszweig <ary esperanto.org.ar>  
wrote:

 Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 What I'd like to see is something like this possible:

 void foo (int timeout, string bar, float f = 4.0);

 void foo(int timeout);

 call!(foo)("timeout=5,bar=\"hello\"");

 Taking into account the default value of f, what the parameters are  
 named, and which overload to call.  I could certainly do it with C#.

names, which currently does not exist.

Why do it with strings? Why not call!(foo)(5, "hello") with varaidic args?

Ok, say foo is: void foo(string bar, int timeout) -Steve
Aug 04 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 04 Aug 2009 14:46:34 -0400, Ary Borenszweig <ary esperanto.org.ar>  
wrote:

 Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 13:44:46 -0400, Ary Borenszweig  
 <ary esperanto.org.ar> wrote:

 Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 What I'd like to see is something like this possible:

 void foo (int timeout, string bar, float f = 4.0);

 void foo(int timeout);

 call!(foo)("timeout=5,bar=\"hello\"");

 Taking into account the default value of f, what the parameters are  
 named, and which overload to call.  I could certainly do it with C#.

names, which currently does not exist.

Why do it with strings? Why not call!(foo)(5, "hello") with varaidic args?

void foo(string bar, int timeout)

What's the difference?

The difference is, I'm saying I want to call foo with parameters identified by parameter name, not parameter order. -Steve
Aug 04 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 04 Aug 2009 15:56:16 -0400, Ary Borenszweig <ary esperanto.org.ar>  
wrote:

 Andrei Alexandrescu wrote:
  Well some don't like to need to remember the order of arguments.

But that's a way totally different thing discussed here. First you need to introduce argument names when invoking a function. void foo(int timeout, string bar) { .. } Can be used as: foo(timeout=5, bar="100") (with some other syntax, of course) Once you have that, you could do: call!(foo)(timeout=5, bar="100") Voilà!

It could also be accomplished via a fully implemented reflection library, which is my side topic for this thread branch :P For instance you could do this exact thing in C#, even though C# doesn't support named parameters. -Steve
Aug 04 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 04 Aug 2009 17:20:53 -0400, Rainer Deyke <rainerd eldwood.com>  
wrote:

 Steven Schveighoffer wrote:
 On Tue, 04 Aug 2009 15:56:16 -0400, Ary Borenszweig
 <ary esperanto.org.ar> wrote:
 foo(timeout=5, bar="100")

library, which is my side topic for this thread branch :P

No. The names of positional arguments are an implementation detail, and should not be exposed via reflection. Named arguments are different from positional arguments and require separate language support.

It works. See http://msdn.microsoft.com/en-us/library/system.reflection.parameterinfo.name.aspx
 Consider the ambiguity caused by function overloading:
   void f(int x, string y);
   void f(string y, int x);
   f(x = 1, y = "");

That is a case where the proposed function would throw an exception.
 Consider the implications of function pointers:
   void f(int x, int y);
   void g(int y, int x);
   (cond ? &f : &g)(x = 1, y = 2);

I don't see what this has to do with reflection... -Steve
Aug 04 2009
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 05 Aug 2009 07:20:38 +0400, Benji Smith <dlanguage benjismith.net>  
wrote:

 Frank Benoit wrote:
 Andrei Alexandrescu schrieb:
 Ary Borenszweig wrote:
 call!(foo)(5, "hello")

 with varaidic args?

Andrei

i can think of... 1. on the call side, it is documented for what the given values are used. 2. it may be possible to let all parameters have default values and for example just give a value for the last parameter. This is not possible with just the parameter order.

But these aren't issues with reflection. These are just the same function calling rules applied elsewhere in the language: 1) If you want to call a function: you must know its name. 2) If you want to pass parameters: you must know the correct order. I can't imagine a circumstance where someone uses reflection to call a function and knows how to create the correct set of arguments, but doesn't know what order to put them in. --benji

They are mostly used with optional parameters: void foo(int x = -1, int y = 42, bool b = false); foo(b: true);
Aug 05 2009
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

I like the idea of attributes having names that can never be identifiers, since adding new attributes will then, as you point out, never break existing code. But won't we lose this benefit if we later allow user-defined annotations? -Lars
Aug 03 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Lars T. Kyllingstad escribió:
 Ary Borenszweig wrote:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

I like the idea of attributes having names that can never be identifiers, since adding new attributes will then, as you point out, never break existing code. But won't we lose this benefit if we later allow user-defined annotations?

Kind of, but not totally. If you allow user-defined annotations, they need to be placed in a module, so they have a fully qualified name. You could have an foo.bar.align annotation (supposing "align" was already an annotation) and do: foo.bar.align int x; The compiler-instrinsic annotations would be defined in module object or something like that. That way you can disambiguate annotations with same names.
Aug 03 2009
prev sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
I'd rather see this put off until we have macros; then steal the syntax
to mean the same thing it does in Python.
Aug 03 2009