Subject: Re: how to validate input?
From: Erik Naggum <>
Date: 2000/04/26
Newsgroups: comp.lang.lisp
Message-ID: <>

* Joe Marshall <>
| I am.  I assert that the _semantics_ of the language are unchanged
| when tail-recursion is present:  the results of *all* computations
| _that produce results_ is identical under both; thus there is no
| semantic issue at all.

  this is a very narrow definition of "semantics", and I don't think
  it's useful to discuss such definitions, so suffice to say that I do
  not respect the view that the only semantics are those that can be
  described by denotational semantics.

| Certainly if full proper tail-recursion is too expensive to implement, 
| but no tail-recursion whatsoever is undesirable, self-tail-recursion
| is an attractive alternative.  Indeed, many Scheme implementations
| only provide self-tail recursion. 

  I still have the impression that I'm not getting through with the
  distinction between _requiring_ a particular implementation of tail
  calls and _allowing_ it as and when desired.  there is _nothing_
  whatsoever that affects "allows" if one argues against "requires".
  I have no interest in countering arguments against "allows", as I
  have explicitly argued _for_ "allow", already.

  among the reasons I'm no fan of Scheme is that the _requirements_ in
  its language design are very serious mistakes, and they affect the
  way Scheme people think about language design so adversely that it
  is sometimes impossible to penetrate the view that "if it isn't
  required in the standard, you can't trust smart people to do it".
  e.g, I don't see anyone (except Scheme people who knock down
  strawman arguments) even bring up "no tail-recursion whatsoever".

  it's a cheap argument, but it accurately reflects my sentiments
  towards most of what distinguishes Scheme from everything else: if
  it's so smart, other smart people will want to do it, but if they
  don't, maybe it wasn't so smart to begin with.  this is the best
  simple answer to the sentiment nearly unique to Scheme: "why does
  language X _lack_ random feature Y (from Scheme)", which is raised
  in nearly those words in c.l.l from time to time.

  as an even cheaper argument, I'd summarize Scheme by saying that all
  its good ideas have been absorbed elsewhere and the only stuff left
  to brag about is that which wasn't smart to begin with, which tends
  to reinforce the silliness of the Scheme superiority.

  in contrast to this, Common Lisp doesn't suffer from a need to feel
  superior, mostly because it has so much "impure" and historic stuff
  in it that any "superiority" would be ridiculous, anyway, but it has
  a unique blend of pragmatic and elegant design that means you can
  always attack specifics, but you can't attack the design without
  implicitly or explicitly arguing for a _worse_ design.  that's why
  the language specification doesn't _require_ a smart feature that
  isn't smart across the board and always, but also doesn't disallow
  it (like some other languages do through sheer incompetence).