4 ms·

Its not like its impossible to model metaprogramming with types. TypeScript recently brought a new level of expressiveness and power into the mainstream with ma

by spion 10y ago

Its not like its impossible to model metaprogramming with types. TypeScript recently brought a new level of expressiveness and power into the mainstream with mapped types. Example: https://goo.gl/LphqrJ https://goo.gl/LphqrJ Its possible to map over record fields of different types to transform the inner type of a field. Similarly, if I understood it correctly, for your example that would mean you could map an object where every field is of a different but related type Domain<T[Key]> into an object of the same shape containing WsllexFunc<T[Key]> or Decoder<T[Key]>. Furthermore, you don't have to use Domain<T[Key]> - you can define a more restricted interface that only requires wsllex and decode. Then the extra functionality defined in the Domain<T[Key]> is no longer required, nor mentioned. Similarly the types WsllexFunc<X> and Decoder<X> are simple function types, and any function types with the same shape (arguments and return type) would be accepted regardless of their name. Recursively the arguments and return type are themselves structural, and so on (!) IMO its incredible how structural type systems change the game completely and we've yet to realise the full implications of this for dynamic languages. My guess is that this is why Guido is excited about types.

jstimpfle 10y ago
Thank you for taking the time (and referring to the point I made instead of criticizing the code, which is experimental and a little crappy in places). Looks interesting and I will keep an eye on it. But am I right guessing that the TypeScript you linked would not work if the schema is only read at runtime?
- spion 10y ago
  Yeah, unfortunately. For something like that, code generation of at least the initial record types would be required for different schemas at before-compile-time. Then they can be transformed further by the type level language. Another option is to model the type as a dictionary of items, each item being a union of the possible types. There is a tradeoff here, and I believe that if the rest of the code statically assumes a concrete schema is in place, code generation + record types is the better choice. Otherwise, dictionaries would probably work okay. There are languages such as Idris and F# that have type providers which can be programmed to read and generate the types from the database, but AFAIK that would still happen at compile-time. https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tutorials/type-providers/accessing-a-sql-database https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tuto... - i guess its a kind of "built in" code generation.

by spion 10y ago

jstimpfle 10y ago

Thank you for taking the time (and referring to the point I made instead of criticizing the code, which is experimental and a little crappy in places). Looks interesting and I will keep an eye on it. But am I right guessing that the TypeScript you linked would not work if the schema is only read at runtime?

spion 10y ago
Yeah, unfortunately. For something like that, code generation of at least the initial record types would be required for different schemas at before-compile-time. Then they can be transformed further by the type level language. Another option is to model the type as a dictionary of items, each item being a union of the possible types. There is a tradeoff here, and I believe that if the rest of the code statically assumes a concrete schema is in place, code generation + record types is the better choice. Otherwise, dictionaries would probably work okay. There are languages such as Idris and F# that have type providers which can be programmed to read and generate the types from the database, but AFAIK that would still happen at compile-time. https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tutorials/type-providers/accessing-a-sql-database https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tuto... - i guess its a kind of "built in" code generation.