With respect to the more visual oriented, I think what helped me most
was to recognize that there is structure but that parentheses are not
an issue one needs to care about, as long as you do follow it. I think
Graham has an example in his "Ansi CL" book in which he presents some
Lisp code with and without the parens. It's getting the structure that
matters, not the parens. I think, a claim somebody made is likely to
be true across most programming languages, which is that it does not
really matter what style you're following, it's following the style
that matters [2].

But then again, I may be one of those who you would classify as a
visual oriented person, although I tend to see myself as being verbal
oriented. Come to think of it, I'm a very unlikely candidate for
participating in an obfuscated code contest, although I am uncertain
whether that tells a story or doesn't.

Holger

Footnotes:
[1]  Some time ago, I made some whitespace modifications to some old
and very ugly looking code. I was not the only one feeling that the
result was much more readable afterwards.

[2]  Of course, when you have to follow some style guideline enforced
by external forces, this may throw you off when its totally against
your personal preferences.

42

Ed L Cashin <ecas...@uga.edu> writes:

Hello!!!!!!

The point being that in CL you can modify the language, and make it
look like CL or something else.

Here is one of my favourite `primes' in conforming CL.

(in-package "SETL-USER")

(defun primes (max)
  [n in (range 3 max 2)
     / (not (exist m in (range 3 (min (1- n) (+ 2 (sqrt n))) 2)
                     / (= (mod n m) 0)))])

Cheers

  Sigh.  I wrote:

    It appears warranted by the various reactions people have posted and
    told of elsewhere to conclude that Common Lisp is a language that is
    better suited for those who are more verbal than visual in how they
    remember and learn.

| For instance, a verbal learner should not be thrown off by code like
| (member (car (list (do-something here (based on another complicated
| computation) ... <bunch of further arguments elided>)))).  This seems
| counterintuitive to me, I think even experienced Lisp programmers tend to
| have (reading) problems with such gross code. [1]

  On what basis do you conclude something about what a "verbal learner"
  should or should not be thrown off by?

| But then again, I may be one of those who you would classify as a
| visual oriented person

  Why do you think this is an either-or issue?  When I write "more verbal
  than visual" and try to be very clear that we are talking about a point
  on a line between two extrama, please do not waste my time by assuming
  that only the extrema are worth talking about.  Nobody is "classified" as
  a visual-oriented person, it is a matter of what you are more comfortable
  with, not some one-bit flag in your personality.

(aref *some-array* 10)
vs.
some_array[10];

In C, the braces take the place of "aref" and are easily spotted, even
by someone who has trouble spotting "aref" in a mass of text. Thus,
discounting syntactic characters (parens, semi-colons, and braces), C
code has a lot more non-character symbols than Lisp. The structure is
still important in both cases.

I show the extreme example of a visually-oriented language, but I've
so far managed to avoid learning any Perl.

Thom

Regards,
Julian

Holger

More to the point though, even if, in CL, words matter "more" than
other things, formatting still is an important matter. But formatting,
or structure, is clearly an issue of visually grasping what's going
on. That's an important support to (verbally) understanding code.

I hasten to add (that I believe) that throwing a bunch of non-text
characters all over the place to further enhance such support is
misguided.

Holger

What I meant was that doing `library standard' or `language standard'
systems is, in my opinion, very hard indeed (and many of the so-called
`standard libraries' such as, for instance, the Win32 API are in my
opinion good examples of systems which are *failing* to be good enough
and thus require endless reinvention).

I'm all in favour of general tools (which should be library/language
standard), and I think that CL is a very good example of such a
general tool whose design is actually adequate in almost all areas
(that is meant to be very high praise: there aren't any bits of CL
which I find unusably badly designed, which is not something I've come
across very often).

*But*, since I think that design of general tools is so hard, or at
least it is hard for me, I tend to not try, but instead to design
special tools for the job at hand.  That way I actually get the job
done.

So I wasn't making a value judgement, more trying to describe how I
work.

Cheers

(maphash (lambda (key value) (format t "~A => ~A~%" key value))
         (equal-hash-table "foo" "bar" "baz" "bar"))

The point being that hash-tables (_unlike_ many other data-structures
in CL), lack both reader-syntax and simple creation functions.  Thus
the disadvantage when compared to Ruby/Perl/...;  but I consider that
accidental, since CL does have such support for things like lists,
vectors, arrays, etc.

Probably make-hash-table should take an initial-contents keyword arg,
just like make-array does, e.g.

(maphash (lambda (key value) (format t "~A => ~A~%" key value))
         (make-hash-table :test #'equal
                          :initial-contents '(("foo" "bar") ("baz" "bar"))))

Regs, Pierre.

(+ 4 5)
=> 9

It's as simple as that! Here are some more examples. Say I want to add 4
to the result of multiplying 5 by 2. Starting from the outside, I write:

(+ 4 ...)

This applies the function plus the the argument 4 and the result of the
multiplication (represented here as ...). Now how do you do the
multiplication? Exactly the same way you did the addition:

(+ 4 (* 5 2))
=> 14

All function application works exactly this way. The interpreter or
compiler executes code by evaluating it. Evaluation for an number or
string returns that number or string:

4
=> 4

"foo"
=> "foo"

Evaluation of a symbol which refers to a variable returns the value of
that variable:

;; x has been set or bound before to 5
x
=> 5

Evaluation of a list (which is a function application) evaluates every
element of the list (I'm simplifying a little bit here, and using the
semantics of Scheme, rather than Common Lisp, because it makes more
sense that way), and then applies the function which appears at the
beginning to the (evaluated) rest of the arguments (I will use < and >
to enclose the evalueated value of the elements of the list):

(+ 4 (* 5 2))
  (<function:+> <number:4> ...)
    (<function:*> <number:5> <number:2>) => 10
  (<function:+> <number:4> <number:10>) => 14
=> 14

The difference between a function and a special form is that in a
special form, it doesn't go through and evaluate every element. Instead,
it looks at the first one, and based on that decides how to evaluate the
rest. For example, when you are using if, you don't want it to evaluate
both the true and false conditions. For example, if you're writing
something that controls a nuclear weapon launch (this example stolen
from SICP), you don't want the statement

(if (at-war? us)
  (launch missile)
  (keep-waiting))

to launch the missile every time the if is evaluated!

So you see, parentheses in lisp are actually much simpler than those in
other languages. In C, you need to learn about precedence rules, square
brackets, curly braces, and all kinds of other delimeters, and
parentheses are used for three different things (typecasting, function
calls, and grouping arithmetic statements), while in lisp they are only
used for function calls and special forms.

If you don't want to learn all of Common Lisp, I would recommend Scheme,
which is much conceptually simpler than Common Lisp, but works in the
same basic way. There are some good intros online; go to
<http://www.schemers.org/>. Especially good is Abelson and Sussman, and
Sussman's "Structure and Interpretation of Computer Programs" at
http://mitpress.mit.edu/sicp/full-text/book/book.html (the link is kind
of buried if you try to find it on schemers.org).

(apologies for presenting scheme and advocating scheme on
comp.lang.lisp, but I think that it's better to introduce someone who
doesn't understand all those parentheses to scheme, rather than common
lisp, where you don't evaluate every element of the list uniformly)

As by definition an atom is anything that is not a cons, then insofar
as the second sentence is true, it's trivially true.

This gives us problems with the third sentence, as atoms thus include
things like packages, arrays, hash tables, and CLOS instances, which I
hope you will agree are generally _not_ "things that you won't need to
use that much"...

If in the second sentence you had instead said "Everything in lisp
_code_ is either an atom or a list", you could have made a rather more
defensible (if still not entirely justified) claim on the third
sentence, because code doesn't often contain literal hash tables.

OK, maybe I'm nit-picking, but confusing lisp code syntax with sexpr
syntax, and confusing the outward sexpr-based representation with the
actual objects are both common new-user mistakes, and I think it helps
to be exact with terminology when explaining.

-dan

--

I think hash-tables are meant to store larger amounts of unordered data and
I cannot see using the :initial-contents to populate a 1000+ key/value pairs
(or for that matter 100,000 values).  I would rebel at doing the typing.
For me, storing 2 key/value or even 100 values in a hash table is just not
worth it.

It is for those reasons that I think an initial-contents argument to
make-hash-table makes as much sense as it does for make-array.  Of
course this is not something I'm going to fret about, but I've more
than once written a "make-hash-table-from-kv-pairs"-type function, and
wouldn't consider such an addition without some good will.

Of course your implicit point that alists are often a better choice
(which accidentally also have good support for literal input) for
smallish lookup tables is duly taken.

Regs, Pierre.

Whereas I'm a visually terrible person :-), so according to Erik's
criterion it makes sense that I like Lisp; but I also find visual
tricks like syntax-colouring extremely helpful, in Lisp and also in
other languages. (Maybe I find those tricks helpful *because* I'm
not very visual; perhaps if my visual subsystem worked better it
would do those jobs unaided.)

And, despite being very "verbal", I do find that sometimes the
"verbosity" of Lisp bothers me. I don't think I've yet found an
instance where it's (1) genuine verbosity and (2) not easily
fixed with a bit of macrology or read-table manipulation; but
it can still cause discomfort. It's possible that the discomfort
is a useful signal that macrology might be in order.

                                *

Example: Earlier in the thread, someone posted a comparison between
two code snippets, one in Ruby and one in Lisp. Both had the form:
build a hash table containing known keys and values, then iterate
over it. The Ruby code was shorter and allegedly clearer. (I find
the ambiguous use of curly brackets in Ruby disagreeable, but never
mind that.) And it's true: the CL code is verbose and hard to read.

But, if you're doing a lot of that sort of thing then it's the work
of a minute (well, OK, five minutes) to write two simple macros so
you can write

    (dohash (key value)
            (hash ("foo" "bar") ("baz" "quux"))
      (format t "~&~A -> ~A.~%" key value))

which seems to me just as clear (to someone with a little Lisp
experience; no one denies that Lisp takes getting used to) as

    {"foo" => "bar", "baz" => "quux"}.each {
      |key, value|
      print key, " -> ", value, "\n"
    }

or, for that matter,

    for key,value in {"foo": "bar", "baz": "quux"}.items():
      print key, "->", value, "\n"

except that FORMAT looks too much like line noise to some readers.
(Compression implies near-randomness.) Again, if you do a lot of
writing sequences of things to *STANDARD-OUTPUT* then it's the
work of another minute or two to write a function so you can say

    (dohash (key value)
            (hash ("foo" "bar") ("baz" "quux"))
      (output key " -> " value #\Newline))

Ruby and Python and all sorts of other languages have advantages
over CL, but brevity and clarity aren't among them unless either
your programs are so short that brevity and clarity don't matter
anyway, or you're deliberately choosing to write CL in a way that
doesn't provide the sort of brevity and clarity you want.

                                *

    (defvar *preferred-hash-test* 'equal)

    (defmacro hash (&rest pairs)
      (let ((result (gensym)))
        `(let ((,result (make-hash-table :test ',*preferred-hash-test*)))
           ,@(loop for (key value) in pairs collect
               `(setf (gethash ,key ,result) ,value))
           ,result)))

    (defmacro dohash ((k v) hform &body body)
      `(loop for ,k being each hash-key of ,hform using (hash-value ,v) do
         . ,body))

    (defun output (&rest values)
      (loop for value in values do (princ value)))

  When a hash-table is all you have, you tend to optimize it heavily.  The
  same goes for regexps.  Both hash-tables and regular expressions are very
  powerful and general tools, but they turn into monstrosities when all the
  more specialized tools are effectively removed from the language they use.

  Common Lisp has the disadvantage compared to the one-trick languages that
  the different access functions for various kinds of mappings between key
  and value are precisely that -- different.  When there is only one way to
  do it, being offered several ways is just confusing, and so people who
  think "hash-table" when they should have thought "key-value mapping" will
  miss simple and elegant things like property lists or association lists.

  I mean, if { "foo" => "bar", "baz" => "zot" } is so great, why is not
  (("foo" . "bar") ("baz" . "zot"))?  Is it _only_ the sugar-coated syntax
  that is so visually appealing to some?  If so, a Common Lisp programmer
  will write a small parser function that is called via the reader-macro
  support to read this list.  Why is this not more used?  I belive it is
  because most people who pine for other syntaxes have no clue how to go
  about specifying them or writing parsers for them, and because once you
  have grown that clue, you do not need it or, more importantly, want it.

  But what the heck.  Proof of concept follows.  

(let ((mapping-types ()))
  (defun readtable-mapping-type (readtable)
    (check-type readtable readtable)
    (or (cdr (assoc readtable mapping-types)) :alist))

  (defun (setf readtable-mapping-type) (mode readtable)
    (check-type readtable readtable)
    (check-type mode (member :alist :plist :eq :eql :equal :equalp))
    (let ((existing (assoc readtable mapping-types)))
      (if existing
          (setf (cdr existing) mode)
        (push (cons readtable mode) mapping-types))))

  (defun mapping-reader (stream char)
    (declare (stream stream) (ignore char))
    (loop
        with mapping-type = (readtable-mapping-type *readtable*)
        with key and value
        with hashtable = (case mapping-type
                           (:eq     (make-hash-table :test #'eq))
                           (:eql    (make-hash-table :test #'eql))
                           (:equal  (make-hash-table :test #'equal))
                           (:equalp (make-hash-table :test #'equalp)))
        do
          (when (eql #\} (peek-char t stream t nil t))
            (read-char stream t nil t)
            (loop-finish))
          (setq key (read stream t nil t))
          (if (eql #\= (peek-char t stream t nil t))
              (read-char stream t nil t)
            (error 'parse-error :stream stream))
          (unless (eql #\> (read-char stream t nil t))
            (error 'parse-error :stream stream))
          (setq value (read stream t nil t))
          (case (peek-char t stream t nil t)
            (#\, (read-char stream t nil t))
            (#\} t)
            (t (error 'parse-error :stream stream)))
        if (eq mapping-type :alist) collect (cons key value) into list else
        if (eq mapping-type :plist) collect key into list
           and collect value into list else
        do (setf (gethash key hashtable) value)
        finally (case mapping-type
                  ((:alist :plist) (return (list 'quote list)))
                  (t (return hashtable))))))

  Now, suppose the above is available in the Common Lisp world.  A file
  that uses this syntax could go like this:

(eval-when (:execute :compile-toplevel)
  (setq *readtable* (copy-readtable))
  (set-macro-character #\{ #'mapping-reader)
  (set-syntax-from-char #\} #\)))

(eval-when (:execute :compile-toplevel)
  (setf (readtable-mapping-type *readtable*) :alist))

(defparameter *roman-alist*
    { "I" => 1,
      "V" => 5,
      "X" => 10,
      "L" => 50,
      "C" => 100,
      "D" => 500,
      "M" => 1000 })

(eval-when (:execute :compile-toplevel)
  (setf (readtable-mapping-type *readtable*) :plist))

(defparameter *roman-plist*
    { "I" => 1,
      "V" => 5,
      "X" => 10,
      "L" => 50,
      "C" => 100,
      "D" => 500,
      "M" => 1000 })

(eval-when (:execute :compile-toplevel)
  (setf (readtable-mapping-type *readtable*) :equal))

(defparameter *roman-hash*
    { "I" => 1,
      "V" => 5,
      "X" => 10,
      "L" => 50,
      "C" => 100,
      "D" => 500,
      "M" => 1000 })

  I chose this design because I figured that it would be annoying to change
  the data if the access functions would need to change and that it would
  be more convenient to specify this via a readtable-local setting than add
  a lot more syntax for it.  If you have support for the in-syntaax form
  and named readtables, creating a named readtable to invoke this syntax
  would obviously be the best solution.

  Now, if you want other kinds of things to go on within { }, it is not a
  lot of trouble to build a parser by hand, provided you are not a moron
  and create syntaxes the like of C++ or some other horrible monstrosity.

  Creating a writer for alists, plists, and hashtables that write data in
  this syntax is left as an exercise for the reader.

  Copyright notice: Copyright © 2002 Erik Naggum.  The code may be used to
  create commercial products without charge or other license provided that
  the author is credited in each source file that uses it or the syntax it
  allows.  Creation of derivative works is permitted under two conditions:
  No rewrites to use if* or not to use loop are allowed, and the author
  must be notified by e-mail at <e...@naggum.net>.  Search engines are
  permitted to index and retrieve this article in perpetuity and present to
  users in either normal text or html-ized form, but no other form of re-
  publication is permitted.  Inclusion of this material in some "cookbook"
  is expressly not permitted.

  Yeah.  They go like this:

  Rule #1: Don't feed the trolls.

  Rule #2: Don't give the trolls the benefit of the doubt.

  Rule #3: Don't let the trolls feed on you.

  Rule #4: Sufficiently advanced ignorance is indistinguishable from trolls.

  Rule #5: Get paid to write books for dummies and permanent newbies.

  You failed.