www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What type functions mean on a language level

reply Stefan Koch <uplink.coder googlemail.com> writes:
Good Evening and Happy new year to everyone.

After a stressful move to the UK in uncertain times, I am now 
free and able to enjoy the last day of my holiday.

I am currently not working on DMD but on a different hobby 
project instead.

So with some distance between me and the implementation details I 
think it's a good idea to talk about what type functions mean for 
the language (regardless of all the architecture issues  in DMD 
which make an implementation iffy)

Specification wise type functions require two statements to be 
added.

"Under certain conditions a type may be implicitly converted to a 
value of type __type__."
and
"Under certain conditions a value of type __type__ may be 
converted to a type."

That's it.

Everything else is just working regularly with value and 
expressions.

let me give you an example.

enum TK
{
   Integral,
   Floating,
   Other,
}

string ts(__type__ t)
{
   switch (t)
   {
      case ubyte, byte, ushort, short, int, uint, long, ulong:
          return TK.Integral;
      case double, float, real :
          return TK.Floating;
      default:
          return TK.Other;
   }
}


this looks like it would require a new construct right?
infact it does not.

since the types are used in a ctfe context where values are 
expected they get implicitly converted to values.

so what happens is:
string ts(__type__ t)
{
      case cast(__type__)ubyte, cast(__type__)byte, 
cast(__type__)ushort, cast(__type__)short, cast(__type__)int, 
cast(__type__)uint, cast(__type__)long, cast(__type__)ulong:
          return TK.Integral;
      case cast(__type__)double, cast(__type__)float, 
cast(__type__)real :
          return TK.Floating;
      default:
          return TK.Other;
   }
}

which converts the types into values, the same stuff as integers 
:)
and since a switch works with integers it works with types as 
well.

And that is precisely the reason why I was so excited about my 
invention/discovery.

It just fits in. And requires minimal changes to the spec.

You will see that I've punted on the definition of the 
circumstances in which the implicit conversion from type to value 
and vice versa may occur.
That's just to keep the post short and avoid many long and boring 
words ;)

I do hope you get as excited as me when reading this.

Regards,
Stefan
Jan 01
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 1 January 2021 at 23:26:58 UTC, Stefan Koch wrote:
 Good Evening and Happy new year to everyone.

 After a stressful move to the UK in uncertain times, I am now 
 free and able to enjoy the last day of my holiday.

 I am currently not working on DMD but on a different hobby 
 project instead.

 So with some distance between me and the implementation details 
 I think it's a good idea to talk about what type functions mean 
 for the language (regardless of all the architecture issues  in 
 DMD which make an implementation iffy)

 Specification wise type functions require two statements to be 
 added.

 "Under certain conditions a type may be implicitly converted to 
 a value of type __type__."
 and
 "Under certain conditions a value of type __type__ may be 
 converted to a type."

 That's it.

 Everything else is just working regularly with value and 
 expressions.

 let me give you an example.

 enum TK
 {
   Integral,
   Floating,
   Other,
 }

 string ts(__type__ t)
 {
   switch (t)
   {
      case ubyte, byte, ushort, short, int, uint, long, ulong:
          return TK.Integral;
      case double, float, real :
          return TK.Floating;
      default:
          return TK.Other;
   }
 }


 this looks like it would require a new construct right?
 infact it does not.

 since the types are used in a ctfe context where values are 
 expected they get implicitly converted to values.

 so what happens is:
 string ts(__type__ t)
 {
      case cast(__type__)ubyte, cast(__type__)byte, 
 cast(__type__)ushort, cast(__type__)short, cast(__type__)int, 
 cast(__type__)uint, cast(__type__)long, cast(__type__)ulong:
          return TK.Integral;
      case cast(__type__)double, cast(__type__)float, 
 cast(__type__)real :
          return TK.Floating;
      default:
          return TK.Other;
   }
 }

 which converts the types into values, the same stuff as 
 integers :)
 and since a switch works with integers it works with types as 
 well.

 And that is precisely the reason why I was so excited about my 
 invention/discovery.

 It just fits in. And requires minimal changes to the spec.

 You will see that I've punted on the definition of the 
 circumstances in which the implicit conversion from type to 
 value and vice versa may occur.
 That's just to keep the post short and avoid many long and 
 boring words ;)

 I do hope you get as excited as me when reading this.

 Regards,
 Stefan
Why can't __type__ be named "any" as indication that it is a top type for all types?
Jan 01
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 1 January 2021 at 23:32:25 UTC, 12345swordy wrote:
 
 Why can't __type__ be named "any" as indication that it is a 
 top type for all types?
__type__ is the type of types, it is not Top. well technically it's the type of type values which are not types themselves but may be converted to types, and be created from types. Also the name any is already used by phobos templates, making it unavailable. After type functions are in; I plan on generalizing further and introduce a proper TOP type. Which can bind to anything (like T... in a template) But for now I want to gently introduce the concept.
Jan 01
parent Jacob Carlborg <doob me.com> writes:
On 2021-01-02 00:55, Stefan Koch wrote:

 After type functions are in; I plan on generalizing further and 
 introduce a proper TOP type.
 Which can bind to anything (like T... in a template)
Isn't that what `alias` parameters do? -- /Jacob Carlborg
Jan 02
prev sibling next sibling parent reply Max Haughton <maxhaton gmail.com> writes:
On Friday, 1 January 2021 at 23:26:58 UTC, Stefan Koch wrote:
 Good Evening and Happy new year to everyone.

 After a stressful move to the UK in uncertain times, I am now 
 free and able to enjoy the last day of my holiday.

 I am currently not working on DMD but on a different hobby 
 project instead.

 So with some distance between me and the implementation details 
 I think it's a good idea to talk about what type functions mean 
 for the language (regardless of all the architecture issues  in 
 DMD which make an implementation iffy)

 Specification wise type functions require two statements to be 
 added.

 "Under certain conditions a type may be implicitly converted to 
 a value of type __type__."
 and
 "Under certain conditions a value of type __type__ may be 
 converted to a type."

 That's it.

 Everything else is just working regularly with value and 
 expressions.

 let me give you an example.

 enum TK
 {
   Integral,
   Floating,
   Other,
 }

 string ts(__type__ t)
 {
   switch (t)
   {
      case ubyte, byte, ushort, short, int, uint, long, ulong:
          return TK.Integral;
      case double, float, real :
          return TK.Floating;
      default:
          return TK.Other;
   }
 }


 this looks like it would require a new construct right?
 infact it does not.

 since the types are used in a ctfe context where values are 
 expected they get implicitly converted to values.

 so what happens is:
 string ts(__type__ t)
 {
      case cast(__type__)ubyte, cast(__type__)byte, 
 cast(__type__)ushort, cast(__type__)short, cast(__type__)int, 
 cast(__type__)uint, cast(__type__)long, cast(__type__)ulong:
          return TK.Integral;
      case cast(__type__)double, cast(__type__)float, 
 cast(__type__)real :
          return TK.Floating;
      default:
          return TK.Other;
   }
 }

 which converts the types into values, the same stuff as 
 integers :)
 and since a switch works with integers it works with types as 
 well.

 And that is precisely the reason why I was so excited about my 
 invention/discovery.

 It just fits in. And requires minimal changes to the spec.

 You will see that I've punted on the definition of the 
 circumstances in which the implicit conversion from type to 
 value and vice versa may occur.
 That's just to keep the post short and avoid many long and 
 boring words ;)

 I do hope you get as excited as me when reading this.

 Regards,
 Stefan
I like this idea quite a lot, some questions/points: 1. How far does this go? Are we just exposing the frontends concept of a type (i.e. the contents of dmd.mtype) or a abstraction over it? Can I (say) make an entirely new type like a struct like I would with a mixin? 2. I don't think avoiding spec changes is necessarily a good thing - D is already fairly murky in that regard so (wrt previous point) specifying exactly what typefunctions can do is probably a good thing. 3. I think a similar thing wouldn't be all that bad for the AST - read-only I should say (the only that worries me in the abstract about that is that dmd's AST isn't very consistent in its API) - i.e. Being able to access it as a regular (say) class at CTFE rather than adding more and more and more __traits.
Jan 01
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 1 January 2021 at 23:52:58 UTC, Max Haughton wrote:
 On Friday, 1 January 2021 at 23:26:58 UTC, Stefan Koch wrote:
 Good Evening and Happy new year to everyone.

 After a stressful move to the UK in uncertain times, I am now 
 free and able to enjoy the last day of my holiday.

 I am currently not working on DMD but on a different hobby 
 project instead.

 So with some distance between me and the implementation 
 details I think it's a good idea to talk about what type 
 functions mean for the language (regardless of all the 
 architecture issues  in DMD which make an implementation iffy)

 Specification wise type functions require two statements to be 
 added.

 "Under certain conditions a type may be implicitly converted 
 to a value of type __type__."
 and
 "Under certain conditions a value of type __type__ may be 
 converted to a type."

 That's it.

 Everything else is just working regularly with value and 
 expressions.

 let me give you an example.

 enum TK
 {
   Integral,
   Floating,
   Other,
 }

 string ts(__type__ t)
 {
   switch (t)
   {
      case ubyte, byte, ushort, short, int, uint, long, ulong:
          return TK.Integral;
      case double, float, real :
          return TK.Floating;
      default:
          return TK.Other;
   }
 }


 this looks like it would require a new construct right?
 infact it does not.

 since the types are used in a ctfe context where values are 
 expected they get implicitly converted to values.

 so what happens is:
 string ts(__type__ t)
 {
      case cast(__type__)ubyte, cast(__type__)byte, 
 cast(__type__)ushort, cast(__type__)short, cast(__type__)int, 
 cast(__type__)uint, cast(__type__)long, cast(__type__)ulong:
          return TK.Integral;
      case cast(__type__)double, cast(__type__)float, 
 cast(__type__)real :
          return TK.Floating;
      default:
          return TK.Other;
   }
 }

 which converts the types into values, the same stuff as 
 integers :)
 and since a switch works with integers it works with types as 
 well.

 And that is precisely the reason why I was so excited about my 
 invention/discovery.

 It just fits in. And requires minimal changes to the spec.

 You will see that I've punted on the definition of the 
 circumstances in which the implicit conversion from type to 
 value and vice versa may occur.
 That's just to keep the post short and avoid many long and 
 boring words ;)

 I do hope you get as excited as me when reading this.

 Regards,
 Stefan
I like this idea quite a lot, some questions/points: 1. How far does this go? Are we just exposing the frontends concept of a type (i.e. the contents of dmd.mtype) or a abstraction over it? Can I (say) make an entirely new type like a struct like I would with a mixin?
I used to think that creating entirely new types was impossible, because the new type would not have a mangle. Now I see that I could just do the same thing as a template would do and give it a mangle of all the arguments to the type functions; that however has the unpleasant side effect of creating potentially giant mangles, which I want to avoid. Therefore the current implementation disallows creation of new types. Also I am not sure how I want the api to look like. Perhaps like this? struct StructField { __type__ type; string name } __type__ makeStruct (string name, StructField[] fields) { __struct__ sresult = __interal__magic__makeStruct(name); foreach(f;fields) { sresult.addField(f.name, f.type); } return __internal__magic__registerType(sresult); }
 2. I don't think avoiding spec changes is necessarily a good 
 thing - D is already fairly murky in that regard so (wrt 
 previous point) specifying exactly what typefunctions can do is 
 probably a good thing.
The are just regular CTFE-only functions they can do anything a pure function can do.
 3. I think a similar thing wouldn't be all that bad for the AST 
 - read-only I should say (the only that worries me in the 
 abstract about that is that dmd's AST isn't very consistent in 
 its API) - i.e. Being able to access it as a regular (say) 
 class at CTFE rather than adding more and more and more 
 __traits.
See the sketch of a possible API above. And feel free to suggest your own!
Jan 01
parent reply Jacob Carlborg <doob me.com> writes:
On 2021-01-02 01:05, Stefan Koch wrote:

 Also I am not sure how I want the api to look like.
 
 Perhaps like this?
 struct StructField
 {
      __type__ type;
      string name
 }
 __type__ makeStruct (string name, StructField[] fields)
 {
      __struct__ sresult = __interal__magic__makeStruct(name);
      foreach(f;fields) { sresult.addField(f.name, f.type); }
      return __internal__magic__registerType(sresult);
 }
I'm not sure if it needs to have an API. Just look at how Zig does it. __type__ LinkedList(__type__ ElementType) { return struct { static struct Node { ElementType element; Node* next; Node* prev; } Node* first; Node* last; } } LinkedList(int) list; If you want to pass in the field names, I guess you'll have to resort to string mixins. Sure, there could be better alternatives than string mixins, but I think that's a separate issue.
 See the sketch of a possible API above.
 
 And feel free to suggest your own!
Here I've experimented in exposing the compiler AST [1]. [1] https://github.com/jacob-carlborg/druntime/blob/517dafcf54ad73049fb35d1ed5fa2ad6619b9ac4/src/core/ast/expression.d -- /Jacob Carlborg
Jan 02
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Saturday, 2 January 2021 at 08:47:07 UTC, Jacob Carlborg wrote:
 On 2021-01-02 01:05, Stefan Koch wrote:

 Also I am not sure how I want the api to look like.
 
 Perhaps like this?
 struct StructField
 {
      __type__ type;
      string name
 }
 __type__ makeStruct (string name, StructField[] fields)
 {
      __struct__ sresult = __interal__magic__makeStruct(name);
      foreach(f;fields) { sresult.addField(f.name, f.type); }
      return __internal__magic__registerType(sresult);
 }
I'm not sure if it needs to have an API. Just look at how Zig does it. __type__ LinkedList(__type__ ElementType) { return struct { static struct Node { ElementType element; Node* next; Node* prev; } Node* first; Node* last; } } LinkedList(int) list;
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... perhaps it's still worthwhile though? it's certainly better than a string mixin.
 If you want to pass in the field names, I guess you'll have to 
 resort to string mixins. Sure, there could be better 
 alternatives than string mixins, but I think that's a separate 
 issue.

 See the sketch of a possible API above.
 
 And feel free to suggest your own!
Here I've experimented in exposing the compiler AST [1]. [1] https://github.com/jacob-carlborg/druntime/blob/517dafcf54ad73049fb35d1ed5fa2ad6619b9ac4/src/core/ast/expression.d
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();
Jan 02
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Jan 06
parent reply sighoya <sighoya gmail.com> writes:
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.
Jan 06
parent reply Jacob Carlborg <doob me.com> writes:
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
Jan 06
parent Jacob Carlborg <doob me.com> writes:
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
Jan 06
prev sibling parent reply sighoya <sighoya gmail.com> writes:
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.
Jan 06
parent reply Q. Schroll <qs.il.paperinik gmail.com> writes:
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?
Jan 12
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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.
Jan 13
parent reply Max Haughton <maxhaton gmail.com> writes:
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?
Jan 13
parent Stefan Koch <uplink.coder googlemail.com> writes:
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.
Jan 14
prev sibling parent sighoya <sighoya gmail.com> writes:
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.
Jan 13
prev sibling parent reply Max Haughton <maxhaton gmail.com> writes:
On Saturday, 2 January 2021 at 08:47:07 UTC, Jacob Carlborg wrote:
 On 2021-01-02 01:05, Stefan Koch wrote:

 [...]
I'm not sure if it needs to have an API. Just look at how Zig does it. __type__ LinkedList(__type__ ElementType) { return struct { static struct Node { ElementType element; Node* next; Node* prev; } Node* first; Node* last; } } LinkedList(int) list; If you want to pass in the field names, I guess you'll have to resort to string mixins. Sure, there could be better alternatives than string mixins, but I think that's a separate issue.
 [...]
Here I've experimented in exposing the compiler AST [1]. [1] https://github.com/jacob-carlborg/druntime/blob/517dafcf54ad73049fb35d1ed5fa2ad6619b9ac4/src/core/ast/expression.d
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
Jan 02
parent Jacob Carlborg <doob me.com> writes:
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
Jan 06
prev sibling next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 1 January 2021 at 23:52:58 UTC, Max Haughton wrote:
 [...] specifying exactly what typefunctions can do is probably 
 a good thing.
Let a type tainted value be: - a value of type __type__ or - a value of an aggregate which contains a type value as a field (this is transitive) or - a value which is an associative array that contains a type value. examples are: __type__ x; // x is a type tainted value __type__[string] y; // y is a type tainted value struct S { __type__ x; } S s; // s is a type tainted value s[string] y2; // y2 is a type tainted value class C { typeof(y2) f; } C c = new C(); // c is a type tainted value A typefunction is specified as "a function which either returns a type tainted value, or takes takes at least one type tainted value as argument" A typefunction may only be evaluated at compile time. A typefunction may not generate any code in object files. Other than the 2 typefunction specific rules above it's a regular function. I believe what you want specified are the operations which can be performed on type values. A type value may be created by from types by means of implicit conversion (whenever a type value is expected; such as when calling a type function, or when performing a comparison via is), or a cast to __type__. examples: void f(__type__ x); f(int); // int is implicitly converted to __type__ meaning a the type expression `int` is rewritten to the type value expression `cast(__type__)int`; __type__[__type__] arr; arr = [int:uint, myClass:yourClass]; // here the conversion is inserted as follows arr = [cast(__type__)int:cast(__type__)uint, cast(__type__)myClass:cast(__type__)yourClass]; or explicit auto x = cast(__type__)double;// although that's not needed since the type type is inferred here. meaning: auto x = int; static assert (is(typeof(x) == __type__); // passes A type value exposes all the properties of a type. such as `.sizeof`, `.min`, `.max` and so on. currently the exceptions here are .mangleof and stringof, since they can be referring to the variable itself. examples: __type__ t = int; assert(t.sizeof == 4); // yep t = double; assert(t.sizeof == 8); // works too t = ushort; assert(t.max == ushort.max && t.min == ushort.min); // that's fine assert(t.stringof == ushort.stringof) // fails: t.stringof is "t" Furthermore a type value may be used in an is expression and in __traits which can take a type; where it behaves as if the it were type which it currently represents. struct V3_64 { double x; double y; double z; } t = V3_64; assert(__traits(allMembers, t) == ["x", "y", "z"]); //passes assert(is(t == V3_64)); // passes assert(!is(t == double)); // passes assert(__traits(identifier, t) == "V3_64"); // passes // note: t.stringof is still "t" The initialization value __type__.init is defined as the primitive type __emptyType also known as the empty Type. the emptyType exposes default values for it's properties. sizeof = 0, min = 0, max = 0, __traits(identifier, __type__.init) = __emptyType, __traits(allMemebers, __type__.init) = [] the other specialty about the empty type is that the is expression does not consider it to be a type. which means it can be detected via: is(typeof(t) == __type__) && !is(t); And I that's all there is.
Jan 01
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2021-01-02 00:52, Max Haughton wrote:

 Being  able to access it as a regular (say) class at CTFE rather than adding 
 more and more and more __traits.
That would be nice and not that difficult to do. -- /Jacob Carlborg
Jan 02
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2021-01-02 00:26, Stefan Koch wrote:

 Specification wise type functions require two statements to be added.
 
 "Under certain conditions a type may be implicitly converted to a value 
 of type __type__."
 and
 "Under certain conditions a value of type __type__ may be converted to a 
 type."
"certain conditions" is not suitable for a specification. You need to specify all conditions, all details.
 That's it.
You need to specify what __type__ is as well. A keyword? A special symbol like __FILE__? -- /Jacob Carlborg
Jan 02
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Saturday, 2 January 2021 at 08:31:26 UTC, Jacob Carlborg wrote:
 On 2021-01-02 00:26, Stefan Koch wrote:

 Specification wise type functions require two statements to be 
 added.
 
 "Under certain conditions a type may be implicitly converted 
 to a value of type __type__."
 and
 "Under certain conditions a value of type __type__ may be 
 converted to a type."
"certain conditions" is not suitable for a specification. You need to specify all conditions, all details.
 That's it.
You need to specify what __type__ is as well. A keyword? A special symbol like __FILE__?
Condition for type -> type value : you need to use a type in a place where a type value is needed. Conditions for type value -> type : - you need to use a type value in place where a type is needed AND - the type value needs to be a constant expression. correct __type__ is a basic type just like int, and therefore a keyword. the reason for the four underscores it that __type is already used in the glibc binding.
Jan 02
parent reply sighoya <sighoya gmail.com> writes:
On Saturday, 2 January 2021 at 09:13:42 UTC, Stefan Koch wrote:
 Condition for type -> type value :
   you need to use a type in a place where a type value is 
 needed.

 Conditions for type value -> type :
   - you need to use a type value in place where a type is 
 needed AND
   - the type value needs to be a constant expression.

 correct __type__ is a basic type just like int, and therefore a 
 keyword.
 the reason for the four underscores it that __type is already 
 used in the glibc binding.
At first, thanks for working on first class types. Second, why we need at all __type__ and can't just reuse TypeInfo? TypeInfo already gives us the opportunity to compare types for equality and some other ops. We have `typeid(SecondClassType)` turning a second class type into a first class type, i.e. a value we can do operations on it. We just need the counterpart `asType(FirstClassType)` turning a TypeInfo into an second class type back, this must be done at compile time. And we need to support to call typeid at compile time. Maybe I'm wrong, just want to hear your opinion about it. I appreciate the use of first class types as they allow replacing the ugly nuts of alias seqs and recursion. I think executing a normal function mapping types to types could be faster than macro expansion, though I don't know that exactly.
Jan 02
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Saturday, 2 January 2021 at 14:34:39 UTC, sighoya wrote:
 On Saturday, 2 January 2021 at 09:13:42 UTC, Stefan Koch wrote:
 Condition for type -> type value :
   you need to use a type in a place where a type value is 
 needed.

 Conditions for type value -> type :
   - you need to use a type value in place where a type is 
 needed AND
   - the type value needs to be a constant expression.

 correct __type__ is a basic type just like int, and therefore 
 a keyword.
 the reason for the four underscores it that __type is already 
 used in the glibc binding.
At first, thanks for working on first class types. Second, why we need at all __type__ and can't just reuse TypeInfo? TypeInfo already gives us the opportunity to compare types for equality and some other ops. We have `typeid(SecondClassType)` turning a second class type into a first class type, i.e. a value we can do operations on it. We just need the counterpart `asType(FirstClassType)` turning a TypeInfo into an second class type back, this must be done at compile time. And we need to support to call typeid at compile time. Maybe I'm wrong, just want to hear your opinion about it. I appreciate the use of first class types as they allow replacing the ugly nuts of alias seqs and recursion. I think executing a normal function mapping types to types could be faster than macro expansion, though I don't know that exactly.
The reason I use the new primitive type __type__ is because typeid is meant for RTTI, and it's runtime dependent. Whereas __type__ is a proper langauge builtin. And therefore it can use builtin properties. I would not be able to expose .sizeof as the .sizeof property for example if I used some typeinfo class. In short the look & feel would suffer. By using a less integrated design.
Jan 02
parent reply sighoya <sighoya gmail.com> writes:
On Saturday, 2 January 2021 at 16:29:17 UTC, Stefan Koch wrote:

 The reason I use the new primitive type __type__ is because 
 typeid is meant for RTTI, and it's runtime dependent.
Yes, but I think not for types.
 Whereas __type__ is a proper langauge builtin.
 And therefore it can use builtin properties.
 I would not be able to expose .sizeof as the .sizeof property 
 for example if I used some typeinfo class.
I don't understand this, could we define properties on any type? Or are built-in properties only allowed for built-in types. Note, we have tsized and talign properties for a TypeInfo structure. See: https://dlang.org/library/object/type_info.html
 In short the look & feel would suffer.
Hmm, what about extending TypeInfo to have sizeof and the other properties referring to tsize and talign?
 By using a less integrated design.
My thought is to reuse existing structures.
Jan 02
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Saturday, 2 January 2021 at 17:28:20 UTC, sighoya wrote:
 My thought is to reuse existing structures.
So now in templates you write sizeof and in typefunctions you write tsize? In a template you write alingof and in a typefunction you have to write talign? That's needlessly increasing surface knowledge one needs to have. Yes I can see the appeal but in this case I think it's a misplaced urge to reuse existing structure. 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.
Jan 02
parent reply sighoya <sighoya gmail.com> writes:
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.
Jan 02
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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.
Jan 02
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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)?
Jan 03
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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.
Jan 03
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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?
Jan 03
prev sibling parent reply sighoya <sighoya gmail.com> writes:
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?
Jan 03
parent Stefan Koch <uplink.coder googlemail.com> writes:
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.
Jan 03
prev sibling next sibling parent reply claptrap <clap trap.com> writes:
On Friday, 1 January 2021 at 23:26:58 UTC, Stefan Koch wrote:
 Good Evening and Happy new year to everyone.

 After a stressful move to the UK in uncertain times, I am now 
 free and able to enjoy the last day of my holiday.
Welcome to the UK. Some small advice for the newcomer ;) If someone says "how are you" or "alright", it's a greeting, they dont actually want to know if you are alright. They would be happy with a concise "Im OK", or "Not bad" in response but they dont generally want more than one sentence. An awkward silence after the initial greeting is perfectly acceptable. Almost everything is "Not bad" in the UK, it's not good enough to be excited about anything, but not bad enough to be miserable. The range of life events that fit within the definition of "Not bad" is quite large, family members dying, losing a leg, wining the lottery etc.. are all "Not bad". The weather. Be sure to have an opinion about the weather, it is the most important thing to talk about. Even if you have just seen the person 10 minutes earlier the weather changes so often that you can mention it again. Recently it has become fashionable to say something about the lack of snow in the winter compared with when you were a child, or that it's like summer all year round because of global warming. (British summers are mostly indistinguishable from a mild winter) If in doubt assume British people are being mildly sarcastic whenever they speak. "Spotted dick" is a pudding made with suet and dried fruit.
Jan 02
next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Saturday, 2 January 2021 at 11:59:39 UTC, claptrap wrote:
 On Friday, 1 January 2021 at 23:26:58 UTC, Stefan Koch wrote:
 [...]
Welcome to the UK. Some small advice for the newcomer ;) If someone says "how are you" or "alright", it's a greeting, they dont actually want to know if you are alright. They would be happy with a concise "Im OK", or "Not bad" in response but they dont generally want more than one sentence. [...]
Hmm that wasn't exactly the response I was expecting. But thanks for the advise anyways! Luckily my social contacts are minimal :)
Jan 02
prev sibling parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Saturday, 2 January 2021 at 11:59:39 UTC, claptrap wrote:
...
 "Spotted dick" is a pudding made with suet and dried fruit.
Haha
Jan 08
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 1 January 2021 at 23:26:58 UTC, Stefan Koch wrote:
 [snip]
 I do hope you get as excited as me when reading this.

 Regards,
 Stefan
Looks interesting.
Jan 02