January 02, 2021
On Saturday, 2 January 2021 at 19:06:32 UTC, Stefan Koch wrote:

>That's needlessly increasing surface knowledge one needs to have.

Therefore, I recommended mapping `sizeof` to `tsize` and `alignof` to `talign`.

If this isn't possible, then yes you got the point.

> The reason that the existing structure typeinfo is not used much at all is because it's less appealing than using the template approach, even if that has other issues.

Because you can't even do that yet,
1.) we need to lift typeid() to be callable at compile time
2.) and to provide a way to convert a typeinfo back as a second class type, i.e. a normal type we use in templates.

January 02, 2021
On Saturday, 2 January 2021 at 22:26:32 UTC, sighoya wrote:
> On Saturday, 2 January 2021 at 19:06:32 UTC, Stefan Koch wrote:
>
>>That's needlessly increasing surface knowledge one needs to have.
>
> Therefore, I recommended mapping `sizeof` to `tsize` and `alignof` to `talign`.
>
> If this isn't possible, then yes you got the point.
>
It isn't possible.

>> The reason that the existing structure typeinfo is not used much at all is because it's less appealing than using the template approach, even if that has other issues.
>
> Because you can't even do that yet,
> 1.) we need to lift typeid() to be callable at compile time
> 2.) and to provide a way to convert a typeinfo back as a second class type, i.e. a normal type we use in templates.

You can use typeid at compiletime.
I know because I implemented it.

But TypeInfo is way too incomplete, you don't just need alignment or size, you also need members, UDAs, vtbl layouts and many more.

I don't see how one can stuff all that into a statically available, datastructure without blowing out compile times.
January 03, 2021
On Saturday, 2 January 2021 at 22:47:29 UTC, Stefan Koch wrote:
> I don't see how one can stuff all that into a statically available, datastructure without blowing out compile times.

Build it dynamically using caching (e.g. tables)?
That is the standard way of doing unification (e.g. prolog)?



January 03, 2021
On Sunday, 3 January 2021 at 11:49:34 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 2 January 2021 at 22:47:29 UTC, Stefan Koch wrote:
>> I don't see how one can stuff all that into a statically available, datastructure without blowing out compile times.
>
> Build it dynamically using caching (e.g. tables)?
> That is the standard way of doing unification (e.g. prolog)?

If I expose it as a 'real' datastructure rather than a langauge builtin I cannot build it dynamically, it needs to be there for use at runtime as well.
January 03, 2021
On Sunday, 3 January 2021 at 12:06:18 UTC, Stefan Koch wrote:
> If I expose it as a 'real' datastructure rather than a langauge builtin I cannot build it dynamically, it needs to be there for use at runtime as well.

Maybe if you constrain it so that all accessed attributes can be determined at compile time?

So, for each compiled d-module you record what information that d-module will try to access at runtime. Then you at the "link stage" generate it?

January 03, 2021
On Saturday, 2 January 2021 at 22:47:29 UTC, Stefan Koch wrote:
> You can use typeid at compiletime.
> I know because I implemented it.

```

void main()
{
    import std.algorithm, std.stdio, std.file, std.range;
    static assert(typeid(int)==typeid(float));
}

onlineapp.d(4): Error: static variable typeid(int) cannot be read at compile time
onlineapp.d(4):        called from here: opEquals(typeid(int), typeid(float))
onlineapp.d(4):        while evaluating: static assert(typeid(int) == typeid(float))

```

Or did you mean you have implemented it in your newCTFE branch?
January 03, 2021
On Sunday, 3 January 2021 at 14:05:21 UTC, sighoya wrote:
> On Saturday, 2 January 2021 at 22:47:29 UTC, Stefan Koch wrote:
>> You can use typeid at compiletime.
>> I know because I implemented it.
>
> ```
>
> void main()
> {
>     import std.algorithm, std.stdio, std.file, std.range;
>     static assert(typeid(int)==typeid(float));
> }
>
> onlineapp.d(4): Error: static variable typeid(int) cannot be read at compile time
> onlineapp.d(4):        called from here: opEquals(typeid(int), typeid(float))
> onlineapp.d(4):        while evaluating: static assert(typeid(int) == typeid(float))
>
> ```
>
> Or did you mean you have implemented it in your newCTFE branch?

No, I did not mean that.
But the support for typeid in CTFE is not very solid at the moment.
Perhaps you can only access certain properties of typeid.
The reason being that you cannot generate an actual TypeInfo hence the compiler has to fake  it.
January 06, 2021
On 2021-01-02 10:28, Stefan Koch wrote:

> The issue here is knowing when the type is complete.
> Imagine you did not put int into there, but some template or another typefunction result.
> At which point can I take the lock and register myself in the type universe?
> And how do I make sure I don't have to type LinkedList(f(x, g(y), j(z))) to reference the type?
> 
> I guess I could create the name to just be "LinkedList(f(x, g(y), j(z)))" where f(x, g(y), j(z))) is eagerly evaluated, and then the name is LinkedList(float) or something like that.
> 
> But that seems like reinventing templates with all their troubles...

I don't know. I'm not the expert.

> perhaps it's still worthwhile though?

I like the syntax at least :)

Your example doesn't have the same problem because it's explicitly calling `__internal__magic__registerType`?


> Hmm I wanted to avoid having to puzzle ast nodes together, as I find it rather counter verbose to use.
> simple stuff like;
> mixin(f(a, b));
> becomes
> new CallExp(findFunction("f"), [findVariableExpression("a"), findVariableExpression("b")].insertIntoTreeInPlace();

There's nothing that prevents building helper functions on top of the low level AST.

In my idea for AST macros, there would be support for quasi-quoting and splicing. It's implemented as a built-in function that converts the internal AST (defined in the compiler) to the external AST (defined in druntime).

ast(f(a, b)); // single line

ast({ // multiple statements
    int a = 3;
    int b = 4;
    f(a, b);
});

auto name = ast(a);

ast({
    int $name = 3; // splicing. This will declare a variable with the name "a"
});

-- 
/Jacob Carlborg
January 06, 2021
On 2021-01-02 20:04, Max Haughton wrote:

> Did you get as far as actually emitting it to be used during compilation? I'm not about the best way of actually using the AST structure inside the compiler

Yes, at least the most basic AST nodes. Converting the internal AST (defined in the compiler) to the external AST (defined in druntime) is the easy part. It's more difficult to do the conversion the other direction. It's a matter of knowing how to construct the internal AST node to make behave the same way as if you had written the corresponding source code.

-- 
/Jacob Carlborg
January 06, 2021
On Saturday, 2 January 2021 at 09:28:15 UTC, Stefan Koch wrote:
>I guess I could create the name to just be "LinkedList(f(x, g(y), j(z)))" where f(x, g(y), j(z))) is eagerly evaluated, and then the name is LinkedList(float) or something like that.

>But that seems like reinventing templates with all their troubles...
>perhaps it's still worthwhile though?


If we allow a __type__ in type position, indirectly or directly, we're able to implement generics known from other languages, e.g.:

```
method(__type__ type)(type value){...}
```
vs

```
method(T)(T value){...}
```

Although I appreciate a more idiomatic form of generics, we would provide two ways to do the same thing.

Moreover, __type__ generics have, as you said, to be eagerly checked, and we are forced to provide full constraints with the potential to forcefully up propagate them.

Even though this is the more correct way to set up things it doesn't feel very D-ish or kiss like, don't know if its worth the cost.

Theoretically, template systems could provide better errors than generic systems because their error messages would be of concrete kind while those of generics are of abstract kind.
The only problem is how to back propagate template error messages such they are meaningful in downstream code, it's possible, but it is a lot of work.