Lambda (was: Refactoring in Tunes)

[Laurent Martelli]

>>>>> "billy" == btanksley  <btanksley@hifn.com> writes:

  >> From: Laurent Martelli [mailto:martelli@iie.cnam.fr] Subject: Re:
  >> Lambda (was: Refactoring in Tunes)

  >> >>>>> "billy" == btanksley <btanksley@hifn.com> writes:

  >> >> But couldn't it use type infering, à la Caml ?
  billy> In order to use type annotations to produce error messages,
  billy> type inference is _essential_.  The type annotations would
  billy> simply allow the inference engine to produce error messages
  billy> which are more appropriate to the problem.

  >> OK. So annotations should be what they are : annotations. That
  >> is, they should not be part of the program. They should be
  >> add-ons. Some sort of other program (an aspect program ?).

  billy> You could do that, but why?  The annotations are there to
  billy> allow the compiler to make your life easier, not dramatically
  billy> harder.  It's hard enough to add the annotations in the first
  billy> place -- don't make it any harder.

  billy> Also, the type annotations are intrinsically a part of the
  billy> function they're annotating.  They have absolutely ZERO use
  billy> outside of that function.

My point is that those annotations are not needed to run the code, so
a code evaluator should not be required to understand them. If
annotations are included in the code, it's hard to commnicate your
code to someone whose system does not understand annotations, or
understands another type of anotations.

Annotations are like a style sheet, it just allow *some* kind of
reader to *better* manipulate some objects. There can be many
different annotations : params type, params names ... That's what I'm
trying to say in my paper on separation of concerns : if it's not
needed, don't require it. 

Anyway, all this does not prevent anyone to build a frontend that
integrates annotations with the code itself. 

-- 
Laurent Martelli
martelli@iie.cnam.fr