Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support parametrized "Any" #111

Open
judah opened this issue Jul 31, 2017 · 0 comments
Open

Support parametrized "Any" #111

judah opened this issue Jul 31, 2017 · 0 comments

Comments

@judah
Copy link
Collaborator

judah commented Jul 31, 2017

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:

extend google.protobuf.MessageOptions {
    repeated string haskell_type_var = 50000;
}

extend google.protobuf.FieldOptions {
    optional string haskell_type_var = 50000;
}

Then we can use those options to annotate a type:

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.

blackgnezdo pushed a commit that referenced this issue Aug 17, 2018
- 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant