+
Skip to content

Overly general type signatures that violate contextual constraints do not raise errors #20

@arendsee

Description

@arendsee

In the flu case study of commit d6c2aba, in the function definition:

plotCladeTree :: FluConfig -> RootedTree Str e (a, Clade) -> ()
plotCladeTree config = plotTree config@treefile . mapLeaf setLeafName 

where plotTree, mapLeaf, and setLeafName have the following signatures:

plotTree :: Filename -> RootedTree n Real Str -> ()
setLeafName :: (JsonObj, Sequence) -> Str
mapLeaf :: (l -> l') -> RootedTree n e l -> RootedTree n e l'

In the top-level signature definition for plotCladeTree, there are two generic types, e and a. However, these types will be inferred to be Real and (JsonObj, Sequence), respectively.

This code does not raise an error, but it probably should. e and a are not really free here, they are constrained to specific types. In Haskell, this code would raise "rigid type value" errors. That is, the general type requested for each variable violates contextual constraints placed on the variables.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions

    点击 这是indexloc提供的php浏览器服务,不要输入任何密码和下载