Lambda (was: Refactoring in Tunes)

[Laurent Martelli]

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

  >> But our system is not designed yet, so we can decide what we want
  >> to put in it.

  billy> Right.  And I'm telling you what I think our system should
  billy> do.

So do I :-)

  billy> It sounds as though you're saying that for any standard we
  billy> decide on, you would feel free to leave out parts of the
  billy> standard, and then blame the standard-compliant programs for
  billy> not running on your system.

No. I just think that we should define the best standard as possible. 

[...]

  >> I can even imagine that ML could accept "define square x :- x*x;"
  >> and define as many overloaded function as possible.

  billy> I imagined that as well at the time.  There are a few
  billy> problems with doing that -- for example, the number of
  billy> functions grows exponentially.  The type inferencing is
  billy> already NP-complete.

So type annotations are just an optimization hint and are not strictly
needed for semantics of the language.


  >> Isn't typechecking proving that no type errors will occur if you
  >> run the program ?

  >> From an academic viewpoint, I suppose so.  Most programmers find
  >> it more
  billy> useful when it proves that there IS a type error, and this is
  billy> the use for which I designed this.

These are the two sides of the coin. 


  >> Anyway, if you have somewhere : (defun f (x) (* x x)) and
  >> somewhere else (deftype f (int int))

  >> It's very easy for a GUI to gather the 2 thing and display int
  >> f(int x) = x * x ; The fact that the annotation refers to f
  >> places it next to f. It's up to the UI to display this in a
  >> convenient manner.

  billy> I don't get it, though.  Why would we deliberately make
  billy> things more complex?  Why shouldn't we design for simplicity?

My design makes the core language simpler since it does not have to
deal with type annotations. 

-- 
Laurent Martelli
martelli@iie.cnam.fr