You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can use google.protobuf.Any to support basic parametric polymorphism. For example, if we define a file haskell_type_variables.proto with custom options:
import ".../haskell_type_variables.proto";
message Foo {
option (haskell_type_var) = "a";
option (haskell_type_var) = "b";
int32 x = 1;
google.protobuf.Any y = 2 [(haskell_type_var)="a"];
google.protobuf.Any z = 2 [(haskell_type_var)="b"];
}
And generate the following type from that file:
data Foo a b = Foo { _Foo'x :: Int32, _Foo'y :: Maybe a, _Foo'z :: Maybe b}
instance (Message a, Message b) => Message (Foo a b) where ...
encodeMessage/decodeMessage could serialize the submessage as an Any, but in Haskell code represent it as a regular (not serialized) Haskell type. This makes it easier to use proto types directly in Haskell (instead of via wrapper types).
Following the above option-based design will require us to support extensions (#27) so that proto-lens-protoc can understand the new options that we add.
The text was updated successfully, but these errors were encountered:
- Merge tensorflow-nn and tensorflow-queue into tensorflow-ops.
They don't add extra dependencies and each contain a single module, so I
don't think it's worth separating them at the package level.
- Remove google-shim in favor of direct use of test-framework.
We can use
google.protobuf.Any
to support basic parametric polymorphism. For example, if we define a filehaskell_type_variables.proto
with custom options:Then we can use those options to annotate a type:
And generate the following type from that file:
encodeMessage/decodeMessage
could serialize the submessage as anAny
, but in Haskell code represent it as a regular (not serialized) Haskell type. This makes it easier to use proto types directly in Haskell (instead of via wrapper types).Following the above option-based design will require us to support extensions (#27) so that proto-lens-protoc can understand the new options that we add.
The text was updated successfully, but these errors were encountered: