Put me out of my misery

I've been studying programming for 3 fucking years and I STILL don't know what 'foobar' is. FUCK.

Some kind of Windows software. I think it plays audio. There's a whole cult devoted to it.

it's used in Java as the default names of variables. Because gosling thought it'd be funny as foobar is a homonym for the military acronym ``FUBAR''

>>1
your gonna loose your head once you find out there is a ˝baz˝ too.

>>4
Go away.

>>3
It's used FUCKING EVERYWHERE

>>5
no

>>1
There is an RFC explaining the etymology of foo, go look it up (or you could use wikipedia)

I pity the foo who bars my baz.

>>9
D'aww. No love for quux?

>>10
Only "the Great Quux"

FOOBAR MY ANUS

>>10
Quuux is superior.

When I'm not using a language in which they are keywords, I use ``car'', ``cdr'', ``cadr'', ``cdaddr'', &c. for metasyntactic variables.

>>14
You silly bitch.

>>14
So everything except CL then?

>>16
technically you can rebind those in CL as well

>>17
http://www.lispworks.com/documentation/HyperSpec/Body/11_abab.htm

>>18
That's only for the CL package.

Usually you never alter the CL package(altough, many implementations let you), you make your own package and you're free to have any symbols you want named whatever you want them. Most commonly you use the COMMON-LISP package, but if you want, you can always shadow those symbols, or not import CL at all (if you need to use stuff from CL, just use the full symbol name, which includes the package name). So >>17 would be right if he said, "shadow" or "don't import them in the first place". You can also shadow them in CL-USER, which is the default package nickname for COMMON-LISP-USER, which is the default value of *package*. CL-USER typically uses CL and a bunch of common implementation-specific packages.

>>19
I'm no expert on CL packages, but as I read LISP-SYMBOL-REDEFINITION¹ you need to have every name exported by COMMON-LISP imported at every point of your program because a macro might decide to make use of something in its expansion without the full name.

¹ http://www.lispworks.com/documentation/HyperSpec/Issues/iss214_w.htm

>>20
That depends on when the macro is read. I've seen people redefine or define new packages with completly new macros (and also did it myself many times), and never had any problems with it.


When a macro's code is read, its code is transformed into a list object, and each symbol in that nested list points not to the name, but the effective symbol.

The problem does exist, but it's specific to your own macros, and if you decide to redefine something for your own package, it's your responsibility to make adjustments to your own code for that to work.

*completly new symbols

Here's an example that shows how this is supposed to work (symbols used in macros point to the object they represented at the time the macro was read):


;; Define an empty package which contains no symbols, nor does it import anything
(defpackage emptyness)
;; Set the current *package* for compile, load, execute-times.
(in-package #:emptyness)

(cl:dotimes (i 5)
  (cl:princ i)) ;=> prints 01234

Now, I had SLIME expand it for me:

(COMMON-LISP:DO ((I 0 (COMMON-LISP:1+ I)))
                ((COMMON-LISP:>= I 5) COMMON-LISP:NIL)
  (COMMON-LISP:DECLARE (COMMON-LISP:TYPE COMMON-LISP:UNSIGNED-BYTE I))
  (COMMON-LISP:PRINC I))

; which expands to
(COMMON-LISP:BLOCK COMMON-LISP:NIL
  (COMMON-LISP:LET ((I 0))
    (COMMON-LISP:DECLARE (COMMON-LISP:TYPE COMMON-LISP:UNSIGNED-BYTE I))
    (COMMON-LISP:TAGBODY
       (COMMON-LISP:GO #:G893)
       #:G892
       (COMMON-LISP:TAGBODY (COMMON-LISP:PRINC I))
       (COMMON-LISP:PSETQ I (COMMON-LISP:1+ I))
       #:G893
       (COMMON-LISP:UNLESS (COMMON-LISP:>= I 5) (COMMON-LISP:GO #:G892))
       (COMMON-LISP:RETURN-FROM COMMON-LISP:NIL
         (COMMON-LISP:PROGN COMMON-LISP:NIL)))))
;; which, after more iteration, finally expands to

(COMMON-LISP:BLOCK COMMON-LISP:NIL
  (COMMON-LISP:LET ((I 0))
    (COMMON-LISP:DECLARE (COMMON-LISP:TYPE COMMON-LISP:UNSIGNED-BYTE I))
    (COMMON-LISP:TAGBODY
       (COMMON-LISP:GO #:G893)
       #:G892
       (COMMON-LISP:TAGBODY (COMMON-LISP:PRINC I))
       (COMMON-LISP:LET* ()
         (COMMON-LISP:LET ((#:NEW894 (COMMON-LISP:1+ I)))
           (COMMON-LISP:PROGN (COMMON-LISP:SETQ I #:NEW894) COMMON-LISP:NIL)))
       #:G893
       (COMMON-LISP:IF (COMMON-LISP:>= I 5) COMMON-LISP:NIL
                       (COMMON-LISP:PROGN (COMMON-LISP:GO #:G892)))
       (COMMON-LISP:RETURN-FROM COMMON-LISP:NIL
         (COMMON-LISP:PROGN COMMON-LISP:NIL)))))
As you can see, it runs fine, it expands fine, as the macro is compiled and works with concrete symbols, not package-less symbol names (strings). Of course, if you were to define new macros in this new package, you'll have to qualify the symbols with the proper package name.

26 Name: Anonymous 2010-12-27 23:38

---

Don't change these.

Name:		Email:
Entire Thread Thread List