Idea for @annotations

[Mehrdad]

On 8/1/2011 12:00 AM, KennyTM~ wrote:
> On Aug 1, 11 13:42, %u wrote:
>> mixin memoize!(function int(int n) { ... });
>
> I believe you mean
>
>     alias memoize!(<that function>) fib;
Yeah, same difference. :)

> Also, self-reference should be handled:
>
>     @memoize
>     ulong fib(ulong n) {
>        return n < 2 ? 1 : fib(n - 2) + fib(n - 1);
>     //                    ^^^ recursion^^^
>     }
>
>     @exportName("F/List")
>     class F_List {
>        int content;
>        F_List next;
>     // ^^^^^^ self-reference
>     }
Uh-oh... Houston, I think we have a problem. :\  How would you go about 
doing this, if the return type is inferred and the annotation template 
_depends_ on the return type?
You could either go on a "best-effort" basis on the compiler, or just 
assume that internal references (whether direct or indirect) assume 
un-annotated symbols. But we could have different problems that way too 
(i.e. security holes: calling the same method from different places 
producing different results, etc.) so this would need lots of thinking 
to work correctly.
Hopefully we can figure something out, though! :)

On 8/1/2011 1:05 AM, Peter Alexander wrote:
> On 1/08/11 6:42 AM, %u wrote:
>> An idea for a potential use of annotations:
>>
>> How about being able to annotate _anything_ with a template?
> What problem does this solve? Is it just syntax sugar? If so, is it 
> worth complicating the language even more for this convenience? 
(1) It's beautiful!
(2) It documents the fact that you're doing a transformation on 
something else
(3) It also works pretty well for non-transforming annotations (i.e. 
those that are there just for metadata) -- you could easy add static 
assertions inside the template and return the original alias, etc.
(4) We're going to have annotations sooner or later (I hope?) so this is 
just an idea on how to make them work, without introducing a new kind of 
annotation declaration (since it works with pretty much any old template).
(5) To my (VERY) limited knowledge, this could be incredibly useful 
Aspect-Oriented Programming, if I've understood the concept correctly. I 
could very well be wrong, though.

>> Implementing this would obviously be difficult as I would assume,
>> but does it sound like a reasonable idea?
> Would you mind to write a DIP? 
> (http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs)
I wouldn't mind, but I think we might want to get some details straight 
first. I can't think of an obvious solution to the self-reference issue, 
so we should probably figure that part out before I actually suggest 
this for inclusion, right? :)