freenode/#lisp - IRC Chatlog
Search
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
2:22:53
aeth
Gnuxie[m]: I think the issue is one of time. Generally the way to get enough time to do it is to get paid to do a job in a related thing and there just aren't enough CL jobs yet.