- More heterogeneous list ops
- Resource ops that don't use "dtype" as the type parameter
For the latter, we may need an upstream fix, or else to change the convention
of how we can tell what the type parameter is.
We should treat such attributes as regular `DataType` values rather than type
parameters; otherwise we'll get ambiguous types. As with other attributes,
they can either set by default or passed in as an explicit argument to the op.
Allows us to reenable a couple more ops.
Also removes all the ghc-8-specific logic in the .cabal files.
ghc-8 has issues with deeply nested tuples of constraints. We can
work around it by:
- Changing TensorTypes to a regular class. This required FlexibleContexts.
(But we'll probably need it anyway when we support heterogeneous tensor
lists.)
- Specializing NoneOf for long type lists.
For more details, see: https://ghc.haskell.org/trac/ghc/ticket/12175.
Also added 'directory' to tensorflow-core-ops' dependencies since it's used
in the Setup script.
One more step towards fixing #38.
Two issues:
- The definition of `\\` was missing parentheses. It was probably a bug
that this used to worked in ghc-7.10.
- Set `-fconstraint-solver-iterations=0` to work around
https://ghc.haskell.org/trac/ghc/ticket/12175. It looks like we can
trigger that bug when defining a significantly complicated op. Specifically,
our type shenanigans ("OneOf") along with lens setters (for OpDef) seem
to confuse GHC.
Still TODO: automate testing of different ghc versions to prevent a regression.
* No longer need to hide ResourceHandle ops
* Blacklisted not supported TensorArrayV2
* Ownership of feed tensors changed (1f0c5119a0230c5160d45496175b9256f097e144)
