home *** CD-ROM | disk | FTP | other *** search
/ back2roots/padua / padua.7z / padua / lang / gofer223.lha / doc / appx_c < prev    next >
Encoding:
Text File  |  1992-11-10  |  9.0 KB  |  265 lines
  1.  
  2.  
  3. Introduction to Gofer         APPENDIX C: RELATIONSHIP WITH HASKELL 1.1         
  4.  
  5.  
  6. APPENDIX C: RELATIONSHIP WITH HASKELL 1.1
  7.  
  8. The language supported by Gofer is both syntactically and  semantically
  9. similar to that of  the  functional  programming  language  Haskell  as
  10. defined in the report  for  Haskell  version  1.1  [5].   This  section
  11. details the differences between the two languages, outlined briefly  in
  12. section 2.
  13.  
  14. Haskell features not included in Gofer:
  15. ---------------------------------------
  16.   o  Modules
  17.  
  18.   o  Arrays
  19.  
  20.   o  Derived instances for standard classes -- the ability to construct
  21.      instances of particular classes automatically.
  22.  
  23.   o  Default mechanism for eliminating unresolved overloading involving
  24.      numeric and standard classes.   Since  Gofer  is  an  experimental
  25.      system, it can be  used  with  a  range  of  completely  different
  26.      prelude files; there is no concept of `standard classes'.
  27.  
  28.   o  Overloaded numeric constants.  In  the  absence  of  a  defaulting
  29.      mechanism  as  mentioned  in  the  previous  item,  problems  with
  30.      unresolved overloading make implicitly typed programming involving
  31.      numeric constants impractical in an interpreter based system.
  32.  
  33.   o  Full range of numeric types  and  classes.   Gofer  has  only  two
  34.      primitive numeric types Int and Float (the second of which is  not
  35.      supported in the PC version).  Although is would  be  possible  to
  36.      modify the standard prelude so that  Gofer  uses  the  same  class
  37.      hierarchy as Haskell, this is unnecessarily sophisticated for  the
  38.      intended uses of Gofer.
  39.  
  40.   o  Datatype definitions in Haskell may involve class constraints such
  41.      as:
  42.  
  43.               data  Ord a => Set a = Set [a]
  44.  
  45.      It is  not  clear  how  such  constraints  should  be  interpreted
  46.      (particularly in the light of the  extended  form  of  constraints
  47.      used by Gofer) in such a way to  make  them  useful  whilst  avoid
  48.      unwanted ambiguity problems.
  49.  
  50.  
  51. Gofer features not supported in Haskell:
  52. ----------------------------------------
  53.   o  Type classes may have multiple parameters.
  54.  
  55.   o  Predicates  in  type  expressions  may  involve   arbitrary   type
  56.      expressions, not just type variables as used in Haskell.
  57.  
  58.   o  Instances of type classes can be defined at  non-overlapping,  but
  59.      otherwise arbitrary types, as described in section 14.2.5.
  60.  
  61.   o  List comprehensions  may include  local definitions,  specified by
  62.  
  63.  
  64.                                       111
  65.  
  66.  
  67.  
  68.  
  69. Introduction to Gofer         APPENDIX C: RELATIONSHIP WITH HASKELL 1.1         
  70.  
  71.  
  72.      qualifiers of the form <pat>=<expr> as described in section 10.2.
  73.  
  74.   o  No restrictions are placed on the form of predicates  that  appear
  75.      in the context for a class of instance declaration.   This  has  a
  76.      number  of  consequences,  including  the  possibility  of   using
  77.      (mutually)  recursive  groups  of  dictionaries,  but  means  that
  78.      decidability of the predicate entailment  relation  may  be  lost.
  79.      This is not a great problem  in  practice,  since  all  dictionary
  80.      construction  is  performed  before  evaluation   and   supposedly
  81.      non-terminating dictionary constructions will actually generate an
  82.      error due to the limited amount of  space  available  for  holding
  83.      dictionaries (see section 14.4.2).
  84.  
  85.  
  86. Other differences:
  87. ------------------
  88.   o  Whilst superficially similar the approach to type classes in Gofer
  89.      is quite different to that used in Haskell.   In  particular,  the
  90.      approach used in Gofer ensures that all necessary dictionaries are
  91.      constructed before the evaluation of an expression begins,  rather
  92.      than being built (possibly several times) during the evaluation as
  93.      is the case with Haskell.  See section 14 and reference  [11]  for
  94.      further details.
  95.  
  96.   o  Input/Output facilities - Gofer supports  only  a  subset  of  the
  97.      requests available in Haskell.  In principal, it should not be too
  98.      difficult to add most of the remaining forms of request (with  the
  99.      exception of those associated with binary files)  to  Gofer.   The
  100.      principal motivation for including the I/O facilities in Gofer was
  101.      to  make  it  possible  to  experiment  with  simple   interactive
  102.      programs.
  103.  
  104.   o  In Gofer, unary minus has greater  precedence  than  any  operator
  105.      symbol, but lower than that of function application.  In  Haskell,
  106.      the precedence of unary minus is the same as  that  of  the  infix
  107.      (subtraction) operator of the same name.
  108.  
  109.   o  In Haskell, the character `-'  can  only  be  used  as  the  first
  110.      character of an operator symbol.  In  Gofer,  this  character  may
  111.      appear  in  any  position  in  an  operator  (except  for  symbols
  112.      beginning with "--", which indicates the start of a comment).  The
  113.      only problems that I am aware  of  with  this  is  that  a  lambda
  114.      expression such as "\-2->2" will be parsed as such  by  a  Haskell
  115.      system, but cause a syntax error in Gofer.  This  form  of  lambda
  116.      expression is sufficiently unusual that I do not believe this will
  117.      cause any problems in practice; in any case, the  parsing  problem
  118.      can be solved by inserting a space: "\ -2->2".
  119.  
  120.   o  Pattern bindings are not currently permitted in either instance or
  121.      class declarations.  This restriction has  been  made  simply  for
  122.      ease of implementation, is not an inherent problem with  the  type
  123.      class system and is likely to be  relaxed  in  later  versions  of
  124.      Gofer if appropriate.  I have yet to see any examples in which the
  125.      lack of pattern bindings in class and instance declarations causes
  126.      any kind of deficiency.
  127.  
  128.  
  129.  
  130.                                       112
  131.  
  132.  
  133.  
  134.  
  135. Introduction to Gofer         APPENDIX C: RELATIONSHIP WITH HASKELL 1.1         
  136.  
  137.  
  138.   o  Qualified  type  signatures  are  not  permitted  for  the  member
  139.      functions  in  Gofer  class  declarations.    Once   again,   this
  140.      restriction was made for ease of implementation  rather  than  any
  141.      pressing technical issues.  It is  likely  that  this  restriction
  142.      will be relaxed in future versions of Gofer,  although  I  am  not
  143.      convinced that proper use can be made  of  such  member  functions
  144.      without some form of nested instance declarations (yuk!).
  145.  
  146.   o  The definition of the class Text given  in  the  standard  prelude
  147.      does not include the Haskell functions for reading/parsing  values
  148.      from strings; the only reason for omitting these functions was  to
  149.      try and avoid unnecessary complexity in the standard prelude.  The
  150.      standard prelude  can  be  modified  to  include  the  appropriate
  151.      additional definitions if these are required.
  152.  
  153.  
  154. Known problems in Gofer:
  155. ------------------------
  156.   o  The null escape sequence "\&" is not generated  in  the  printable
  157.      representations of strings produced by both The primitive function
  158.      primPrint (used to implement the show' function) and  the  version
  159.      of show defined in the standard prelude.  This means that  certain
  160.      strings values are  not printed correctly  e.g.  show' "\245\&123"
  161.      produces the string "\245123".  This is unlikely to cause too many
  162.      problems in practice.
  163.  
  164.   o  Unification of a type variable a with a  type  expression  of  the
  165.      form T a where T is  a  synonym  name  whose  expansion  does  not
  166.      involve a will fail.   It  is  not  entirely  clear  whether  this
  167.      behaviour is correct or not.
  168.  
  169.   o  Formfeeds '\f' and vertical tabs '\v' are  not  treated  as  valid
  170.      whitespace characters in the way suggested by the Haskell  report.
  171.  
  172.   o  Inability to recover from program stack  overlow  errors  in  some
  173.      situations.  This problem only affects the  PC  implementation  of
  174.      Gofer.
  175.  
  176.   o  Implementation of ReadFile may loose referential transparency; the
  177.      response to a particular ReadFile request may  be  affected  by  a
  178.      later WriteFile or AppendFile request for the same  file.   Whilst
  179.      this problem can be solved for UNIX based implementations, I  have
  180.      not yet found a portable solution suitable for all of the  systems
  181.      on which Gofer can be used.
  182.  
  183.  
  184. Areas for possible future improvement:
  185. --------------------------------------
  186.   o  Relaxing the restriction on type synonyms in predicates.
  187.  
  188.   o  General  purpose  automatic  default  mechanism  for   eliminating
  189.      certain forms of unresolved overloading.
  190.  
  191.   o  Improved checking and use of superclass and  instance  constraints
  192.      during static analysis and type checking.
  193.  
  194.  
  195.  
  196.                                       113
  197.  
  198.  
  199.  
  200.  
  201. Introduction to Gofer         APPENDIX C: RELATIONSHIP WITH HASKELL 1.1         
  202.  
  203.  
  204.   o  Simple facility to force dictionary construction at load-time.
  205.  
  206.   o  Provision for shell escapes :! etc within the Gofer interpreter.
  207.  
  208.   o  Debugging  facilities,  including  breakpoints  and  tracing  from
  209.      within interpreter.
  210.  
  211.   o  Separate interpreter and compiler programs for creating standalone
  212.      applications using Gofer.
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.                                       114
  263.  
  264.  
  265.