"FU????"

*(DEFUN FU (&REST XS) (CONCATENATE 'STRING "FU" XS))
FU

* (SETQ FU "U")
"U"

* (FU FU FU FU FU)
"FU????"


I do not understand LISP.

1

OK, so this works: (DEFUN FU (&REST xs) (apply 'CONCATENATE 'STRING "FU" xs))

2

I still don't think I understand LISP.

>>1
(DEFUN FU (&REST XS) (CONCATENATE 'STRING "FU" XS))
Defines a function FU in the current package. FU takes a variable number of arguments, those arguments are consed up in a list XS, and that list is used as an argument to [/m]CONCATENATE[/m]. Valid arguments could be characters like:
(FU #\U #\U \#!);=> "FUUU!"
(SETQ FU "U")
This is actually an undefined operation at the toplevel, but in general, it will set the FU's symbol's (global) value, so equivalent to (set 'fu "U") or (setf (symbol-value 'fu) "U"). The tricky part here is that in general you'd want to use DEFVAR or DEFPARAMETER which does the same thing, but also proclaims the symbol special (of course, it's also bad style to not use earmuff's when naming globally special symbols, so it should be *fu*). Most implementations will just set the SYMBOL-VALUE, however some (CMUCL?) will also proclaim the symbol special, which can have negative consequences like not being able to declare  variables named after this symbol lexically(since it's proclaim special).
tl;dr: Don't do global SETQ's unless you know what your implementation does, instead use forms which describe your intent EXACTLY (such as a set of SYMBOL-VALUE or aDEFVAR/DEFPARAMETER, which show the intent and no implementation will behave differently here). It should also be noted that some saner implementations like SBCL will warn you if you do a global setq, saying that the variable is undefined (and just perform a set on SYMBOL-VALUE, no special proclamation).

* (FU FU FU FU FU)
Calls function FU with 4 arguments(each being the value of the symbol FU, which is "U" in this case). If symbol FU had the value #\! (or some other character), this call would make sense, and the result would be "FU!!!!", however in your case, FU is a string, and doing CONCATENATE of a character and a string does not work, it's a type-error. Most implementations would signal type-error here. Strangely yours doesn't and it treats those string pointers as unicode characters or something? I have no idea if such behaviour is standards compliant or not, but I'm too lazy to open up Hyperspec and look this up.

>>2
(apply #'concatenate 'string "FU" xs) makes more sense, as now you can specify strings as arguments to your function.
>>3
That code just calls concatenate with 'string, "FU", and the rest of the arguments which were passed to the FU function, so if you passed a bunch of strings, you'd just call concatenate with those strings and expect a new string to be returned.

Another possibility would be that your implementation tries to coerce a string to a character, and instead of signaling an error, it converts it to some unprintable character or #\?, try and see if (coerce "some string" 'character) returns #\?
I could speculate more, but in short, your code invokes undefined behaviour twice, and saner implementations should signal a (style) warning on the first one, and possibly an error on the second, however it seems your implementation skimps on that warning and doesn't signal the error either.

Now I'm actually curious what implementation behaves this strangely. I've tried it on SBCL, CLISP and CCL, and they all signal a type-error like they're supposed to.

7
Allego CL.

Maybe it represents strings as lists, and tries to print a list of strings as a list of characters?

>>8
Somehow I doubt it represents strings as lists of characters(strings are usually represented as simple-array/vector's of characters, and smart implementations store such arrays unboxed, which means something akin to an ASCII or UNICODE string with a tag and a size). ACL is considered a reasonable implementation, so this is quite the strange behaviour IMO. Maybe I'll try setting up a trial on my box later to confirm this behaviour. Did you try coercing a random string to a character, does it return #\? ... Another possibility would be high optimization settings leading to the compiled code ommiting typechecking of the strings and just treating them as character, but speculating is somewhat pointless. The easiest way to find out what's really going on is to get ACL, compile these functions and disassemble them to track down the behaviour.

>>8
Okay, I've looked at ACL quickly, it seems a compiler macro is used when (concatenate 'string ...) is called and it translate to an internal function called EXCL::CONCAT-TO-SSTRING_2OP, which concatenates any 2 sequences to a string. I've done a bit of experimenting, and it seems these question marks are actually unprintable characters which result by treating objects as characters regardless of their actual type(typechecking is skipped, I'm assuming this is due to excessive optimization settings):

(EXCL::CONCAT-TO-SSTRING_2OP (list "x") (vector #\a #\b (list 'c))
)
"?ab?"
(aref * 0)
#\?
(char-code *)
13014
(char-code (aref *** 3))
49694
I could do more investigating here, but there's two ways to treat this:
1) Accept that you've invoked undefined behaviour and just don't write code like that OR
2) Bother your vendor (Franz which makes ACL) to fix this bug for you, which they would probably either fix by compiling their code with more safe settings which do proper typechecking, or they'll tell you to buy their product if you want real support. I don't know which it would be. I tend to stick to free Lisps(like SBCL,CCL,CMUCL, CLISP,ABCL,...) as they're of decent quality and if something goes wrong, I can fix stuff myself without having to rely on commercial support, however some people (like real companies) do prefer commercial support for obvious reasons.

FUUUUUUUUUUUUUUUUUUUU

POWIEDŹCIE KURWA CO ZNACZY 'FUUUUUUU' ALBO WAS TEŻ ZAJEBIE!

>>12
http://i.imgur.com/NSrRs.jpg

my other CDR is a CAR