another idea for compile time functions

[janderson]

Andrei Alexandrescu (See Website For Email) wrote:
> janderson wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> Hasan Aljudy wrote:
>>> [snip]
>>>> The trick may lie in letting the compiler recognize these kind of 
>>>> functions. A simple solution might me to come up with a new 
>>>> attribute; let's call it "meta":
>>>> # meta int add( int x, int y ) { return x + y; }
>>>> This attribute will assist the compiler in recognizing that this 
>>>> function can be computed at compile time if it's given constant 
>>>> arguments.
>>>
>>> This is much in keep with my idea on how metaprogramming should be 
>>> done, with the little semantic nit that "meta" should be "dual" as 
>>> add has dual functionality.
>>>
>>> The attribute is not even needed if meta-code is flagged as such. My 
>>> thoughts currently gravitate around the idea of using mixin as an 
>>> escape into compile-time world. Anything that's printed to standard 
>>> output in compile-time world becomes code, e.g. (using your function):
>>>
>>> mixin
>>> {
>>>   writefln("int x = ", add(10, 20), ";");
>>> }
>>>
>>> is entirely equivalent to:
>>>
>>> int x = 30;
>>>
>>> No annotation is needed on add because mixin clarifies that it's 
>>> called during compilation. The compiler will complain if add cannot 
>>> be user dually.
>>>
>>> Using mixin and write as separation devices makes it very clear what 
>>> is to be done when; otherwise, it quickly becomes confusing what code 
>>> is meant to actually get evaluated eagerly, and what code is to 
>>> actually be "output" for compilation.
>>>
>>> The not-so-nice thing is that we get to manipulate numbers, strings, 
>>> and arrays, not trees like in LISP.
>>>
>>>
>>> Andrei
>>
>> Although I like this idea, I fear it will not work for anything hidden 
>> in a library (if you are using something that is moved to a .lib, your 
>> code will stop working).  Maybe that's ok.  Actually now I think about 
>> it, that would be safer, because even if the D compiler could put an 
>> "ok" signatures in a library, someone could create fake signatures.
> 
> Good point. This is reasonable. To execute code during compilation it's 
> reasonable to expect transparency. C++ commercial vendors did not really 
> suffer financial loss due to this requirement, and at any rate, OSS is 
> on the rise :o).
> 
>> It could get confusing if you don't know which functions will work and 
>> which won't.  Perhaps the compiler could help there (spit out a list 
>> of functions u can use or something).
> 
> Yes, that's a documentation issue. The nice thing is that a plethora of 
> really useful functions (e.g. string manipulation) can be written in D's 
> subset that can be interpreted. Pretty much the entire string library 
> will be meta-executable. No more need for the metastrings lib!
> 
>> I think the compiler would compile these commands on demand and cache 
>> them so it doesn't need to do them every time.  That would help a lot. 
>> It could even cache results so it only needs to compute them once.
>>
>> Anyways, there i think there is so much possibility with compile time 
>> coding.
> 
> Me too. Once compile-time interpretation (and mutation) makes it in, I 
> think there's no fear of efficiency loss anymore. Speed will be 
> comparable to that of any interpreted code, and there are entire 
> communities that don't have a problem with that.
> 
> The question is, what is the subset of D that can be interpreted? I'm 
> thinking:
> 
> * Basic data types (they will be stored as a dynamically-typed variant 
> anyway), except pointers to functions and delegates.

Agreed. Pointers are a likely area for abuse.  Maybe they could be added 
at a later time once we understand how this goes in practice.

> 
> * Arrays and hashes
> 
> * Basic expressions (except 'is', 'delete' et al.)
> 
> * if, for, foreach, while, do, switch, continue, break, return
> 
> I'm constructing this list thinking what it takes to write basic data 
> manipulation functions. What did I forget?
> 
> 
> Andrei

This is a good start.

* Import and mixin's as well so we can read in stuff (safely) at compile 
time and do self reflection and stuff.

* Classes + structs would be a nice addition, although they wouldn't be 
need in the first additions.  Classes would mean you'd need a GC and 
would add more complications.  I think once a foundation is in they 
could be added with more discussions.  OO is a powerful abstraction 
concept so would be useful in simplifying the compile-time code.

-Joel