freenode/lisp - IRC Chatlog
Search
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?
10:21:10
jackdaniel
how often do you read forms printed readably on one implementation into another?
10:22:34
phoe
that wouldn't be fully portable though - arrays are not guaranteed to be printable readably
10:27:36
Shinmera
the user might accidentally or purposefully stick those values into a config structure or whatever.
10:28:31
jackdaniel
I think that relying on lisp read / write functions to deserialize / serialize config is not a wise strategy
10:29:29
jackdaniel
if you need to store lisp objects then you want a library like cl-store, dumping forms into a file is more a one-time hack for devs
10:33:47
jackdaniel
ditto, cl-unicode generates its files (only once), magicl has pregenerated ffi definitions to liblapack and such
10:40:10
jackdaniel
phoe: what you've put on github is a misquote given what I said above about cl-unicode and magicl which generate code
10:40:32
phoe
11:21 < jackdaniel> how often do you read forms printed readably on one implementation into another?
10:41:02
jackdaniel
I have an impression that you read very selectively (i.e ignore what I've said later)
13:08:25
lukego
I'm defining data structures for AST nodes. I usually use DEFSTRUCT for each node type, but have the nagging feeling that I should use DEFCLASS, but can't bring myself to do that because DEFCLASS declarations always seem so wordy and redundant. Anybody relate to that feeling? Just live with it? Or is there a DEFCLASS* that I need to start using?
13:08:50
lukego
(Haven't Lisped in a while and wondering if it's finally time to get over my aversion to CLOS.)
13:09:54
Shinmera
Though if you have a well-defined set of classes that are all similar, writing a specific macro for it is just fine.
13:11:07
luis
I like defclass-star (but don't use it very often). Succinct like defstruct, flexible like defclass (obviously).
13:14:34
Shinmera
p_l: copy paste is not governed by paredit, which is useful for getting it back into a stable state without having to deactivate it.
13:15:35
luis
Paredit eliminates that silly step at the end of writing a bit of code where you make sure parenthesis match up properly. If you use electric-indent-mode you can even get rid of the make-sure-your-code-is-properly-indented step. (Although that step is pretty quick with M-q paredit-reindent-defun.)
13:15:47
p_l
Shinmera: it's also an excellent way to get it to state where it gives up counting parens. I know there's a chord to type parens disregarding paredit state, but I a) never remember it b) never got fluent enough with structural editing to gain much benefit
13:16:24
Shinmera
I pretty much only use slurp/barf/convolute in paredit. Same for Slime, my fu is really weak in general.
13:16:57
p_l
yeah, same here. Just found that electric indent and electric parens work better for me now
13:17:53
luis
Shinmera: interesting. I think what I use the most is splice (M-s), raise, (M-r) and kill (C-k and C-M-k)
13:18:02
lukego
Thanks p_l it's nice to be lisping again too :). Seems like every time I start working on a project I think "Hey I wonder if I could do this in Lisp" but usually not due to some constraint. Just now I want to make up a DSL and write a transpiler onto diverse targets and Lisp seems like a great fit.
13:18:36
Shinmera
luis: Oh yeah, splice, too. And kill I didn't even think about being a paredit thing but I use it too.