I'm having trouble going from the tutorials to the real world. For
example, a lot of what i do is related to processing text files. So, i
though i'd write a simple/stupid program to count the number of lines
in a file. Here it is:

;; count number of lines in file key.html
(with-open-file (ifile "key.html" :direction :input)
                (setf nlines 0)
                (loop
                  (if (read-line ifile nil)
                    (setf nlines (+ 1 nlines))
                    (return nlines))))

It doesn't work (it just hangs, so i think it's stuck in the loop). I
thought it would read lines until the end of the file, when the read-
line would return nil, and that would trigger the second form inside
the if (a return, to get out of the loop).

I'm sorry for posting something so stupid, but why doesn't this work?

--
Glauber Ribeiro
theglau...@my-deja.com
"Opinions stated are my own and not representative of Experian"

OK. Using TRACE, i found that read-line wasn't returning nil, but
something like #<END-OF-FILE>. So i added the third optional parameter,
the one that tells it what to return at end of file. This made me do
the (IF) backwards:

;; count lines
(with-open-file (ifile "key.html" :direction :input)
                (setf nlines 0)
                (loop
                  (if (eql 'eof (read-line ifile nil 'eof))
                    (return (print nlines))
                    (setf nlines (+ 1 nlines)))))

And it works...

And, of course, this works too:

(with-open-file (ifile "key.html" :direction :input)
                (setf nlines 0)
                (loop
                  (if (read-line ifile nil nil)
                    (setf nlines (+ 1 nlines))
                    (return (print nlines)))))

So, i plod along, undaunted...
I'm pretty sure this is an ugly program, and i appreciate suggestions.

--
Glauber Ribeiro
theglau...@my-deja.com
"Opinions stated are my own and not representative of Experian"

have not looked further into it, but I found this interesting enough to
post it.

  You're using a free variable, nlines, in this code.  You should not
  use a free variable unless you have very specific need for it.  This
  does not affect the correctness of your code, however.

| It doesn't work (it just hangs, so i think it's stuck in the loop).

  Try being explicit in the value of eof-value, i.e.

(read-line ifile nil nil)

| I thought it would read lines until the end of the file, when the
| read- line would return nil, and that would trigger the second form
| inside the if (a return, to get out of the loop).

  I think it would be instructive to print the value from read-line:

(print (read-line ifile nil))

  print returns its value.

| I'm sorry for posting something so stupid, but why doesn't this work?

  Seems like a bug in your Common Lisp implementation.  Which is it?

  Thanks for noting this.  I'm waiting for a report from Bruno Haible
  whether this was a typo in the standard or (gasp!) a bug in CLISP.

So, the revised, slightly cleaner code looks like this:

(with-open-file (ifile "key.html" :direction :input)
  (let ((nlines 0))
    (loop
       while (read-line ifile nil nil)
       do (incf nlines)
       finally (return nlines))))

The even more compact version uses the for and from loop functionality:

(with-open-file (ifile "key.html" :direction :input)
  (loop
    for nlines from 0
    while (read-line ifile nil nil)
    finally (return nlines)))

Thom

[1] I learned my Lisp somewhat in a vacuum, so I sometimes find that
what I consider elegant or clean, other people consider ugly or unclear.

(with-open-file (ifile "key.html" :direction :input)
  (loop for line = (read-line ifile nil)
        while line
        counting 1))

If the loop implementation of your CL system supports extending loop
paths you can even write a loop path that gives you each line in the
file. I have such a thing in my .clinit.

Then you can do:

(loop for line being each line of ifile
      count 1)

If you use the simple loop, you might consider do:

(with-open-file (ifile "/etc/passwd" :direction :input)
  (do ((line (read-line ifile nil) (read-line ifile nil))
       (count 0))
      ((null line) count)
    (incf count)))

BTW: I very often supply the eof-value explicitly, for reasons of
clarity.

- The most obviously mistake lies in your use of setf to establish a
  new variable.  In the absence of any binding, this will be treated
  as a reference to a global special variable, which you don't want.
  Use let to introduce local lexical variables.  Once such a binding
  exists, you can alter the value of the binding via setf & friends,
  if you want to.

- The variable names are distinctly unlispy:  Since CL (and Scheme)
  allows useful separator characters in symbols, and your environment
  relieves you of the burden of retyping long names, you are free to
  use long, self-descriptive names.

- Wrap your code fragment in a function definition, and you get a
  ready made line-counting function for free...

- While working with low-level looping constructs can be instructive,
  most programmers would use a higher-level looping construct to
  more clearly express the intent of the code.

- Don't print the result yourself, since the surrounding code or the
  top-level read-eval-print loop will already do this for you

- Use documentation strings to document your functions

Given all of the above, your function might be written like this

  (defun count-lines-in-file (filename)
    "Count the lines in the file indicated by `filename'."
    (with-open-file (stream filename :direction :input)
      (do ((line-count 0 (1+ line-count)))
          ((null (read-line stream nil nil)) line-count))))

Or, using the extended loop facility:

  (defun count-lines-in-file (filename)
    "Count the lines in the file indicated by `filename'."
    (with-open-file (stream filename :direction :input)
      (loop while (read-line stream nil nil)
            sum 1)))

Or, using simple loop, like you did:

  (defun count-lines-in-file (filename)
    "Count the lines in the file indicated by `filename'."
    (with-open-file (stream filename :direction :input)
      (let ((line-count 0))
        (loop
          (if (read-line stream nil nil)
              (incf line-count)
              (return line-count))))))

Beware that all of the code is untested, though ;)

Regs, Pierre.

[...]

Thanks!

glauber

--
Glauber Ribeiro
theglau...@my-deja.com
"Opinions stated are my own and not representative of Experian"

Thanks!

--
Glauber Ribeiro
theglau...@my-deja.com
"Opinions stated are my own and not representative of Experian"

Thanks!

--
Glauber Ribeiro
theglau...@my-deja.com
"Opinions stated are my own and not representative of Experian"

  Simply using while (read-line ifile nil nil) seems even more compact.

  However, I have this negative gut reaction to wanton waste, as in
  effectively allocating as many strings as there are lines for no
  good reason, just exercising the garbage collector, so while we're
  at it, how about

(loop for char = (read-char ifile nil nil)
      while char
      count (char= char #\newline))

  Note that read-line will return nil on an empty file, but the data
  leading up to the end-of-file if no newline intervened and then nil
  on the next call, effectively counting a non-empty file containing
  no newlines as having one line.  This may be relevant.

| (loop for line being each line of ifile
|       count 1)

  Elegant.

the default value for eof-value is nil, which I'd expect to provide
the desired result.

  (setq foo ...)

BTW, in an earlier post Erik wrote:

  You're using a free variable, nlines, in this code.  You should not
  use a free variable unless you have very specific need for it.  This
  does not affect the correctness of your code, however.

  "Free variable" is orthogonal to "undeclared variable".  Your gripe
  is about "undeclared variables".  I talked about "free variable".
  Please, some precision when you pick nits.

  One that is not bound by a surrounding (binding) form.

Indeed, the "free" use of a variable is orthogonal to the "undeclared"
use of a variable, but that does in itself not mean anything.  A Usenet
posting may be factually incorrect, and it may be stupid.  But it may
be stupid without being incorrect, and it may be incorrect without
being stupid, and it may be both stupid and incorrect.  These two
properties are orthogonal.  I know this because I have both read and
writen many Usenet postings over the past 17 years.

Similarly, a reference to a variable may be either or both of "undeclared"
and "free".  Rather than muck around in the meaning of these terms, I'd
ask Erik the following focussed question:

Assume a freshly-booted ANS-compliant CL implementation.  What behavior,
if any, is guaranteed by execution of the following form?

 (print (progn (setq pie 22/7) pie))

Now, in every implementation I know, this will print an approximation of
PI, with (if in the interative top level) various prompting and whitespace
handling.  It might (especially in compiled code) or might not warn about
the undeclared variable PI.  None of this matters to me.

I want to know whether this behavior (modulo toplevel interaction,
prompting, and newlinification) is defined by the ANS.  If you claim that
it is, please cite the ANS section references.  I claim that the behavior
is either "is an error" or "is undefined".

* (setq pie 22/7)
==> 22/7
* pie
==> 22/7

illustrate your point just as well?

<URL:http://www.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Body/sec_3-1...>

    If a form is a symbol that is not a symbol macro, then it is the
    name of a variable, and the value of that variable is
    returned. There are three kinds of variables: lexical variables,
    dynamic variables, and constant variables. A variable can store
    one object. The main operations on a variable are to read[1] and
    to write[1] its value.

    An error of type unbound-variable should be signaled if an unbound
    variable is referenced.

SETQ is defined to bind variables to forms. A variable is just any
name in the 'variable' namespace (Yeuch! LISP2! **Nasty**).
<URL:http://www.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Body/spefor_...>

So, in your example, setq binds the name 'pie' in the current dynamic
environment, by assigning a value to that name in the namespace (all
possible names exist (in a platonic sense) in the namespace, it's just
that the overwhelming majority of them are never instantiated by being
bound). The environment happens to be top-level. The following
evaluation of the name pie retrieves the value from the namespace.

Therefore the behaviour you describe is mandated by the hyperspec. I
don't have the text of the ANSI specification to hand, but have
sufficient trust in the hyperspec editors to believe that if it's
mandated by the one, it's mandated by the other.

--
si...@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/

  I answered it years ago, to your satisfaction if I recall correctly.

  However, both the question and the answer have exactly _nothing_ to
  do with anything anybody else are or have been discussing.  You
  brought up "undeclared" in attempt to quibble my "free variable" to
  death, and now you bring up "top-level" because it obviously didn't
  work to quibble over "undeclared" in the context we were discussing
  this.  I have better things to do.  You should go soak your head.

  Wrong.

| A variable is just any name in the 'variable' namespace

  Wrong.

| (Yeuch!  LISP2! **Nasty**).

  Idiot.

| So, in your example, setq binds the name 'pie' in the current dynamic
| environment, by assigning a value to that name in the namespace (all
| possible names exist (in a platonic sense) in the namespace, it's just
| that the overwhelming majority of them are never instantiated by being
| bound). The environment happens to be top-level. The following
| evaluation of the name pie retrieves the value from the namespace.

  Bogus from A to Z.

| Therefore the behaviour you describe is mandated by the hyperspec.

  Wrong.  (If it is, it isn't because of your reasoning.)

  A more interesting question than Steven M Haflich's stupid quibbling
  is whether (setq foo 1) is identical to (setf (symbol-value 'foo) 1)
  if foo is not lexically bound.  If it is, then it is completely
  beside the point whether foo is "declared" or not.