On Sun, Jul 22, 2012 at 6:15 PM, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> On 7/22/12, Philippe Sigaud <philippe.sigaud@gmail.com> wrote:
>> 2) Why classes, as opposed to structs?
>
> I think either way you'd need reference semantics.

Yeah, I agree, reference semantics look better.
And since there is a lot of duplication (struct info is a subtype of
class info, itself looking very uch like a module info, I guess a
mini-hierarchy is possible).
So I'm convinced classes look like a good fit.


> You could use structs as well, and actually I use structs in my codegenerator (with a similar layout to what Andrei posted). Each struct (e.g. Class/Function) stores Symbols, which are structs with an ID and a Type. I can look up each symbol in a SymTable which actually holds the structures with data. So a Symbol is like a fake pointer, and the SymTable would be the memory. I originally planned to use classes but some serialization frameworks didn't work with those so I settled using structs and a bit of template mixin magic instead.

Could you describe your design in this thread, and possibly link to some code?


> All of this std.reflection talk is quite exciting actually.

It is!

> If you had
> AST information about your entire D library you could do some really
> cool things. You could make a better documentation generator than
> ddoc, or export the AST into a file for a code-completion plugin, or
> create a wrapper C library which enables other languages to use your D
> library.

You could do macros. 'nuff said.

On 2012-07-22 16:28, Andrei Alexandrescu wrote:

> Something like that. Note that such a query is not particularly OO-ish,
> because getting a class' cone (totality of subclasses) works against the
> modularity that inheritance is meant for. I don't think we should make
> getting class cones particularly easy.

I see no reason to make it difficult on purpose.

-- 
/Jacob Carlborg

On 23-Jul-12 10:30, Philippe Sigaud wrote:
>
>> Well you're the resident crazy-stuff-during-compilation guy.
>
> Ah! I wish.
>
> I had this wonderful idea of having code be parsed at CT, semantically
> analyzed, transformed into some machine code at CT and... , oh wait.

I kind of did it...
regex pattern  ---parse---> bytecode ---generate D code---> profit.

BTW you can avoid machine code, just use D code as glorified backend :)
(and get optimizations for free, yay!)


-- 
Dmitry Olshansky

On Mon, Jul 23, 2012 at 8:41 AM, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:
> On 23-Jul-12 10:30, Philippe Sigaud wrote:
>>
>>
>>> Well you're the resident crazy-stuff-during-compilation guy.
>>
>>
>> Ah! I wish.
>>
>> I had this wonderful idea of having code be parsed at CT, semantically analyzed, transformed into some machine code at CT and... , oh wait.
>
>
> I kind of did it...
> regex pattern  ---parse---> bytecode ---generate D code---> profit.
>
> BTW you can avoid machine code, just use D code as glorified backend :)
> (and get optimizations for free, yay!)

Hey, that was a joke, about implementing a D compiler in D, to be
executed at CT by the real D compiler to basically do its job a second
time, only worse :)
But yes, your regex work is a great example. I should have a look at
the code once more.

On 7/23/12 2:39 AM, Jacob Carlborg wrote:
> On 2012-07-22 16:28, Andrei Alexandrescu wrote:
>
>> Something like that. Note that such a query is not particularly OO-ish,
>> because getting a class' cone (totality of subclasses) works against the
>> modularity that inheritance is meant for. I don't think we should make
>> getting class cones particularly easy.
>
> I see no reason to make it difficult on purpose.

The reason is that often the cone would be incomplete and therefore confusing. It would also foster non-modular approaches to doing things.

Andrei

On 23-Jul-12 10:47, Philippe Sigaud wrote:
> On Mon, Jul 23, 2012 at 8:41 AM, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:
>> On 23-Jul-12 10:30, Philippe Sigaud wrote:
>>>
>>>
>>>> Well you're the resident crazy-stuff-during-compilation guy.
>>>
>>>
>>> Ah! I wish.
>>>
>>> I had this wonderful idea of having code be parsed at CT, semantically
>>> analyzed, transformed into some machine code at CT and... , oh wait.
>>
>>
>> I kind of did it...
>> regex pattern  ---parse---> bytecode ---generate D code---> profit.
>>
>> BTW you can avoid machine code, just use D code as glorified backend :)
>> (and get optimizations for free, yay!)
>
> Hey, that was a joke, about implementing a D compiler in D, to be
> executed at CT by the real D compiler to basically do its job a second
> time, only worse :)

Yeah, now I think I got it. Could be a nice benchmark for CTFE though :)

> But yes, your regex work is a great example. I should have a look at
> the code once more.
>

I'd advice to wait a bit ... it's not really in a good shape (to read it) as there have been tons of improvements in CTFE since the last time I've touched it. I'll have to revisit it and remove some roundabout workarounds.

-- 
Dmitry Olshansky

On 2012-07-23 08:35, Philippe Sigaud wrote:
> On Sun, Jul 22, 2012 at 6:15 PM, Andrej Mitrovic

>> If you had
>> AST information about your entire D library you could do some really
>> cool things. You could make a better documentation generator than
>> ddoc, or export the AST into a file for a code-completion plugin, or
>> create a wrapper C library which enables other languages to use your D
>> library.
>
> You could do macros. 'nuff said.

If I recall correctly, Scala uses its reflection API as a part off its macros.

-- 
/Jacob Carlborg

On Mon, 23 Jul 2012 08:32:37 +0200, Philippe Sigaud <philippe.sigaud@gmail.com> wrote:

> Maybe I don't get your comment, but AFAICT, the language does allow
> you to use CTFE parameters values as arguments to templates:
>
> template Twice(double d)
> {
>     enum Twice = d * 2;
> }
>
> double foo(double d)
> {
>     return d+1.0;
> }
>
> void main()
> {
>     enum t = Twice!(foo(1.0));
>     pragma(msg, t);
> }

Wrong way around. Try this:

template Twice(double d)
{
    enum Twice = d * 2;
}

double foo(double d)
{
    return Twice!d;
}

void main()
{
    enum  t = foo(1.0);
    pragma(msg, t);
}

-- 
Simen

On Mon, Jul 23, 2012 at 9:46 AM, Simen Kjaeraas <simen.kjaras@gmail.com> wrote:

> Wrong way around. Try this:
>
>
> template Twice(double d)
> {
>     enum Twice = d * 2;
> }
>
> double foo(double d)
> {
>     return Twice!d;
> }
>
> void main()
> {
>     enum  t = foo(1.0);
>     pragma(msg, t);
> }

Ah, that, OK. And __ctfe does not help.
Would it really limit the proposed scheme for std.reflection?

On Sunday, 22 July 2012 at 13:39:31 UTC, Philippe Sigaud wrote:
> 4) How would that allows queries like "Here is class C, give me all
> its available subclasses."? Hmm, wait, I get it: extract classes from
> the module, and recursively from imported modules. From these classes,
> extract the parent classes and so on, until the search ranged over the
> whole inheritance tree. I guess inheritance info could be standard
> enough for std.reflection to provide such a search.

You can't do that without breaking the module system – as long as a class is not final (and then it doesn't make much sense to ask for its subclasses anyway), somebody can always extend it in a module completely separate from the code making the query.

To illustrate what I mean, let's assume you define a class Foo in a module A. The user imports A from a second module B, and potentially extends Foo there. Now, if it was possible to get all possible subclasses in A, this would lead to information leaking from B to A, while the import graph only allows the other direction. As a consequence, all kinds of issues related to order dependence, separate compilation, etc. would arise.

David