Tim Bradshaw  <t...@cley.com> wrote:

or

(setf (readtable-case *readtable*) :invert)

The latter is useful if you don't want to CRY OUT THE STANDARD
SYMBOL NAMES:

* (symbol-name 'foo)

"FOO"
* (symbol-name 'FOO)

"foo"
* (symbol-name 'Foo)

"Foo"

What would you refer to as original name in the case:

(mapcar #'symbol-original-name (list 'foo 'Foo 'FOO))

in your example, if you wanted to map 'foo, 'Foo and 'FOO to the
same symbol objects?

Kind regards,

[...]

I have no idea whether Tim thought the idea had any merit. I'm just glad
he and you got the point.

The answer to your example would be ("FOO" "FOO" "FOO"). (list 'foo 'Foo
'FOO) is first evaluated. "foo" is first associated with the symbol FOO.
Then this is replaced with "Foo". Finally "FOO" is associated with the
symbol FOO. Mapping symbol-original-name onto a list of the same symbols
would lead to the same string being returned each time.

This would break all kinds of identity as (list (symbol-original-name
'foo) (symbol-original-name 'Foo) (symbol-original-name 'FOO)) would
return ("foo" "Foo" "FOO") compared to the mapcar example.

Another problem is that since case sensitive modes generate different
symbols then your example would generate ("foo" "Foo" "FOO") whenever a
case sensitive mode was in use.

So (mapcar #'symbol-original-name (list 'foo 'Foo 'FOO)) would generate
("foo" "foo" "foo") because "foo" was first associated with the symbol
name FOO.

(list (symbol-original-name 'foo) (symbol-original-name 'Foo)
(symbol-original-name 'FOO)) would also generate ("foo" "foo" "foo")
because "foo" was associated with the symbol FOO the first time it was
read by the Lisp Reader.

There would still be a difference with case senstive reader modes--but
there is always a difference when symbols have a different case in case
sensitive reader modes.

The idea would seem to require the string information for each unique
symbol to be retained forever (unless explicitly destroyed).

So (mapcar #'symbol-original-name (list 'foo 'Foo 'FOO)) would generate
("foo" "foo" "foo") because "foo" was first associated with the symbol
name FOO.

(list (symbol-original-name 'foo) (symbol-original-name 'Foo)
(symbol-original-name 'FOO)) would also generate ("foo" "foo" "foo")
because "foo" was associated with the symbol FOO the first time it was
read by the Lisp Reader.

There would still be a difference with case sensitive reader modes--but
there is always a difference in such modes when symbols differ by case.
Plus the functionality would be pointless.

The idea would seem to require the string information for each unique
symbol to be retained forever (unless explicitly destroyed).

Anyway, it's clear that you didn't grok Lisp, if you still think
that Lisp sticks you with one way of expressing yourself that
you ``have to'' follow.

In the end, everyone deserves the tool they end up with.

It looks like you are cutting and pasting Lisp trivia from some
document to make it seem as if you actually know the language,
so that you could write more subtle trolls.

I can do the same; I know next to nothing about, say, Eiffel, but I
can cut and paste trivia from FAQ's, web pages other sources. Then
go to comp.lang.eiffel and claim that I spent years using
Eiffel, and have always wanted a language with these features.
Oh, but I couldn't stand some little detail, so I switched
to Perl and life was perfect after that! :)

  f(a[++i], b + c/d)

which might translate to

  (f (aref a (incf i)) b (/ c d))

  What would happen to (defstruct foo ...)?  Would you have MAKE-foo or
  make-foo?

  I have spent many hours working on various ways to make a case-preserving,
  lower-case Common Lisp work according to the standard, but I find myself
  stumped by macros that generate symbols by "concatenating" input symbols
  with symbols of its own making.  I have come to believe that this should be
  avoided at all cost, including writing out the symbols created by defstruct
  in full.  You see, what I want is for `intern´ and `symbol-name´ to use
  lower-case symbol names when I throw a switch, but if I also want a case-
  preserving reader, what comes out of defstruct is probably MAKE-foo.  To
  make this work, macros that call intern need to capture the state of the
  flag that modifies how `intern´ and friends work so that they would do the
  right thing as the macro writer intended when it was compiled.  This is
  pretty messy, so I have not taken then idea any further.

| The idea would seem to require the string information for each unique
| symbol to be retained forever (unless explicitly destroyed).

  Why do you think this is not how things work today?

--
Erik Naggum, Oslo, Norway

Cheers

What is harder to parse for the computer is harder for the human.
There are no algorithmic shortcuts for parsing that are available
to the human brain. Sorting out associativity and precedence in
a an expression takes work, whether you are man or machine.

Note that neither Lisp nor C is easy to read for a human without
indentation. We actually read indentation as the major clue to the
program's structure. Formatting is a big deal. There is no consistent
way to format all of the constructs of C.

I cringe every time I have to split a long for(;;) across multiple
lines. Or a long expression.

In Lisp we can write nice things like:

(or (and (and (condition1 ...)
              (or (condition2 ...)
                  (not (condition3 ...))))
         (not (or condition4 condition5)))
    (and condition6 condition7 condition8))

Now what do we do in C to format it sanely? Okay, the major
constituent
is or, but in infix, that will land in the middle of the long
expression
somewhere. Instead the expression begins with the leftmost node.

((condition1(...) && (condition2(...) || !condition3(...))
&& !(condition4 || condition5)) || condition6 && condition7 &&
condition8

How can we break that in a sane way? In the formatted Lisp version,
I can visually check the balance of the parentheses thanks to the
canonical formatting. I'd like it to be obvious that the expression
has two major constituents coupled by ||.

In Lisp, the frustration is gone. You just follow a simple algorithm
that an idiot can learn in five minutes, and your expression is
formatted sanely.

I don't follow your claim that a wider diversity (C has a 90 member
character set which uses nearly all of the symbols in the ASCII
character set for some kind of punctuation, with the exception of
@ and $) leads to improved readability. More symbols just means more
memorizing. There has to be some optimal alphabet size for human
readability; 90 characters is probably too much, whereas two symbols
(binary code) is too little.

    File reader (...)

        File writer (...)

  This, is, a, (curious), position, to, hold.  The, amount, of, [punctuation],
  in, (normal, writing), is, pretty, low, and, { ensures; }, that, punctuation,
  has, meaning; [distinct] from the normal { flow; } of the language.  In, C,
  the, [punctuation], is, so, { heavy }, that, the, reader, [must], pay, acute,
  { attention; }, to, it, even, though, it, is, (largely), meaningless.  This,
  is, not, [easier], to, read, as, this, paragraph, should, be, have, [shown],
  you.  When, an, { assortment; }, of, punctuation, is, made, into, background,
  { noise; }, the, result: is, that; people, become, [hypersensitized], to();
  changes, in, the, punctuation, they, have, to, (read && would), reject, any,
  languages, with, a, simpler, syntax && other, punctuation, to, ignore.

  If you have become used to C, the empirical evidence is that you have a very
  hard time reading languages with other syntaxes.  This is prima facie
  evidence that the C syntax family requires an expensive learning process and
  constant refreshes.  I found myself frustrated when I tried to write a
  couple hundred lines of C recently to exercise some Linux features and make
  them available to Common Lisp (particularly the dnotify facility) and all
  the keyboarding was just /painful/ compared to the swift typing that I
  usually achieve with Common Lisp and English.

| My example was meant to show that the scope introduced when a variable is
| declared can be "hidden" in C/C++, which makes it easier to read.

  Where /did/ you get the notion that "easier to read" is universalizable and
  one-dimensional to boot?  Sheesh, you prove that you have no clue what you
  talk about when you treat "easier to read" as a metric that is unrelated to
  experience.

| Your examples on the type of syntax transformations one can do in LISP,
| however, don't contradict my point, as far as I can see.

  What /would/ contradict your point?  It seems to be remarkably resilient,
  but mainly in your own view.

--
Erik Naggum, Oslo, Norway

I would just like to say that I find neither C nor Lisp
hard to read when properly formatted. I didn't find
Pascal hard to read when I first started to learn programming.

I find Lisp code harder to read though, but the reason for that
is not that I find it hard to see the structure of the program,
but rather that the idioms and solutions used are different from
what I am used to. One "problem" is that recursion is often
used and I do not have that much training in reading recursive
functions. But my guess is that this is a trivial problem which
will disappear with time :)

So, I speculate that this might be Zivs problem. Not that the
structure of the program is hard to read, but the use of
unfamiliar constructs requires some extra brainpower. I might
be totally wrong and I apologize if that is the case.

--
Thomas.

  Heh.  Probably not.  Recursion can be extremely hard to understand if you
  look too closely at it.  E.g., the simple factorial function is hard to read
  if you try to think about what actually happens to 10! and you try to work
  out the recursive calls in your head.  What you need to do with recursive
  functions is figure out the problem as composed of sub-problems that are
  just like itself.  For instance, an iterative tree traversal function will
  do a lot of work to remember past nodes, while a recursive version can work
  on a single node at a time and completely hide the fact that the call stack
  holds all the information that the iterative version would have to allocate
  explicit memory to hold.  So-called tail-recursive problems are only simple
  decompositions into itself without any new information in each step and it
  makes little sense to use this idiom even when you want to train yourself to
  think recursively, because the whole point with recursive functions is that
  the call stack contains useful information and tail-recursive functions only
  use the function call paradigm to express iteration.

--
Erik Naggum, Oslo, Norway

I don't really have a hard time with any of the syntaxes, although ML
and Haskell can give me a headache at times.

   "Lisp syntax is *truly* hard," don't you think?

is certainly easier to read than

   quote capitalize lisp syntax is emphasize truly
   unemphasize hard comma unquote don apostrophe t you
   think query

I think the Lisp syntax is plenty readable myself, but
I also don't think its syntax is really as terribly
minimal as it could be.  It uses parens very
effectively to identify groups and subgroups, and it
uses keywords at the "car" position where other
languages wantonly use up dedicated characters --
making for less diversity in user-chosen symbols!
Once you start getting a feel for the specialness of
keywords, you get back the diversity of syntax that you
may have initially felt was missing.

What are the better alternatives? Enquiring minds want to know! ;-)

TIA. Cheers.

The easily enumerable part is loaded salary costs (salary + overhead
for offices, machines, etc).  Producing ANSI CL [1986 to 1995] took a
bit over $400K, if I recall right.

The costs of a zillion people traveling, of the timeline being years
long, of people sitting at desks answering email and reviewing
hardcopy, etc., are hard to measure.  I'd say probably that comes
close to doubling it...

None of this counts the cost of the community "accepting" the changes,
meaning of each user reading new documentation, of vendors making and
testing new implementations, of deployed products looking for and perhaps
even debugging incompatibilities (this cost may be present even if the
incompatibilities won't be there, since one has to at least check).
An analyst report I saw at Symbolics once for a fairly modest set of
incompatible changes (that is, small in number but pervasive in nature)
showed that target customers often pay upwards (sometimes way upwards)
of $10K per customer to accept such releases...  This aggregates to ENORMOUS
community cost before any new benefit is realized.  

Before making changes, one wants to believe they are going to overcome
these costs.

Layered standards are another matter, but require no change to the existing
core.

  Some years ago, I spent considerable time playing with the reader in order
  to learn how it worked and how much I could change it without removing the
  Lisp feel.  I modified the list reader to post-process them such that, e.g.,
  `(x <- y)´ and `(y -> x)´ would transform to `(setf x y)´, reintroduced the
  `=>´ from Scheme's `cond´ to pass the value of the conditional to the body,
  got rid of `aref´ with `[array index ...]´ and sundry other minor changes.
  Most of these were dead ends, but I still kind of like the infix -> and <-.
  (It looks even better with an assortment of Unicode arrows.)

| If Lisp keywords were not written as words fashioned from an alphabet but as
| dedicated symbols (say as Japanese kanji), with all other words being
| alphabet-based, then the wrench of going from C to Lisp may not be felt as
| much.

  You can do an amazing amount of syntactic harm with Unicode.  I have all
  sorts of cute symbols available on my keyboard, now.  Real less-than-or-equal
  signs, open and filled triangles for brackets and bullets and open and filled
  circles and squares for bullets, and a little greek and, um.  Syntactic harm.

--
Erik Naggum, Oslo, Norway

  * (defstruct foo)
  foo
  * (make-foo)
  #S(foo)
  * (symbol-name 'make-foo)
  "MAKE-foo"
  * (eql 'make-foo '|make-foo|)
  NIL

This wouldn't be backwards-compatible, but it would only break for
ugly code like defstruct.  Which is probably too high of a price to
pay, but that's too bad because that looks like very nice case semantics.