Type variables in a simple component
up vote
2
down vote
favorite
Say I have this simple component
type evt =
| NoOp;
type t('a) = 'a;
let component = ReasonReact.reducerComponent("TestComponent");
let make = _children => {
...component,
initialState: () => "hello",
reducer: (evt, state: t('a)) =>
switch (evt) {
| NoOp => ReasonReact.NoUpdate
},
render: self => <div> {str("hello")} </div>,
};
(try it here)
Why am I getting
The type of this module contains type variables that cannot be generalized
? (The type variable is useless here, but imagine it was needed in initialState. Tried to keep the sample as simple as possible.)
compiler-errors polymorphism ocaml reason reason-react
add a comment |
up vote
2
down vote
favorite
Say I have this simple component
type evt =
| NoOp;
type t('a) = 'a;
let component = ReasonReact.reducerComponent("TestComponent");
let make = _children => {
...component,
initialState: () => "hello",
reducer: (evt, state: t('a)) =>
switch (evt) {
| NoOp => ReasonReact.NoUpdate
},
render: self => <div> {str("hello")} </div>,
};
(try it here)
Why am I getting
The type of this module contains type variables that cannot be generalized
? (The type variable is useless here, but imagine it was needed in initialState. Tried to keep the sample as simple as possible.)
compiler-errors polymorphism ocaml reason reason-react
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
Say I have this simple component
type evt =
| NoOp;
type t('a) = 'a;
let component = ReasonReact.reducerComponent("TestComponent");
let make = _children => {
...component,
initialState: () => "hello",
reducer: (evt, state: t('a)) =>
switch (evt) {
| NoOp => ReasonReact.NoUpdate
},
render: self => <div> {str("hello")} </div>,
};
(try it here)
Why am I getting
The type of this module contains type variables that cannot be generalized
? (The type variable is useless here, but imagine it was needed in initialState. Tried to keep the sample as simple as possible.)
compiler-errors polymorphism ocaml reason reason-react
Say I have this simple component
type evt =
| NoOp;
type t('a) = 'a;
let component = ReasonReact.reducerComponent("TestComponent");
let make = _children => {
...component,
initialState: () => "hello",
reducer: (evt, state: t('a)) =>
switch (evt) {
| NoOp => ReasonReact.NoUpdate
},
render: self => <div> {str("hello")} </div>,
};
(try it here)
Why am I getting
The type of this module contains type variables that cannot be generalized
? (The type variable is useless here, but imagine it was needed in initialState. Tried to keep the sample as simple as possible.)
compiler-errors polymorphism ocaml reason reason-react
compiler-errors polymorphism ocaml reason reason-react
edited Nov 9 at 10:51
glennsl
8,918102645
8,918102645
asked Nov 9 at 7:51
swelet
3,16231930
3,16231930
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
The technical reason is that a ReasonReact component is record type which would look something like this:
type fauxComponent = {
reducer: (evt, t('a)) => t('a),
render: t('a) => ReasonReact.reactElement
};
If you try to compile this you'll get an error about an "Unbound type parameter". The difference in error is because it is inferred to be of type ReasonReact.component
which has a bunch of type variables, one of which is inferred to have a polymorphic type. The problem is essentially the same, but much easier to illustrate without all the indirection.
Th technical reason why you can't do this I think is called the value restriction. But there are practical reasons as well. You actually can make this type compile if you explicitly specify 'a
as being polymorphic:
type fauxComponent = {
reducer: 'a. (evt, t('a)) => t('a),
render: 'a. t('a) => ReasonReact.reactElement
};
This says that 'a
can be anything, but that's also the problem. Since it can be anything, you can't know what it is, and you therefore can't really do anything with it other than to have it pass through and returned. You also don't know that 'a
is the same in reducer
and render
, which isn't usually a problem with records since they're not stateful objects. The problem arises because ReasonReact "abuses" them as if they were.
So how would you then accomplish what you're trying to do? Easy, use a functor! ;) In Reason you can parameterize modules, which are then called functors, and use that to specify the type to use across the entire module. Here's your example functorized:
module type Config = {
type t;
let initialState : t;
};
module FunctorComponent(T : Config) {
type evt =
| NoOp;
type t = T.t;
let component = ReasonReact.reducerComponent("TestComponent");
let make = _children => {
...component,
initialState: () => T.initialState,
reducer: (evt, state: t) =>
switch (evt) {
| NoOp => ReasonReact.NoUpdate
},
render: self => <div> {ReasonReact.string("hello")} </div>,
};
};
module MyComponent = FunctorComponent({
type t = string;
let initialState = "hello";
});
ReactDOMRe.renderToElementWithId(<MyComponent />, "preview");
The parameters a functor takes actually need to be modules, so we first define a module type Config
, specify that as the parameter type, and then when we create our MyComponent
module using the functor we create and pass it an anonymous module that implement the Config
module type.
Now you know why a lot of people think OCaml and Reason's module system is so awesome :) (There's actually a lot more to it, but this is a good start)
Whoa! You just blew my mind. Can't try it until tonight, but the upvote is yours.
– swelet
Nov 9 at 11:50
Thanks once again. Been dabbling with Reason and functional programming in general for a while now but I never had a practical use case for functors until now (atleast not that I know of), so I never got to learning them. Great answer!
– swelet
Nov 9 at 22:19
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
The technical reason is that a ReasonReact component is record type which would look something like this:
type fauxComponent = {
reducer: (evt, t('a)) => t('a),
render: t('a) => ReasonReact.reactElement
};
If you try to compile this you'll get an error about an "Unbound type parameter". The difference in error is because it is inferred to be of type ReasonReact.component
which has a bunch of type variables, one of which is inferred to have a polymorphic type. The problem is essentially the same, but much easier to illustrate without all the indirection.
Th technical reason why you can't do this I think is called the value restriction. But there are practical reasons as well. You actually can make this type compile if you explicitly specify 'a
as being polymorphic:
type fauxComponent = {
reducer: 'a. (evt, t('a)) => t('a),
render: 'a. t('a) => ReasonReact.reactElement
};
This says that 'a
can be anything, but that's also the problem. Since it can be anything, you can't know what it is, and you therefore can't really do anything with it other than to have it pass through and returned. You also don't know that 'a
is the same in reducer
and render
, which isn't usually a problem with records since they're not stateful objects. The problem arises because ReasonReact "abuses" them as if they were.
So how would you then accomplish what you're trying to do? Easy, use a functor! ;) In Reason you can parameterize modules, which are then called functors, and use that to specify the type to use across the entire module. Here's your example functorized:
module type Config = {
type t;
let initialState : t;
};
module FunctorComponent(T : Config) {
type evt =
| NoOp;
type t = T.t;
let component = ReasonReact.reducerComponent("TestComponent");
let make = _children => {
...component,
initialState: () => T.initialState,
reducer: (evt, state: t) =>
switch (evt) {
| NoOp => ReasonReact.NoUpdate
},
render: self => <div> {ReasonReact.string("hello")} </div>,
};
};
module MyComponent = FunctorComponent({
type t = string;
let initialState = "hello";
});
ReactDOMRe.renderToElementWithId(<MyComponent />, "preview");
The parameters a functor takes actually need to be modules, so we first define a module type Config
, specify that as the parameter type, and then when we create our MyComponent
module using the functor we create and pass it an anonymous module that implement the Config
module type.
Now you know why a lot of people think OCaml and Reason's module system is so awesome :) (There's actually a lot more to it, but this is a good start)
Whoa! You just blew my mind. Can't try it until tonight, but the upvote is yours.
– swelet
Nov 9 at 11:50
Thanks once again. Been dabbling with Reason and functional programming in general for a while now but I never had a practical use case for functors until now (atleast not that I know of), so I never got to learning them. Great answer!
– swelet
Nov 9 at 22:19
add a comment |
up vote
2
down vote
accepted
The technical reason is that a ReasonReact component is record type which would look something like this:
type fauxComponent = {
reducer: (evt, t('a)) => t('a),
render: t('a) => ReasonReact.reactElement
};
If you try to compile this you'll get an error about an "Unbound type parameter". The difference in error is because it is inferred to be of type ReasonReact.component
which has a bunch of type variables, one of which is inferred to have a polymorphic type. The problem is essentially the same, but much easier to illustrate without all the indirection.
Th technical reason why you can't do this I think is called the value restriction. But there are practical reasons as well. You actually can make this type compile if you explicitly specify 'a
as being polymorphic:
type fauxComponent = {
reducer: 'a. (evt, t('a)) => t('a),
render: 'a. t('a) => ReasonReact.reactElement
};
This says that 'a
can be anything, but that's also the problem. Since it can be anything, you can't know what it is, and you therefore can't really do anything with it other than to have it pass through and returned. You also don't know that 'a
is the same in reducer
and render
, which isn't usually a problem with records since they're not stateful objects. The problem arises because ReasonReact "abuses" them as if they were.
So how would you then accomplish what you're trying to do? Easy, use a functor! ;) In Reason you can parameterize modules, which are then called functors, and use that to specify the type to use across the entire module. Here's your example functorized:
module type Config = {
type t;
let initialState : t;
};
module FunctorComponent(T : Config) {
type evt =
| NoOp;
type t = T.t;
let component = ReasonReact.reducerComponent("TestComponent");
let make = _children => {
...component,
initialState: () => T.initialState,
reducer: (evt, state: t) =>
switch (evt) {
| NoOp => ReasonReact.NoUpdate
},
render: self => <div> {ReasonReact.string("hello")} </div>,
};
};
module MyComponent = FunctorComponent({
type t = string;
let initialState = "hello";
});
ReactDOMRe.renderToElementWithId(<MyComponent />, "preview");
The parameters a functor takes actually need to be modules, so we first define a module type Config
, specify that as the parameter type, and then when we create our MyComponent
module using the functor we create and pass it an anonymous module that implement the Config
module type.
Now you know why a lot of people think OCaml and Reason's module system is so awesome :) (There's actually a lot more to it, but this is a good start)
Whoa! You just blew my mind. Can't try it until tonight, but the upvote is yours.
– swelet
Nov 9 at 11:50
Thanks once again. Been dabbling with Reason and functional programming in general for a while now but I never had a practical use case for functors until now (atleast not that I know of), so I never got to learning them. Great answer!
– swelet
Nov 9 at 22:19
add a comment |
up vote
2
down vote
accepted
up vote
2
down vote
accepted
The technical reason is that a ReasonReact component is record type which would look something like this:
type fauxComponent = {
reducer: (evt, t('a)) => t('a),
render: t('a) => ReasonReact.reactElement
};
If you try to compile this you'll get an error about an "Unbound type parameter". The difference in error is because it is inferred to be of type ReasonReact.component
which has a bunch of type variables, one of which is inferred to have a polymorphic type. The problem is essentially the same, but much easier to illustrate without all the indirection.
Th technical reason why you can't do this I think is called the value restriction. But there are practical reasons as well. You actually can make this type compile if you explicitly specify 'a
as being polymorphic:
type fauxComponent = {
reducer: 'a. (evt, t('a)) => t('a),
render: 'a. t('a) => ReasonReact.reactElement
};
This says that 'a
can be anything, but that's also the problem. Since it can be anything, you can't know what it is, and you therefore can't really do anything with it other than to have it pass through and returned. You also don't know that 'a
is the same in reducer
and render
, which isn't usually a problem with records since they're not stateful objects. The problem arises because ReasonReact "abuses" them as if they were.
So how would you then accomplish what you're trying to do? Easy, use a functor! ;) In Reason you can parameterize modules, which are then called functors, and use that to specify the type to use across the entire module. Here's your example functorized:
module type Config = {
type t;
let initialState : t;
};
module FunctorComponent(T : Config) {
type evt =
| NoOp;
type t = T.t;
let component = ReasonReact.reducerComponent("TestComponent");
let make = _children => {
...component,
initialState: () => T.initialState,
reducer: (evt, state: t) =>
switch (evt) {
| NoOp => ReasonReact.NoUpdate
},
render: self => <div> {ReasonReact.string("hello")} </div>,
};
};
module MyComponent = FunctorComponent({
type t = string;
let initialState = "hello";
});
ReactDOMRe.renderToElementWithId(<MyComponent />, "preview");
The parameters a functor takes actually need to be modules, so we first define a module type Config
, specify that as the parameter type, and then when we create our MyComponent
module using the functor we create and pass it an anonymous module that implement the Config
module type.
Now you know why a lot of people think OCaml and Reason's module system is so awesome :) (There's actually a lot more to it, but this is a good start)
The technical reason is that a ReasonReact component is record type which would look something like this:
type fauxComponent = {
reducer: (evt, t('a)) => t('a),
render: t('a) => ReasonReact.reactElement
};
If you try to compile this you'll get an error about an "Unbound type parameter". The difference in error is because it is inferred to be of type ReasonReact.component
which has a bunch of type variables, one of which is inferred to have a polymorphic type. The problem is essentially the same, but much easier to illustrate without all the indirection.
Th technical reason why you can't do this I think is called the value restriction. But there are practical reasons as well. You actually can make this type compile if you explicitly specify 'a
as being polymorphic:
type fauxComponent = {
reducer: 'a. (evt, t('a)) => t('a),
render: 'a. t('a) => ReasonReact.reactElement
};
This says that 'a
can be anything, but that's also the problem. Since it can be anything, you can't know what it is, and you therefore can't really do anything with it other than to have it pass through and returned. You also don't know that 'a
is the same in reducer
and render
, which isn't usually a problem with records since they're not stateful objects. The problem arises because ReasonReact "abuses" them as if they were.
So how would you then accomplish what you're trying to do? Easy, use a functor! ;) In Reason you can parameterize modules, which are then called functors, and use that to specify the type to use across the entire module. Here's your example functorized:
module type Config = {
type t;
let initialState : t;
};
module FunctorComponent(T : Config) {
type evt =
| NoOp;
type t = T.t;
let component = ReasonReact.reducerComponent("TestComponent");
let make = _children => {
...component,
initialState: () => T.initialState,
reducer: (evt, state: t) =>
switch (evt) {
| NoOp => ReasonReact.NoUpdate
},
render: self => <div> {ReasonReact.string("hello")} </div>,
};
};
module MyComponent = FunctorComponent({
type t = string;
let initialState = "hello";
});
ReactDOMRe.renderToElementWithId(<MyComponent />, "preview");
The parameters a functor takes actually need to be modules, so we first define a module type Config
, specify that as the parameter type, and then when we create our MyComponent
module using the functor we create and pass it an anonymous module that implement the Config
module type.
Now you know why a lot of people think OCaml and Reason's module system is so awesome :) (There's actually a lot more to it, but this is a good start)
answered Nov 9 at 10:50
glennsl
8,918102645
8,918102645
Whoa! You just blew my mind. Can't try it until tonight, but the upvote is yours.
– swelet
Nov 9 at 11:50
Thanks once again. Been dabbling with Reason and functional programming in general for a while now but I never had a practical use case for functors until now (atleast not that I know of), so I never got to learning them. Great answer!
– swelet
Nov 9 at 22:19
add a comment |
Whoa! You just blew my mind. Can't try it until tonight, but the upvote is yours.
– swelet
Nov 9 at 11:50
Thanks once again. Been dabbling with Reason and functional programming in general for a while now but I never had a practical use case for functors until now (atleast not that I know of), so I never got to learning them. Great answer!
– swelet
Nov 9 at 22:19
Whoa! You just blew my mind. Can't try it until tonight, but the upvote is yours.
– swelet
Nov 9 at 11:50
Whoa! You just blew my mind. Can't try it until tonight, but the upvote is yours.
– swelet
Nov 9 at 11:50
Thanks once again. Been dabbling with Reason and functional programming in general for a while now but I never had a practical use case for functors until now (atleast not that I know of), so I never got to learning them. Great answer!
– swelet
Nov 9 at 22:19
Thanks once again. Been dabbling with Reason and functional programming in general for a while now but I never had a practical use case for functors until now (atleast not that I know of), so I never got to learning them. Great answer!
– swelet
Nov 9 at 22:19
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53221716%2ftype-variables-in-a-simple-component%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown