January 06, 2021
On Wednesday, 6 January 2021 at 13:20:35 UTC, Jacob Carlborg wrote:
>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"
>});

Reminds me on Scala macros.

Yes it would be nice, but is it likely to get them in D?

If we're allowed to read any source code from our project, we could write our own macro framework to parse strings of code though the work is doubled as they have to be expanded and re-parsed again by the compiler.
January 06, 2021
On 2021-01-06 14:56, sighoya wrote:

> Reminds me on Scala macros.

Yes, that's the main inspiration. See DIP 50 [1].

> Yes it would be nice, but is it likely to get them in D?

Extremely unlikely.

> If we're allowed to read any source code from our project, we could write our own macro framework to parse strings of code though the work is doubled as they have to be expanded and re-parsed again by the compiler.

Yes, that's possible in theory. DMD could be used as a library to achieve this. The problem is that DMD doesn't contain enough source code location information to do source code refactoring. Also, it doesn't help that the analysis the compiler performs is destructive.

https://wiki.dlang.org/DIP50

-- 
/Jacob Carlborg
January 06, 2021
On 2021-01-06 17:35, Jacob Carlborg wrote:
> On 2021-01-06 14:56, sighoya wrote:
>  
>> Yes it would be nice, but is it likely to get them in D?
> 
> Extremely unlikely.

But this conversation is the actual API to the AST. That could be provided with supporting AST macros.

-- 
/Jacob Carlborg
January 08, 2021
On Saturday, 2 January 2021 at 11:59:39 UTC, claptrap wrote:
...
> "Spotted dick" is a pudding made with suet and dried fruit.

Haha
January 12, 2021
On Wednesday, 6 January 2021 at 13:52:39 UTC, sighoya wrote:
> 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){...}
> ```

Is this a suggestion or what you think the semantics' consequences are? Because I fail to see how the first one is any different from a template. If I replace `__type__ type` by `int i`, it is still a compile-time argument. In one instance, the value argument is (or represents) a type. That doesn't change the semantics, or does it?
January 13, 2021
On Tuesday, 12 January 2021 at 20:41:02 UTC, Q. Schroll wrote:
> On Wednesday, 6 January 2021 at 13:52:39 UTC, sighoya wrote:
>> 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){...}
>> ```
>
> Is this a suggestion or what you think the semantics' consequences are? Because I fail to see how the first one is any different from a template. If I replace `__type__ type` by `int i`, it is still a compile-time argument. In one instance, the value argument is (or represents) a type. That doesn't change the semantics, or does it?

A value type can only be used as type if it a statically known value,
which in the above example is the case.
But I doubt it will work with the ITFI functionality as it is currently implemented.

I have never intended this usecase, I think that we should be able to get it to work,
but I am not sure if that's the most productive thing to do.

January 13, 2021
On Tuesday, 12 January 2021 at 20:41:02 UTC, Q. Schroll wrote:
> On Wednesday, 6 January 2021 at 13:52:39 UTC, sighoya wrote:
>> 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){...}
>> ```
>
> If I replace `__type__ type` by `int i`, it is still a compile-time argument.

No, it would applicate to:

```
method!(int) ==> demangledMethodInt(int value) {...}
```

Just as for the second case, however, the internals are different.

>That doesn't change the semantics, or does it?

I shouldn't except that I think the former part have to be eagerly checked, so you have naturally generics in D.

My point was not to introduce this scenario because we have now two ways to do the same thing.

Rather, I'm advocating the use of type functions to map types to types only s.t. the ugly parts of D through AliasSeq become obsolete.

Type constructors should be served only by templates, we can improve them to behave more like generics for example by providing better error messages or inferred where constraints.
January 13, 2021
On Wednesday, 13 January 2021 at 17:09:59 UTC, Stefan Koch wrote:
> On Tuesday, 12 January 2021 at 20:41:02 UTC, Q. Schroll wrote:
>> On Wednesday, 6 January 2021 at 13:52:39 UTC, sighoya wrote:
>>> 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){...}
>>> ```
>>
>> Is this a suggestion or what you think the semantics' consequences are? Because I fail to see how the first one is any different from a template. If I replace `__type__ type` by `int i`, it is still a compile-time argument. In one instance, the value argument is (or represents) a type. That doesn't change the semantics, or does it?
>
> A value type can only be used as type if it a statically known value,
> which in the above example is the case.
> But I doubt it will work with the ITFI functionality as it is currently implemented.
>
> I have never intended this usecase, I think that we should be able to get it to work,
> but I am not sure if that's the most productive thing to do.

I think the usefulness of typefunctions will derive from treating them as an instance of some type like any other. __type__ is conceptually equivalent to having some string mixin of the type it represents. Maybe you shouldn't do so, but a __type__ in a template is just any other template argument - it shouldn't be rewritten to anything else.

Stefan, I'm thinking of writing a short document (DIP-lite) to document where I think typefunctions should be specified and used, maybe you could look over it?
January 14, 2021
On Wednesday, 13 January 2021 at 20:41:38 UTC, Max Haughton wrote:
> On Wednesday, 13 January 2021 at 17:09:59 UTC, Stefan Koch wrote:
>> On Tuesday, 12 January 2021 at 20:41:02 UTC, Q. Schroll wrote:
>>> On Wednesday, 6 January 2021 at 13:52:39 UTC, sighoya wrote:
>>>> 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){...}
>>>> ```
>>>
>>> Is this a suggestion or what you think the semantics' consequences are? Because I fail to see how the first one is any different from a template. If I replace `__type__ type` by `int i`, it is still a compile-time argument. In one instance, the value argument is (or represents) a type. That doesn't change the semantics, or does it?
>>
>> A value type can only be used as type if it a statically known value,
>> which in the above example is the case.
>> But I doubt it will work with the ITFI functionality as it is currently implemented.
>>
>> I have never intended this usecase, I think that we should be able to get it to work,
>> but I am not sure if that's the most productive thing to do.
>
> I think the usefulness of typefunctions will derive from treating them as an instance of some type like any other. __type__ is conceptually equivalent to having some string mixin of the type it represents. Maybe you shouldn't do so, but a __type__ in a template is just any other template argument - it shouldn't be rewritten to anything else.
>
> Stefan, I'm thinking of writing a short document (DIP-lite) to document where I think typefunctions should be specified and used, maybe you could look over it?

Sure I am happy to have a look at your document.

One of the reasons that __type__ is not actually a real type.
But a type value is because I want typefunctions to be well functions.
They should be mono-morphic (Only have one shape). Such that you do not need to generate new function bodies on every call with a different type argument.
In order for that to be the case, type arguments must not be able to change the shape of the body.
Because if they did, you would be equivalent to templates. (I.E. you cannot proof that the shape does not change from one set of template arguments to the other)
Since generation of the multiple shapes + symbols that templates produce such a big strain on the compiler, and compile time;
Typefunctions disallow that statically.
It also makes it easier to reason about as multiple shapes are hard to keep in ones head.
1 2 3 4
Next ›   Last »