freenode/#lisp - IRC Chatlog
Search
3:29:27
beach
phoe: By the way, I can prepare a presentation for a week from tomorrow (or later) in case you have no other candidates.
8:43:16
pve
but it's not clear to me why (shadow 'array) leads to that weird behaviour, because reading the hyperspec entry for shadow, I get the impression that it should work
8:47:03
pve
are all the references to the symbol "ARRAY" stored "in one place" in the fasl, so that when the fasl is loaded, LOAD sees 'array (i.e. CL:ARRAY, before shadowing) and then assumes all ARRAY symbols in the fasl are the same?
8:49:42
beach
The symbol ARRAY already exists in the cl-user package, so it is going to use the pre-existing symbol.
8:52:13
beach
The name is a designator for a string, so only the name of the symbol matters if you give it a symbol.
8:57:56
pve
but why then, does it print COMMON-LISP-USER::ARRAY if I load-compile from slime (C-c C-k)?
9:17:36
pve
beach: ok, so the discrepancy must have been caused by something I was loading into my slime session (need to investigate that), because if I compile and load my example from the shell without loading any init files or libraries it prints COMMON-LISP-USER::ARRAY in both cases
9:18:39
phoe
I mean, PACKAGE-NAME SYMBOL-PACKAGE should *not* return CL-USER in this case because ARRAY is imported from CL
9:21:11
no-defun-allowed
The two (or three?) means of compiling and/or loading that code appear to do different things though.
9:22:05
phoe
"For each such name, if a corresponding symbol is not present in package (directly, not by inheritance), then a corresponding symbol is created with that name, and inserted into package as an internal symbol."
9:27:06
White_Flame
hmm, nevermind, I think that the eval-when should guarantee the shadowing before the format expression is read
9:28:22
White_Flame
this is why it's important to have a separate package.lisp to set everything up in a separate file
9:29:22
phoe
the SHADOW call should be a part of DEFPACKAGE, that's my only real gripe with this code
9:31:08
pve
my original problem was probably caused by some package-fu I'm doing in the project I'm working on
10:09:02
beach
Am I reading the dictionary entry for DEFCONSTANT right in that the constant is not defined at compile time?
10:09:46
beach
It says that the compiler must recognize that the name names a constant variable, but not that the value is available at compile time.
10:11:14
phoe
"An implementation may choose to evaluate the value-form at compile time, load time, or both."
10:11:43
phoe
if the value is allowed to be available only at load time, then it may *not* be available at compile time
10:12:24
phoe
it is allowed not to be available at compile-time, BUT it also says that this behavior is implementation-dependent
10:12:46
phoe
so as an implementer you can do e.g. what SBCL does which is to EVAL-ALWAYS %DEFCONSTANT
10:13:15
phoe
but it seems that as a user you cannot really depend on the constant being available at compile time.
10:13:19
beach
Right, so a file containing (defconstant bla ...) (defun foo (..) bla) may or may not work.
10:14:21
phoe
"If a defconstant form appears as a top level form, the compiler must recognize that name names a constant variable."
10:16:39
phoe
but this way is trivial to implement and preserves language semantics, since constant redefinition is undefined
10:17:31
beach
I would tend to signal an error, or at least a warning, but I can't see whether it would be allowed to do that.
10:20:01
beach
That the compiler did not have access to the value so it had to compile it as an access to a variable defined at run time.
10:21:50
beach
That the compiler did not have access to the VALUE at compile time, so it could not compile the code as if BLA were the constant that it is defined to be. And instead it had to compile it as an access to a variable at run time, thereby degrading performance.
10:23:03
phoe
I think I partially understand... why would it not have access to VALUE at compile-time? an implementation is allowed to evaluate the DEFCONSTANT value at compile-time, so signaling a warning in that case sounds like a making bugticket for your own self
10:23:38
phoe
and if user code is built in a way that doesn't make it possible, *then* it's a bug on the user side
10:23:43
beach
Because the implementation chose not to evaluate the initialization at compile time, or at least chose to not store that value for compile-time availability.
10:24:11
phoe
but then it's allowed to do that, so I guess that the only warning it can signal would be a STYLE-WARNING
10:28:05
iissaacc
i redefined a method from a library in some code, and I don't get any warnings and the redefinition works as expected in a REPL session. But when I tested it in a fresh REPL session the old behaviour associated with that method happens, i.e the redefinition doesnt seem to have taken effect. Does anyone know why this could be?
10:29:24
phoe
but it is also allowed to *silently* create a brand new generic function BAR:QUUX and then define a method on this
10:30:09
iissaacc
right, so my redefinition is actually creating a new generic function in my package
10:30:49
phoe
that's why I wish there was a toggle to cause DEFMETHOD to error if the respective generic function is not found.
10:33:58
phoe
one of the few cases where Lisp is allowed to completely silently do The Wrong Thing™ and the blame is fully on the programmer for not checking their symbols.
10:35:11
iissaacc
what would be cool would be being able to inspect function definitions, but afaik this isnt possible because things get compiled straight away