freenode/lisp - IRC Chatlog
Search
22:36:29
_death
I thought cl-online-learning would be cool for actual use, though I've not yet had the chance
0:04:40
no-defun-allowed
As in, (find-class '(your . cons)) will give you that class, or that the class-name of that class is your cons?
0:05:25
mfiano
The latter. Don't ask why. I think both of our heads would explode if I tried to explain it. It just seems like the best abstraction for a hard problem I've been trying to solve.
0:05:37
no-defun-allowed
I think you can do (make-instance 'standard-class :name '(your . cons)) to make a class that has a cons for a name, but I don't know if it's portable.
0:05:56
mfiano
I would like to (make-instance '(pkg1:foo pkg2:bar) ..) but if it's not possible I'll continue my search
0:11:57
pjb
mfiano: make-instance is a generic function. If you can map your list onto a symbol, then you can do it.
4:27:08
jcowan
Question for anyone: When you think of an alist, do you think by default of one with atomic keys that can be tested with EQL, or of one with keys that aren't necessarily atomic and are testd with EQUAL?
4:28:33
no-defun-allowed
Probably atomic keys that are EQL, so probably symbols. FWIW, EQL is the default test for assoc among other alist managing things.
4:33:58
White_Flame
I have a lot of macros that set alist & plist functions' :test to #'eq, so I often use the former
4:54:10
jcowan
As I've said before, EQ is basically a performance hack, and it's EQL that is Lisp's identity predicate.
4:55:29
White_Flame
but even with numbers, if you have array or list indexes/lengths, those numbers are always going to be fixnum, as they can only be as big as address space anyway
7:05:47
beach
It is an interesting observation though. Is the integration with the type system based on CLASS-NAME of the class (I don't think so) or FIND-CLASS?
7:13:45
beach
AHA! The secret is that the class name must be a "proper name" (see the glossary) for it to be a type.
7:14:47
beach
That is, FIND-CLASS of SOME-SYMBOL must return a class with a CLASS-NAME of SOME-SYMBOL.
7:31:12
beach
ACTION heaves a sigh of relief since the SICL bootstrapping procedure uses classes with the same CLASS-NAME as the standard ones.
7:36:32
beach
So I think that what CLIM II did should not be necessary. They could have used symbols as names. But, as Scott McKay told me, when they wrote the CLIM II specification, CLOS implementations were not very good.
7:43:12
beach
He also told me that the way moore33 implemented presentation types for McCLIM was the way they would have wanted to use for commercial CLIM, but (again) the CLOS implementations at the time just weren't good enough. I don't know what they did instead, though.
7:47:37
beach
phoe: What makes you think that in ANSI Common Lisp, all classes must be named by symbols?
7:48:36
beach
phoe: I.e. where do you see that it is not allowed to do (make-instance 'standard-class :name '(a b c))?
7:49:07
beach
phoe: Where do you see that it is not allowed to do (make-instance 'standard-class :name '(a b c))?
7:49:31
jackdaniel
I don't understand the "In the MOP remark" -- that would mean that having MOP in ones implementation violates the spec
8:04:17
jackdaniel
does it though? I'm looking at the code now and it seems that class names are something like
8:06:42
jackdaniel
if you refer to the first paragraph "defines a presentation type whose name is .." -- I don't read it that presentation name is the same as the class name this presentation is represented with
8:13:11
jackdaniel
depends how you define a portable code. if you define it as a code which runs on an implementation which is strictly adhering to ansi standard then yes. if you take that portable code runs on existing implementations then most of them define mop
8:21:17
pjb
(defclass |the damn class of all the objects that can talk violet| (|the funny class of talkers| |colored spoken objects|) ()) …
8:22:47
pjb
and if you want lists you can always (read-from-string (format nil "(~A)" '|the damn class of all the objects that can talk violet|)) #| --> (the damn class of all the objects that can talk violet) ; 56 |#
10:15:06
phoe
it seems that the #A extension for printing arrays readably works the same across SBCL and ECL/Clasp with one difference in printing order - whether dimensions or element type comes first
10:15:51
phoe
since I am looking to implement that extension for CCL, is it also worth to try and unify the way implementations work this way, or do I just pick one of the two sides?