class_docstr: NLTK's ``ApplicationExpression`` (which represents function applications like P(x)) has two
  limitations, which we overcome by inheriting from ``ApplicationExpression`` and overriding two
  methods.
  
  Firstly, ``ApplicationExpression`` does not handle the case where P's type involves
  placeholders (R, V, !=, etc.), which are special cases because their return types depend on the
  type of their arguments (x). We override the property ``type`` to redefine the type of the
  application.
  
  Secondly, NLTK's variables only bind to entities, and thus the variable types are 'e' by
  default. We get around this issue by replacing x with X, whose initial type is ANY_TYPE, and
  later gets resolved based on the type signature of the function whose scope the variable
  appears in. This variable binding operation is implemented by overriding ``_set_type`` below.
class_docstr_tok: ["NLTK","'s","``","ApplicationExpression","``","(","which","represents","function","applications","like","P","(","x",")",")","has","two","limitations",",","which","we","overcome","by","inheriting","from","``","ApplicationExpression","``","and","overriding","two","methods",".","Firstly",",","``","ApplicationExpression","``","does","not","handle","the","case","where","P","'s","type","involves","placeholders","(","R",",","V",",","!","=",",","etc",".",")",",","which","are","special","cases","because","their","return","types","depend","on","the","type","of","their","arguments","(","x",")",".","We","override","the","property","``","type","``","to","redefine","the","type","of","the","application",".","Secondly",",","NLTK","'s","variables","only","bind","to","entities",",","and","thus","the","variable","types","are","'","e","'","by","default",".","We","get","around","this","issue","by","replacing","x","with","X",",","whose","initial","type","is","ANY_TYPE",",","and","later","gets","resolved","based","on","the","type","signature","of","the","function","whose","scope","the","variable","appears","in",".","This","variable","binding","operation","is","implemented","by","overriding","``","_set_type","``","below","."]
docstr: We override this method to do just one thing on top of ``ApplicationExpression._set_type``.
  In lambda expressions of the form /x F(x), where the function is F and the argument is x,
  we can use the type of F to infer the type of x. That is, if F is of type <a, b>, we can
  resolve the type of x against a. We do this as the additional step after setting the type
  of F(x).
  
  So why does NLTK not already do this? NLTK assumes all variables (x) are of type entity
  (e).  So it does not have to resolve the type of x anymore. However, this would cause type
  inference failures in our case since x can bind to rows, numbers or cells, each of which
  has a different type. To deal with this issue, we made X of type ANY_TYPE. Also, LambdaDCS
  (and some other languages) contain a var function that indicate the usage of variables
  within lambda functions. We map var to V, and made it of type <#1, #1>. We cannot leave X
  as ANY_TYPE because that would propagate up the tree. We need to set its type when we have
  the information about F. Hence this method. Note that the language may or may not contain
  the var function. We deal with both cases below.
code: def _set_type(self, other_type=ANY_TYPE, signature=None):
      """
      We override this method to do just one thing on top of ``ApplicationExpression._set_type``.
      In lambda expressions of the form /x F(x), where the function is F and the argument is x,
      we can use the type of F to infer the type of x. That is, if F is of type <a, b>, we can
      resolve the type of x against a. We do this as the additional step after setting the type
      of F(x).
  
      So why does NLTK not already do this? NLTK assumes all variables (x) are of type entity
      (e).  So it does not have to resolve the type of x anymore. However, this would cause type
      inference failures in our case since x can bind to rows, numbers or cells, each of which
      has a different type. To deal with this issue, we made X of type ANY_TYPE. Also, LambdaDCS
      (and some other languages) contain a var function that indicate the usage of variables
      within lambda functions. We map var to V, and made it of type <#1, #1>. We cannot leave X
      as ANY_TYPE because that would propagate up the tree. We need to set its type when we have
      the information about F. Hence this method. Note that the language may or may not contain
      the var function. We deal with both cases below.
      """
      super(DynamicTypeApplicationExpression, self)._set_type(
          other_type, signature
      )
      # TODO(pradeep): Assuming the mapping of "var" function is "V". Do something better.
      if (
          isinstance(self.argument, ApplicationExpression)
          and unicode(self.argument.function) == "V"
      ):
          # pylint: disable=protected-access
          self.argument.argument._set_type(self.function.type.first)
      if (
          unicode(self.argument) == "X"
          and unicode(self.function) != "V"
      ):
          # pylint: disable=protected-access
          self.argument._set_type(self.function.type.first)
  
imports: from __future__ import absolute_import
  from collections import defaultdict
  from nltk.sem.logic import Expression, ApplicationExpression, ConstantExpression, LogicParser, Variable
  from nltk.sem.logic import Type, BasicType, ComplexType, ANY_TYPE
  from allennlp.common.util import START_SYMBOL
label_desc: Use image node_id 3 for calling the DynamicTypeApplicationExpression obj's underlying member method code with example usage: obj._set_type(other_type, signature) without return types