freenode/#lisp - IRC Chatlog
Search
20:04:13
Xach
Are there any debian experts who might be able to privately help me through some quicklisp build-server setup issues?
20:08:11
_death
makomo: macros are just programs.. a lot of common functionality can be factored into functions, so there's nothing wrong with functions that return parts of an expansion.. you only need to separate macro definition from macro use so you don't need ugly eval-whens
20:08:46
pjb
Just remember to wrap the functions used by the macro at macroexpansion time in a (eval-when (:compile-toplevel) …).
20:09:05
pjb
(or in a different file loaded in the compilation environment (how do you load a file in the compilation environment with asdf?))
20:09:22
makomo
_death: yeah, i understand that, that's not the problem. the problem is that *you* have to write a function that returns ONCE-ONLY's expansion
20:09:35
aeth
If it's a function only usable in one macro, it should be in the same file as the macro unless it's a *very* complicated macro, like the one I use that converts s-expressions to GLSL strings at compile time.
20:11:32
makomo
and there's no way to escape that (assuming the author didn't provide that function that you showed)
20:12:54
_death
makomo: I once pasted some once-only variant, but it only provided parsing of the specs as a function.. https://gist.github.com/death/8551cf20e2bf296455a3e8cf3f3be11b
21:51:57
makomo
well, anyway, this achieves my goal of using ONCE-ONLY directly, without any rewriting or reinventing the macro
23:27:44
oni-on-ion
literally just reading about 'when-bind' and some very similar examples in On Lisp, pp.94 section 7.6
23:33:09
oni-on-ion
sorry it was jackdaniel who posted this article earlier but i just came across it now from the wild. i thought it was somewhat related to ONCE-ONLY that was being discussed here
1:36:13
kristof
I have stumbled onto something quite accidentally that I read about exactly once in an erik naggum flamewar and I would like to know where in the spec this particular behavior is described
1:37:34
kristof
(defvar variable-name) (defun function-name (variable-name) ;;body) will *bind* variable-name to the value
1:39:35
kristof
I just chose to eschew the naming conventions today and immediately discovered why there are naming conventions
1:40:07
Bike
"When used in a proclamation, a special declaration specifier applies to all bindings as well as to all references of the mentioned variables."
1:42:40
aeth
There are so many fun ways to avoid globals. You can create a closure by putting one or more defuns in a top-level let, for instance. Or you could create a macro that tracks what you want to track.
1:44:04
kristof
I do like globals. They're in the language, and special bindings are unique among all the lexically scoped languages that they deserve to be understood and used.
1:44:08
aeth
This is one way I avoided having a global variable via a macro: (let (... (version (if (fboundp name) (multiple-value-bind (value version) (funcall (fdefinition name)) (declare (ignore value)) (if (and version (integerp version)) (incf version) 1)) 0))) ...)
1:45:16
kristof
I was actually using a defvar in this case to specify a dynamically scoped value that I just didn't want to pass as an argument. I find that valuable
1:46:03
aeth
That does make sense, but I find that the things that make sense as special variables usually already exist (things like *standard-output*)
1:48:00
Bike
if you declare a variable special _locally_, and then bind it again in that extent, that binding will be lexical, so no need for a declaration
4:22:28
Bike
try (find-class name nil). if you get a class, you can use it as a specializer for methods
4:26:51
didi`
Hum, SBCL must do something interesting with the order of slots of a struct, because changing the order of the slots and redefining the struct freaks out the compiler.
4:28:31
Bike
in sbcl's case it means anything using parts of the structure definition will need to be recompiled