libera/commonlisp - IRC Chatlog
Search
19:34:09
NotThatRPG
If one compiles a file with a defmacro in it, and then loads the fasl, does that cause SBCL to raise a style-warning to say that you are redefining the macro?
19:35:11
NotThatRPG
I'm seeing a bunch of unexpected redefinition style warnings in random-state that surprise me.
19:41:26
NotThatRPG
Actually, I wonder if this could be related to using quickload with :silent nil and :verbose t. Could that be revealing warnings and style-warnings that would otherwise be simply quashed by the compiler?
20:14:11
NotThatRPG
What I'm doing is trying to check for a clean build and I'm getting messages I don't expect https://pastebin.com/RJZ3PFzs
20:37:11
jackdaniel
NotThatRPG: this looks like a serious issue I sometimes spot (not a false positive)
20:37:36
jackdaniel
consider (defun foo () (bar ...)) (defmacro bar ...) -- bar in this case is assumed to be a function when foo is defined
20:38:15
jackdaniel
in other words, this looks as if you were using macros before defining them (and that is really really bad)
20:38:17
NotThatRPG
I looked at the files that are being loaded and I do not see the macros being *invoked* in those files, only being defined.
20:39:01
jackdaniel
if the function foo is defined in the file a.lisp and it calls to BAR that is not defined yet, then bar is assumed to be a function
20:39:28
jackdaniel
and when the bar is defined as a macro then the system complains with this very style warning
20:39:30
NotThatRPG
So I wonder if SBCL is throwing out warnings that are *later* quashed by with-compilation-unit, but before they get quashed, I am picking them up.
20:39:44
jackdaniel
as I've said I didn't see the code itself, just that symptoms ideally reflect this failcase
20:41:21
minion
Filystyn: look at pcl: pcl-book: "Practical Common Lisp", an introduction to Common Lisp by Peter Seibel, available at http://www.gigamonkeys.com/book/ and in dead-tree form from Apress (as of 11 April 2005).
20:41:54
NotThatRPG
@jackdaniel: For example, the warning in there about INCFMOD: it's defined in the file toolkit.lisp and only used in rc4.lisp and rc4.lisp is DEFINITELY after toolkit.lisp in a serial asdf system definition
20:42:40
jackdaniel
generally the goto place to see the common lisp standard is so called "hyperspec" available here: http://www.lispworks.com/documentation/HyperSpec/Front/index.htm
20:42:59
NotThatRPG
@jackdaniel: I remember Fare saying something about SBCL throwing a bunch of these style warnings, collecting them up, and then later either squashing them or emitting them on exit from WITH-COMPILATION-UNIT.
20:43:56
NotThatRPG
Fare did something like what I am describing in his WITH-DEFERRED-WARNINGS patch for ASDF.
20:44:26
jackdaniel
Filystyn: perhaps clisp has its own manual (it probably has!); that said sbcl is usually goto implementation for learing because it is better supported by libraries
20:44:58
jackdaniel
so in addition to the standard (either via clhs or what semz linked), you may see sbcl manual http://sbcl.org/manual/index.html
20:45:41
jackdaniel
NotThatRPG: I have not encountered such warnings outside the scenario I've mentioned
20:45:47
NotThatRPG
@jackdaniel: But I can't imagine how I could be grabbing up these warnings before SBCL could screen them, unless SBCL for some reason collects them and only later filters them....
20:46:10
jackdaniel
I can imagine that if the macro is first defined in *.lisp file and then the definition is loaded from *.fasl file, since the source location changes, the warning could be signaled
20:48:02
pjb
jackdaniel: compile-file should only have compilation-time side effects, and only in the compilation environment. Loading the generated fasl file later shouldn't collide, either because load-time and run-time side effects shouldn't collide with compilation-time side effects, or because the previous compilation environment is disjoint from the run-time environment.
20:48:33
pjb
jackdaniel: of course, it all depends on the implementation, but it is expected that (load (compile-file "foo.lisp")) should not signal such errors.
20:52:54
jackdaniel
makes sense; either way (as noted) I've only seen such style warning if the macro was used before it was defined
21:11:18
Filystyn
and when I compile-file the loading process is faste rbecause the compilation is by then done
21:15:44
edwlan[m]
That was a bit aggressive, all I meant is that whether you implement a language with a compiler or an interpreter is an implementation decision, not a feature of a language
21:22:44
pjb
edwlan[m]: CL has scripting aspect. If you define scripting as having program chunks modify the semantics of the rest of the script.
21:24:37
pjb
Most other languages have a semantic that is 100% hardwired and defined by having a compilation phase. Which is not the case of scripting languages, such as shell, perl, ruby, lisp, etc.
21:25:40
pjb
edwlan[m]: that said, when you use things like cl-launch, which compiles "script", you lose this scripting aspect. Which is the reason why I don't use cl-launch, but instead compile all my "scripts" into a single lisp image, and dispatch on argv[0].
21:56:02
jcowan
There exist C repls which provide (IIUC) what you are calling scripting semantics for C.