Subject: Re: how to validate input?
From: Erik Naggum <erik@naggum.no>
Date: 2000/04/25
Newsgroups: comp.lang.lisp
Message-ID: <3165662049043666@naggum.no>

* Joe Marshall <jmarshall@alum.mit.edu>
| Technically, tail recursion and _first-class_ continuations have little
| to do with each other.

  not so, they are conceptual twins, and it would be silly to try to
  specify one without the other, even if it is technically possible to
  ignore the other half of the conceptual solution.  at the heart of the
  matter is whether a function call frame is heap-based or stack-based, but
  this is _not_ an implementation issue alone, it has to do with the whole
  concept of the "lifetime" of a function call.  tail recursion keeps the
  function call alive across function entry boundaries, i.e., entering a
  function does not mean you have a fresh call frame.  continuations keep
  the function call alive across function exit boundaries, i.e., exiting a
  function does not mean you dispose of all inferior call frames.  both
  invalidate the trivial concept of a function call that always exist at
  the leaf of a call tree and which can be talked about with a concept of
  identity, or in brief: the function call that differs conceptually from
  function calls in the popular literature and programming community.

  I find it interesting that several for-education languages have flirted
  with the heap-based call frame, but none of them have become popular, and
  current (very) popular hardware is also "unwilling" to make this run as
  fast as the much simpler stack-based call frame.  even register-rich
  hardware has chosen to make stack-based call frames very efficient, and
  heap-based call frames slow and requiring a lot of manual caretaking.
  this is not accidental, and it should not be dismissed as "oh, that's
  just hardware", which is an expression of the unhealthy arrogance I see
  in these for-education languages.

  in my view, requiring proper tail recursion and first-class continuations
  is evidence of an unwillingness to deal with implementation issues.  in a
  specification, such unwillingness is just too arrogant to be a good sign,
  especially when it is attempted covered up or not even explained.

#:Erik