Fixes

[goodmind]

• Replace never with empty
• Use type imports

[goodmind]

I think you don't need this $ElementType things because you have $Call ? (Also you could use real boolean)

[goodmind]

https://github.com/types/npm-ramda/issues/269#issuecomment-364754563

[KiaraGrouwstra]

@goodmind: Thanks! Agreed, $ElementType is ugly and real booleans would be nice.

Seems TS has gotten better support for conditionals as well (T extends number ? A : B). Over there I'd wanted to switch to function-based pattern matching before ($Call on an interface of multiple functions). Wonder if that'd be viable in Flow.

So far I was converting blind -- I was able to see compiler errors (notably that in), but when I separately compiled this test.ts file with some evident type issues, Flow seemed cool with it too, so I'm still sorta confused.

Also I think you can't just convert directly all this things

Yeah, sounds fair. So far I was really just seeing how far I could take this in a straight-forward conversion. I'm pretty sure you're right though.

• maybe $ObjMapi?

Hmm. So $ObjMapi seems for when you already have a your object. My remaining in use case were generally about cases where I'd have a key / union of keys in a generic and wanna use that to make an object. In TS in / Record help with that, but in Flow I haven't seen this yet I think.

• equivalent to TS's .d.ts is .js.flow
• there's indeed no TS Compiler API, babel can manipulate nodes but no typecheck (would be cool if Flow had OCaml compiler plugins)
• I think you can use what https://github.com/facebook/flow using for tests (either tests or newtests)

Thanks! Gonna have to check that out.

[goodmind]

I think you can't iterate unions in flow (but you have tuples)

[goodmind]

Lol you can actually do something like this, but I'm not sure about it https://flow.org/try/#0MYewdgzgLgBA5gUygaQQTxgXhgCgGYCUWAfDADwAKAXDAFTE4AONFRmpA3gFAwwBOSAK58wMbr14BtRgF0aeHAR4wAvlzVcoaRghio0ELDEkByAIYmANDBMAjKzeAmZm7boAkAFRAB5WwCsEYCgyZGsAMVJsZXcAUQAPM2CyOIAbBABbBDAoTzcyZQBIL0FGdIBZM0ZQ63cAYTNU1LItHRA8eCR9COJiS2VeMEEM2wQ+ZV6BiS4AEyDUswEYADdFmDMaL18AoJD9CGtFEhghkbHiKa4AeiuYOPjgBEYoWL4+EHGcDbFv09G+ay2Gh-MbWYA0aB8ACWYDgKgIQA

[KiaraGrouwstra]

Yeah, unions vs tuples huh. Not bad, thanks!

[goodmind]

@tycho01 any progress?

[KiaraGrouwstra]

not yet! I've gotten a bit distracted by the new TS features, which have narrowed the gap a bit. TS is still low on FP features though, so I still wanna try more on Flow.

[SimonMeskens]

I've been out of the loop for a bit, what are the new features that close the gap? Is there a way to read up on the progress you guys made? I read the TS changelogs obviously

[goodmind]

@SimonMeskens it's version of typical for Flow

[KiaraGrouwstra]

@SimonMeskens notably conditional types, essentially type-level type checks not unlike pattern matching.

My progress: I forked the testing lib so I could determine the TS version from here, tried to improve typings a bit based on the new TS, added docs... then tried to look into actually using this thing, and actually running tsc.

I made a bit of progress there, but for now I fear this lib is still for reading PoCs rather than for consumption.

Fortunately a few other type libs more aimed at consumption rather than PoCs (typelevel-ts, type-zoo) have been helping fill the void.

At least I managed to not have non-terminating types prevent any attempt at compilation.

I've committed the tsc log to track progress on compiler errors, in addition to the existing log detailing behavioral progress.

[KiaraGrouwstra]

hm. I hadn't tried much, but is there a way to see the inferred type in Flow? bad types give errors (yay), but it seemed good types just go through without further feedback. :/

[goodmind]

@tycho01 flow type-at-pos?