A bunch of improvements come to my mind and can be implemented relativly
easy, e.g replacing the test with another test the input should obey and of
course other messages if the input is not what it should be.

Anyway, I think that this has been done before and I guess even in a portable
way. Could you give me a hand here?

because you asked....

My first reaction is that recursion is not really the best idea here, it really is
(logically) a "loop until" situation.  But perhaps that's just a matter of style and
there is no danger...

Otherwise, i don't do much "read"ing, so i can't help.  I do remember with Allegro 3
having my (student) program crash if the user hit <enter> without typing anything!  not
the most bullet-proof design :-)   (have you handled that?)

(clim:accept 'number)

See the myriad of options CLIM:ACCEPT has:

CLIM:ACCEPT type
            &rest accept-args
            &key stream view default default-type history
                 provide-default prompt prompt-mode display-default
                 query-identifier activation-gestures
                 additional-activation-gestures delimiter-gestures
                 additional-delimiter-gestures insert-default replace-input
                 present-p active-p

Coby

(defun get-input ()
   (let (raw-input number)
      (loop until number
        do (format t "Please Enter a Number.  e will exit.~%")
        (setf raw-input (read-line))
        (setf number (parse-integer raw-input :junk-allowed t))
        (when (and (null number) (equal raw-input "e")) (return)))
      number)

   >> (defun get-input ()
   >> "Prompt user for a number if it is a number
   >> return it otherwise return nil"
   >> (format t "Please give me a number (e for Exit) ")
   >> (let ((line (read)))
   >> (if (numberp line)
   >> line
   >> (if (y-or-n-p "Not a number, really exit?")
   >> nil
   >> (get-input)))))

   RJ> - READ neither does read a line nor does it return one, it reads the
   RJ>   printed representation of a Lisp object and
   RJ>   returns a corresponding Lisp object.
Ok I can use read-line instead
   RJ> - don't use recursion, use a loop. CL implementation don't need
   RJ>   to be tail recursive.
Why? I have written the same with a loop but it looks IMO more ugly. But
maybe it's just that I've written it poorly. Here it is:
(defun get-input ()
"see 'get-input-recursive'"
(let ((line))
  (do ((exit nil))
      (exit line)
    (format t "Please give me a number (e for Exit): ")
    (setf line (read))
    (if (numberp line)
        (progn
          (setf exit t)
          line)
      (when (y-or-n-p "Not a number, really exit?")
        (setf exit t)
        (setf line nil))))))

   >> Anyway, I think that this has been done before and I guess even in a portable
   >> way. Could you give me a hand here?

   RJ> If you have CLIM do:

   RJ> (clim:accept 'number)

   RJ> See the myriad of options CLIM:ACCEPT has:

   RJ> CLIM:ACCEPT type
   RJ>             &rest accept-args
   RJ>             &key stream view default default-type history
   RJ>                  provide-default prompt prompt-mode display-default
   RJ>                  query-identifier activation-gestures
   RJ>                  additional-activation-gestures delimiter-gestures
   RJ>                  additional-delimiter-gestures insert-default replace-input
   RJ>                  present-p active-p

I guessed there would be way ;-)

   CB> (defun get-input ()
   CB>    (let (raw-input number)
   CB>       (loop until number
   CB>         do (format t "Please Enter a Number.  e will exit.~%")
   CB>         (setf raw-input (read-line))
   CB>         (setf number (parse-integer raw-input :junk-allowed t))
   CB>         (when (and (null number) (equal raw-input "e")) (return)))
   CB>       number)

This is really nicer, thanks

  it's quite strange, but people who have been trained to write iteration
  using tail recursion tend to write the most amazingly ugly loops, and it
  isn't a question of lack of training in writing loops, it's conceptual.
  (yet another case of Scheme hurting people.)

| (defun get-input ()
| (let ((line))
|   (do ((exit nil))
|       (exit line)
|     (format t "Please give me a number (e for Exit): ")
|     (setf line (read))
|     (if (numberp line)
|         (progn
|           (setf exit t)
|           line)
|       (when (y-or-n-p "Not a number, really exit?")
|         (setf exit t)
|         (setf line nil))))))

(format t "please enter a number: ")
(do ((input (read nil nil nil) (read nil nil nil)))
    ((or (null input) (numberp input)) input)
  (format t "not a number, try again: "))

  I'd use a different input function that read, but that's your call.

   EN>   it's quite strange, but people who have been trained to write iteration
   EN>   using tail recursion tend to write the most amazingly ugly loops, and it
   EN>   isn't a question of lack of training in writing loops, it's conceptual.
   EN>   (yet another case of Scheme hurting people.)
Thanks I take it as an compliment. Maybe I do have understand a bit of Scheme
;-)

   EN> (format t "please enter a number: ")
   EN> (do ((input (read nil nil nil) (read nil nil nil)))
   EN>     ((or (null input) (numberp input)) input)
   EN>   (format t "not a number, try again: "))
I agree this is really nicer and I'll keep in under my pilow ;-)

TIA

That being said, although CL isn't required to be properly tail
recursive, I think *most* CL implementation have the ability to
optimize tail calls between functions, and even more have the ability
to optimize `self' tail calls or tail calls between internal labels
expressions.  You may need to (declare (optimize (speed 3))) or
(declare (optimize (debug 0))) or set some internal compiler switch.

(Are there any popular CommonLisps that don't do *at least* self tail
recursion?)

  coming from a Scheme background, it should be easy for you to explain why
  Scheme needs it so badly and what implementation costs are associated
  with this requirement.  then you should consider whether there are any
  needs in Common Lisp that are unfulfilled without it, like there would be
  in Scheme without it, and whether they are worth the costs.  please note
  that proper tail recursion is closely related to first-class continuations.

  incidentally, it is never productive to ask why things are "left out" of
  a standard unless you know that that was what happened.  tail recursion
  is simply a non-issue in most languages, and where it matters, it had
  been a choice of the compiler writers and optimization settings, not a
  hard requirement in a standard.

  that said, one reason to leave out random "good ideas" from a standard is
  that requiring something that nobody needs in doesn't mean people will
  abide by it, but it does mean they will have to start to ignore parts of
  the standard for _good_ reasons.  this is very, very bad when it happens.

Technically, tail recursion and _first-class_ continuations have little
to do with each other.  An implementation that is properly tail
recursive could not have first-class continuations, and an
implementation that has first-class continuations need not be
tail-recursive.  (There are some implementation techniques that give
you both, however.)

To clarify my previous post, I said:

  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.

Anyone who has implemented both would agree that it makes sense to
specify one without the other.  In fact, there are several properly
tail recursive Scheme implementations that do not have first-class
continuations, and there are several properly tail-recursive
CommonLisps, also without first-class continuations.

Consider looking at it from a denotational semantic viewpoint.  When
you do this you will notice that first-class continuations are
explicitly modeled by reifying the implicit interpreter continuation
into a denotable value.  Tail recursion doesn't appear *at all* in the
denotational equations.

If you cannot reify a continuation, you can prove that the lifetime of
the continuation is no shorter than the lifetime of its children, thus
when you implement your language, you can allocate your continuations
in a stack like manner.

What about tail recursion?  It doesn't enter into the denotational
semantics because it has no semantic meaning.  It is purely an
implementation decision to ensure that you don't needlessly nest
continuations.  If the stack were of infinite size, tail recursion
would be unnecessary.

Tail recursion involves freeing the current stack frame when a call to
another function will supply the value to be returned from this call.
i.e.,  rather than leaving the stack frame on the stack in sort of a
zombie state (it does nothing but pop itself when returned to), we
dispose of the frame immediately.

There are a few mechanisms by which you might do this:  if you have a
stack, you can pop it and immediately re-use it, if you have a heap,
you could immediately put the frame on the free-list, or you could
abandon the frame.

But the presence of tail recursion doesn't invalidate the notion of
stack allocation:  Every frame is managed in a last-in/first-out
manner.

I should point out that with the right hardware, stack-oriented
tail-recursion can be made incredibly fast.

This is the reason Scheme requires TCO -- the designers wanted programmers
to be able to express iteration using recursive syntax, and didn't want the
traditional limits of recursion to apply.

Some of these (especially N-and-a-half-times and exception handling)
have been added to languages designed since Knuth's article, but others
haven't.

Tail-call optimization allows for natural expression of all of them ---
indeed, any kind of control flow you like --- without paying the space
penalty for recursion.

I'd like to point out that each step of the Baeza-Yates string search
involves ANDing many pairs of bits, which is inherently more
computation than each step of the Knuth-Morris-Pratt algorithm (which
only requires running a simple state machine).  But the Baeza-Yates
algorithm runs at very close to the same speed on modern hardware
(well, most computers, past and present) because that hardware is good
at ANDing many pairs of bits in parallel for reasons unrelated to
Baeza-Yates string searching.

Likewise, floating-point addition is far more complex --- and
inherently slower --- than integer addition.  But modern hardware has
huge floating-point units to speed up the floating-point addition,
which make it nearly as fast as integer addition.

  I have looked around at implementations, and what I have found is that
  the old call-frame is basically unwound to the exact same point where a
  return from the function would occur, then a jump to the new function
  takes place instead of a call, and a new call frame is set up, just as if
  it were a normal function call.  the savings is realized in that the
  depth of the stack is not increased, but other than that, nothing, and
  there is much loss to go with this gain: information about the caller
  no longer exists.

| Again, I don't see how tail-call optimization can be tarred with the same
| brush as first-class continuations in this regard.  TCO is precisely a
| willingness to deal with implementation issues.   In fact, I've known
| semanticists to express dismay that TCO deals with "grubby"
| implementation choices.

  the point I'm trying to get across is that _requiring_ proper tail
  recursion is different from _optimizing_ for tail calls as an option.
  the requirement is very much a semantic issue.  I'm all for optimizing
  tail calls when _I_ want to, and can make an informed choice.  I'm
  against a requirement.  please understand the difference.

  I also said "this is not an implementation issue _alone_".  therefore, I
  would appreciate if you argued against the semantic issues that I think
  exist in the design (and requirements) of both of these mechanisms.

| Consider looking at it from a denotational semantic viewpoint.  ...  Tail
| recursion doesn't appear *at all* in the  denotational equations.

  function calls don't appear as such in denotational equations, either, so
  that's really no surprise.

  rewriting a self-tail call to a jump affects recursion.  _requiring_ all
  tail function calls to be jumps affects the entire system adversely, and
  does affect the semantics of the language, even if it should vanish along
  with many other important issues in denotational semantics.

| If the stack were of infinite size, tail recursion would be unnecessary.

  unfortunately, language design has to be performed in the real world.
  contrary to popular belief in some quarters, programming language design
  is not pure mathematics.  there are _severe_ constraints on what we can
  do, and programming language pragmatics do enter the picture.  there are
  times when you can ignore these issues to great benefit, and there are
  times when you can't lest you do something terribly stupid.  confusing
  these times is perhaps the worst thing you can do when you design a
  language.  I maintain that Scheme does exactly that with both the proper
  tail call _requirement_ and with the continuations, for the same reason:
  they have a different function call notion than other languages.

  in my view, it doesn't make much sense to _require_ tail call recursion
  unless you do something that would otherwise make this expensive to add
  as an obvious option.  the reason is that there is a huge difference
  between a self-tail (recursive) call and a normal call, but a requirement
  must make them behave identically.  it would make _much_ more sense to
  require only that self-tail calls be syntactic sugar for a loop.

  predictive cache line acquisition in the heap allocation direction.
  the stack is fast because it's nearly always in the fastest cache.
  if it weren't, it would be disastrously slow on modern hardware.

Flemming