freenode/#lisp - IRC Chatlog
Search
14:35:48
jmercouris
globals, and we wanted to actually change the classes themselves so that inspecting them would show new default value init forms
14:37:19
_death
from what I gathered it sounds like you wanted to avoid something like "factory method" and instead chose to redefine classes?
14:51:05
_death
by "factory method" I mean you could have something like a *configuration* special variable that a user sets to (make-instance 'my-configuration ...) and then there are methods like (defmethod config-create-buffer ((config my-configuration) &rest args) (apply #'make-instance 'my-buffer args)) and possibly a convenience function create-buffer that passes *configuration* to config-create-buffer
14:59:42
jackdaniel
the most portable way to change the initform (and the associated function) is to redefine the class, common lisp has your back and that operation has well-defined semantics (i.e your instances won't stop working etc)
15:10:10
cl-arthur
That reminds me - what's the cleanest way to invoke a macro at runtime? Any better option than giving a list-representation of the macro form to eval/compile?
15:11:18
beach
Or (funcall (macro-function 'foo) <form> <environment>) if for some reason you don't want to use macroexpand.
15:11:23
phoe
a macro function is a standard function that translates from Lisp data to Lisp forms; you can call this function it by calling MACROEXPAND{,-1}
15:11:28
jackdaniel
if you need to expand the code at runtime, then eval is /the/ way (another is to rethink design, it is usually some misconception about your own program)
15:12:32
jackdaniel
also, if you have a macro that takes a few parameters and a body to create a context, you may consider creating macros in a style that it expands into a funcall that passes a continuation
15:13:16
jackdaniel
i.e (defmacro foo (x &body body) `(flet ((,gensymed () ,@body)) (invoke-with-foo x (function ,gensymed))))
15:13:23
_death
beach: wouldn't first class environments also make sense in that configuration scenario?
15:13:58
jackdaniel
_death: wouldn't there be two different classes then? I think that would be undesireable
15:16:40
_death
jackdaniel: I'm suggesting a user create his own class that inherits from the default class (or some subclass of it)
15:18:29
jackdaniel
unless you want to have two classes designated by the same symbol in different environments
15:18:53
cl-arthur
"invoke" - expand the macro form and execute the results. Yeah, seems to be eval.
15:18:53
_death
jackdaniel: so in E1 there'll be a buffer class, and in E2 there will be a different buffer class that inherits from e1:buffer.. then (make-instance 'buffer) can be used
15:20:01
_death
jackdaniel: exactly.. because from reading jmercouris's article, it sounds like they go through all that trouble just so they can say (make-instance 'user-buffer)
15:20:08
cl-arthur
I've seen some (funcall `(lambda () (some-macro ...)) which incidentally work in certain implementations but just hide the eval-iness, I suppose.
15:20:24
jackdaniel
I think that this could be done, however I would argue that packages are much better fit (and of course all other ways we've discussed)
15:21:23
phoe
both are ways to sidestep eval at runtime, and are mostly equivalent to eval at runtime except they can form closures
15:21:24
_death
jackdaniel: packages always seemed a clunky way to do that.. you can't even redefine them
15:22:24
jackdaniel
perhaps, either way thanks for elaborating, now I understand better what you've meant
15:22:38
cl-arthur
jackdaniel: Agree that creating function seams to expand to when possible is nice. (invoke-with-foo)
15:25:12
jackdaniel
cl-arthur: it may be event easily automated, you may check out a function gen-invoke-trampoline in climi package (McCLIM repository)
15:31:02
_death
redefining classes is setting globals.. whereas with my "factory method" approach there is a single global that determines everything
15:31:57
_death
(so it's likely you don't want to set it directly, but call a function that can have hooks etc.)
20:15:26
_death
jmercouris: if you're referring to my paste, I didn't intend it as a solution to your issue
22:24:44
dbotton_
is there a squeak/pharo like x-platfrom graphical environment available for common lisp? in some ways portacle/emas (sans graphics) fills that niche but even so
22:25:43
phoe
everything else that is somewhat usable that I am aware of depends on foreign libraries, like qtools/commonqt which is what I use
22:32:32
aeth
dbotton_: X is designed to permit a client-server separation and there's an X client in pure CL called CLX so McCLIM using the CLX backend on Linux or similar Unix systems can offer a pure CL experience with no foreign libraries.
22:33:55
aeth
Everything else will require CFFI, although it can still be effectively "zero dependency" if it directly calls the exposed OS APIs.
22:44:36
aeth
dbotton_: the problem is that any editor/IDE has to compete with the flawed, but good-enough Emacs in order to get users, so no project has really gotten any momentum
22:51:09
dbotton_
but what though I am thinking about creating is something more like squeak or pharo
23:09:00
Gnuxie[m]
Tbh though, if someone put enough time to it, it is totally possible to beat Emacs+SLIME, it's relatively straight forward what would need to be done
23:23:31
Gnuxie[m]
I meant that it is clear what you would have to do, not that it was gonna be easy