4 ms·

This is the case when someone didn't completed his homework. Most of things he requested are possible with HList in Haskell. A library, nonetheless. From 2008,

by thesz 7y ago

This is the case when someone didn't completed his homework. Most of things he requested are possible with HList in Haskell. A library, nonetheless. From 2008, I believe. PS Structural subtyping is tricky: https://pdfs.semanticscholar.org/ff6f/1c49ff00efa483807fae71ef2a0f2baf6a04.pdf https://pdfs.semanticscholar.org/ff6f/1c49ff00efa483807fae71... It took quarter of century to get it right. Most probably the author of gist just don't get it's trickyness yet.

gpderetta 7y ago
in fact, most of those things are possible in c++ of all places.
- ken 7y ago
  Can you explain how? Most of these look like essentially type-inference through duck-typing, and (AIUI) C++ doesn't even have duck-typing.
  - chombier 7y ago
    C++ templates are a kind of duck typing, aren't they?
  - jcelerier 7y ago
    C++ has had duck typing since it had generics. Here would be an example of the first case : https://wandbox.org/permlink/AIgZtkFgTuiQReDT https://wandbox.org/permlink/AIgZtkFgTuiQReDT
- thesz 7y ago
  I agree, and some of these possible things can be more efficiently implemented in C++.
skywhopper 7y ago
Can you provide examples to show how Haskell and HList would solve the problems the author proposes?
- thesz 7y ago
  Records are associative HLists: HList of pairs (fieldname, valuetype). Fieldnames are string singletons (in Haskell from 2012, at least), and do not have runtime representation and/or cost. Specifying that code has to have this argument with these fields is as simple as providing HList lookups in it. You also can zip and unzip these associative lists, getting completely erasable field names and concrete representation of record. I believe author somehow messed the part where his requirement considers machine representation. This is an implementation detail, BTW. Sometimes it is desirable to have as tight representation as possible, othertimes it is not. I believe that it is quite possible to have associated type for HList records in the vector package style for unboxed vectors - vector represents array of structures as structure of arrays and for HList we can do something alike. Again, you can have it if you want it.

by thesz 7y ago

gpderetta 7y ago

in fact, most of those things are possible in c++ of all places.

ken 7y ago
Can you explain how? Most of these look like essentially type-inference through duck-typing, and (AIUI) C++ doesn't even have duck-typing.
- chombier 7y ago
  C++ templates are a kind of duck typing, aren't they?
- jcelerier 7y ago
  C++ has had duck typing since it had generics. Here would be an example of the first case : https://wandbox.org/permlink/AIgZtkFgTuiQReDT https://wandbox.org/permlink/AIgZtkFgTuiQReDT
thesz 7y ago
I agree, and some of these possible things can be more efficiently implemented in C++.

skywhopper 7y ago

Can you provide examples to show how Haskell and HList would solve the problems the author proposes?

thesz 7y ago
Records are associative HLists: HList of pairs (fieldname, valuetype). Fieldnames are string singletons (in Haskell from 2012, at least), and do not have runtime representation and/or cost. Specifying that code has to have this argument with these fields is as simple as providing HList lookups in it. You also can zip and unzip these associative lists, getting completely erasable field names and concrete representation of record. I believe author somehow messed the part where his requirement considers machine representation. This is an implementation detail, BTW. Sometimes it is desirable to have as tight representation as possible, othertimes it is not. I believe that it is quite possible to have associated type for HList records in the vector package style for unboxed vectors - vector represents array of structures as structure of arrays and for HList we can do something alike. Again, you can have it if you want it.