View mode: basic / threaded / horizontal-split · Log in · Help
July 23, 2012
Re: Time for std.reflection
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.
July 23, 2012
Re: Time for std.reflection
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
July 23, 2012
Re: Time for std.reflection
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
July 23, 2012
Re: Time for std.reflection
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.
July 23, 2012
Re: Time for std.reflection
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
July 23, 2012
Re: Time for std.reflection
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
July 23, 2012
Re: Time for std.reflection
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
July 23, 2012
Re: Time for std.reflection
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
July 23, 2012
Re: Time for std.reflection
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?
July 23, 2012
Re: Time 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
1 2 3 4 5
Top | Discussion index | About this forum | D home