From ... From: Erik Naggum Subject: Re: newbie Lisp question Date: 2000/03/09 Message-ID: <3161565178384561@naggum.no> X-Deja-AN: 595119451 References: <6dDGOGLUjzLw8Cy92neobKcyZGZV@4ax.com> <87ya7t13i3.fsf@orion.dent.isdn.cs.tu-berlin.de> <38C7C1E0.B0BE1FF1@fisec.com> mail-copies-to: never Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 952601210 26647 195.0.192.66 (9 Mar 2000 11:26:50 GMT) Organization: Naggum Software; vox: +47 8800 8879; fax: +47 8800 8601; http://www.naggum.no User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5 Mime-Version: 1.0 NNTP-Posting-Date: 9 Mar 2000 11:26:50 GMT Newsgroups: comp.lang.lisp * Robert Monfera | 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