Subject: Re: Newbie Q: Methods & Packages
From: Erik Naggum <erik@naggum.no>
Date: 1999/09/05
Newsgroups: comp.lang.lisp
Message-ID: <3145544479675346@naggum.no>

* Andrew Cooke
| - first, there doesn't seem to be anything in the package system that
| decides which namespace (function, variable, whatever - I remember
| something saying there were 7) within a particular package a symbol
| refers to.

  huh?  a symbol is a name of something.  a string of letters and whatever
  is the external form of that name.  when read by the Lisp reader, the
  package looks for a symbol with the name with that external form in the
  specified (or current) package, and that symbol is used.  at no point in
  this process does the "something" the symbol names enter the picture.
  however, the "something" is referenced by the user of the symbol, and if
  that is SYMBOL-VALUE, you get the variable, if it is SYMBOL-FUNCTION, it
  is the functional value, if it is FIND-CLASS, it is the class, if it is
  THROW, it it the CATCH tag with that name, but you might as well consider
  the possibility of an ASSOC list or a HASH-TABLE with a symbol as key, so
  counting namespaces is silly.

| Does that mean that if I have a constant and a function with the same
| name (it's OK, I've read a Lisp style guide and I have some common sense,
| but out of curiousity...) both are visible if declared external?

  yes.  there's nothing wrong with using the same name for several things.
  after all, that's the very idea!  it is also far better than trying to
  invent two names for the same thing.  e.g., if you have a VOTE class,
  would you want to call a function CAST-VOTE instead of just VOTE?

| Is there no way of controlling this?

  no.  the key is to understand it.  if you want some property of a symbol
  to be exportable and another not, you can either document it and expect
  people to read the documentation, or you can call it something else.

| - second, my confused reference to circularity in the original post was
| because I couldn't see how methods with the same interface were linked.
| After looking at defgeneric am I right in thinking that a generic
| function is "the same kind of thing" as the list of methods that a class
| has in a language like C++/Java (ie some kind of look-up table that
| organises the methods by specificity etc)?

  no.  skip this comparison competely until you understand it.  actively
  forget C++/Java and don't think about their way of doing things at all
  while you try to deal with CLOS methods.  it's like trying to understand
  the French "ne pas" and trying to make it match "do not" in English.  it
  works up to a point, but it doesn't actually work that way.

| (this then explains why people suggested using defgeneric in a separate
| package to define the structure)

  huh?  where did you find this suggestion?

| Sorry that I keep trying to link things to unrelated languages - I
| realise they are different beasts, I'm just trying to get my bearings.

  you will fail to relate to other languages until you have understood each
  one by itself.  you won't understand one language until you have ceased
  to want to relate to others.  different languages need to be understood
  on their own terms.  and more than anything else, make sure that you wait
  until you have _good_ reason to think two similar properties of two
  different languages are the same -- more often than not, they are very
  different, yet look deceptively the same.  take symbols in Scheme and CL,
  for instance.

#:Erik
-- 
  save the children: just say NO to sex with pro-lifers