Subject: Re: newbie Lisp question
From: Erik Naggum <erik@naggum.no>
Date: 2000/03/09
Newsgroups: comp.lang.lisp
Message-ID: <3161565178384561@naggum.no>

* Robert Monfera <monfera@fisec.com>
| When is it encouraged to put together symbol names though?  By default,
| DEFSTRUCT produces a host of functions with glued names, but it isn't
| common in CL.
| 
| Is it an indication that automagical function (or whatever) creation with
| glued names is rarely encouraged?  Any examples when it's the best way of
| achieving something other than system integration?

  recently, I wrote that making some concepts hard to express didn't cause
  people to suffer from having to express them, but made the concepts
  suffer because they would be underutilized.  humans, falling prey to the
  siren song of convenience, will always think this way.  therefore, the
  languages we use must make smart concepts convenient to express and dumb
  concepts inconvenient to express.  the natural tendency is the opposite.

(intern (concatenate 'string (symbol-name #:make-) (symbol-name symbol))
        (symbol-package symbol))

  will return a new symbol prefixed with "make-" in the same package as the
  symbol without the prefix (thanks for that careful bit, Pierre), but is
  this hard to read?  is it a lot of "internal stuff" that people shouldn't
  ned to worry about?  I dont' think so.  I think this is the smallest you
  can do, short of writing a function specifically to glue symbol names
  that does all this, but think about its hypothetical interface for a
  second: it would naturally want two symbols, but which one is prefix and
  which one is suffix?  (resist the temptation to search for the hyphen!)
  so either you get two functions or you supply the package separately, or
  perhaps you think you could supply one string and one symbol, but either
  way, you have caused the user of your function to exercise a lot more
  brainpower on your symbol-glue function than on the expression above,
  which should be a no-brainer for an experienced Common Lisp programmer in
  a way the symbol-glue functions wouldn't be because they are infrequently
  used.  and if they aren't infrequently used, we're back to Robert's
  question: should we encourage this?  I don't think we should, either, so
  it would be bad if it were too convenient to do it.

  FORMAT is clearly in the "too convenient" camp, since it makes doing it
  the wrong way so convenient, and burdens the user with case conversion
  issues in the reader and the printer at the same time.

  but consider a More Common Lisp that does no case conversion in the
  reader or the printer (which is more common than doing it, hence my
  punnish name), with what-you-see-is-what-you-get symbol names:

(intern (format nil "make-~a" symbol) (symbol-package symbol))

  consider all the idiomatic stuff we got rid of: either an uninterned or
  keyword symbol just to get the symbol name right or an upper-case prefix
  string literal, and extracting the symbol-name part.  this idiomatic
  burden is a no-brainer to an experienced Common Lisp programmer, but
  _acquiring_ the expertise so it becomes a no-brainer is not effortless at
  all, and probably involves struggling and lots of confusion until the
  full ramifications of Common Lisp's attitude to case are internalized.

  so instead of encouraging the convenient creation of symbols, we have an
  elaborate scheme to discourage people from looking at symbol names and
  only use the symbols as symbols, but this works directly against the work
  needed to acquire the expertise in using them correctly!  since symbols
  is very powerful abstraction mechanism, and case conversion is also a
  very powerful mechanism in human communication (it has definite value,
  but by informed choice, not default), we've forced ourselves out on a
  limb every time we have to deal with them, and some are worrying that any
  proposal to fix this is akin to cutting the limb on the dumb side.  this
  is a case of making a smart concept cumbersome to express, and forces us
  to consider more convenient options merely for the sake of convenience --
  it should have been _sufficiently_ convenient to begin with not to have
  to worry about case conversion details.

  let's find a way to make Common Lisp work with readtable-case :preserve
  and lower-case symbol names, so what-you-see-is-what-you-get-ness is also
  preserved for experienced and novice programmer alike, and we can do
  smart stuff without having to be too clever, too.

#:Erik