freenode/#lisp - IRC Chatlog
Search
19:07:32
minion
dim, memo from _death: maybe you'll find what I hacked this past few hours a useful start - https://github.com/death/TIC-80
19:52:30
pjb
_death: given that you can define defglobal in two lines, why should it have it? Just do it!
20:00:37
scymtym
pjb: which aspects would that replicate? performance characteristics or behavior or both?
20:10:22
scymtym
then again, _death said "like sb-ext:defglobal", so he could have referred to a subset of its behavior
21:14:41
aeth
(defparameter *foo* (list 1 2 3)) (define-symbol-macro foobar (elt *foo* 2)) (macroexpand-1 'foobar) => (ELT *FOO* 2)
21:16:28
aeth
in fact, referencing things that aren't global won't work, e.g. (let ((temp (elt *foo* 2))) (define-symbol-macro barfoo temp)) ; barfoo will only work in places where there's a defined temp, like e.g. (let ((temp (elt *foo* 2))) barfoo)
21:27:52
aeth
I suppose the way to handle it properly would be to have a mutable global *foo* (probably an array or hash table, though) because otherwise setf won't work as expected.
21:27:54
_death
pjb: yes, for my purposes defvar+define-symbol-macro could work.. I just wanted to know whether ecl already has such a thing
21:34:57
aeth
At the very least, there's no mention of it here. https://common-lisp.net/project/ecl/static/ecldoc/Extensions.html
21:36:35
_death
guess that for a nicer CL experience w/ tic-80 there'd have to be a specific module.. but that is a job for another time
23:16:21
pierpa
CCL's DEFGLOBAL doesn't do what I understand you are talking about here. It's only vaguely related to global variables.
3:36:24
Josh_2
I left my laptop on, I was attacked by someone I know so that sobered me up pretty fast
6:43:44
krwq
hello, I wonder, does every lisp implementation use cons or is there any where (equal () t)? ( () would be an empty list but nil is not a list )
6:45:38
SaganMan
I think every implementation use cons but lisp intepretor doesn't bother to print nil
6:47:12
krwq
sbcl but currently writing my tiny interpreter which I'd like to eventually expand to compiler
6:50:14
krwq
if every lisp implementation chose cons I'll go with implementing list with conses if there is a precedence for choosing more memory friendly list representation I'll go with that
6:52:51
krwq
I noticed when I write in common lisp i rarely play such low level as list manipulation so there is not much gain in doing linked list
6:54:11
krwq
I wouldn't mind reversing it so that regular list would be implemented with vector but linked list implementation could be there too
6:54:17
jdz
krwq: if you've looked at basic data structures you'd know that these are different data structures, and have different properties and tradeoffs.
6:54:53
krwq
jdz: i did a lot of algorithms and from my experience linked list is almost always slower than vector
6:58:20
krwq
but when you compile to machine code you could easily put non-mutable vector on the stack while mutable conses will be a PITA