freenode/lisp - IRC Chatlog
Search
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
7:06:48
jdz
krwq: it basically defines the "seq" protocol, and one can use it on all kinds of things, including lists and vectors and strings.
7:07:50
krwq
Zhivago: but you could easily define a sub-vector type which could be used the same way - besides that is mostly used with tail-recursion which is easily optimized
7:08:56
krwq
I'm thinking of a list as a plain block of memory and two pointers marking beginning and the end
7:09:46
basket
jdz: Well Common Lisp has the SEQUENCE class with all kinds of subclasses, including lists and vectors and strings
7:12:00
krwq
i think I'll try implementing list with vector and move back to cons-es if it will become annoying
7:14:41
krwq
that will make it much easier - i will have to quirk code all over the place if I implement list with vector and have to assume that empty vector is NIL
7:15:06
beach
krwq: For a compact representation of lists, see the Lisp-machine feature called "CDR coding".
7:16:58
beach
krwq: Lists are much faster for things like adding or removing a single element from the front.
7:17:50
krwq
beach: that's true I admit but if a compiler detects that you only do that then it can switch direction of vector
7:18:31
beach
krwq: A vector won't solve the problem. It would need to be re-allocated from time to time.
7:18:40
jdz
Funny how the Wikipedia page on CRD coding links to https://en.wikipedia.org/wiki/Unrolled_linked_list.
7:20:25
beach
krwq: Different data structures have different performance characteristics. The creators of Common Lisp were very concerned about performance. That is why Common Lisp gives the programmer a choice, as opposed to (say) implementing lists as balanced trees which would be slower for the operations for which lists are particularly fast.
7:20:36
krwq
thread safe queue might be the only example where linked list might actually win - or if you do a lot of manipulation in the middle which is quite rare IMO
7:21:35
beach
krwq: If you add or remove elements in the middle, you should use neither a list nor a vector.
7:21:35
krwq
beach: memory used to be more expensive when lisp was invented so it made sense back then - right now almost always it is better to have one chunk of memory
7:23:06
shka_
"so, this vector thingy, aren't you sure that in fact it is some radix tree based functional data structure?"
7:23:49
beach
shka_: Just like we can't predict the performance of adding a single element to a vector.
7:26:39
krwq
beach: I never said they are always better - they are almost always better than linked lists
7:27:21
beach
krwq: "almost always" makes no sense. It depends on the use case. You must state it relative to the use case. Besides, what if you are right? Does it mean we should eliminate lists?
7:29:22
beach
krwq: Anybody can say anything on YouTube. That video does not in any way show that "vectors are almost always better than linked lists".
7:30:36
beach
krwq: To make such a statement, you would have to look at all programs that use lists, then re-implement them using vectors, count the number of programs that have their performance improved, and if it is greater than half, then you are right.
7:32:29
shka_
and some people know what they are doing, so forcing vectors in each throat is quite pointless
7:36:41
krwq
https://www.codeproject.com/Articles/340797/Number-crunching-Why-you-should-never-ever-EVER-us - the only case where linked list is better is when you have fragmented memory
7:39:29
jdz
It should have been "Why you should never, ever, EVER use linked-list in your code again if you program in C++".
7:40:29
hajovonta
the article actually states: "The number crunching prefix is key to this whole article. If the "Number crunching:" part of the title is ignored it might be understood as a general advice to always stay away from linked-list, that is not the purpose of this article. "
7:41:29
jdz
The choice of programming language and libraries constrains (or at least heavily influences) the data structure, algorithm and general problem solving choice.
7:43:38
jdz
krwq: For instance the section(s) about locality of reference completely disregard garbage collection and GC'd language implementations.
7:47:54
krwq
jdz: considering that in almost every benchmark linked list loses I'd rather have linked list as a separate data structure - it's true that we can't tell for sure which one is better without implementing reasonable size lisp program and checking how it performs on both implementations
7:50:22
hajovonta
but then there is versatility and maintainability and linked list may be advantageous when these are more important than number crunching performance
7:51:23
jdz
hajovonta: if linked list is not the right data structure, use the one that _is_ right. Where's the problem?
7:52:11
hajovonta
I often use a linked list when first attacking the problem and then later switch if it becomes a performance problem
7:54:05
jdz
Again, I think the original question was about implementing single-linked lists with vectors, and people in this channel argue that that is the wrong thing to do.
9:02:17
miatomi_
anyone know if there's a "newbie friendly" distribution of common lisp? the thing I'm looking at is this: between learning asdf, learning about quickproject, quicklisp, slime, etc. on top of just learning common lisp, there was a lot of friction that I had to go through that might throw some other newbies off. if there was a distribution of sbcl, lets say, that came bundled with quicklisp and automatically installed quickproject with
9:02:17
miatomi_
a short tutorial, that would probably take down the TTL (time to learn) for new people a ton, and give them an almost clojure/leiningen like experience
9:04:39
pjb
clisp has a number of features that are newbie friendly: it includes readline, and has a usable debugger, so you can use it in the terminal without slime.
9:05:27
pjb
Some care is given to return unsurprising results for newbies. Eg. sort will keep the first and last cons cells in place.
9:05:55
pjb
Of course, it is not a good idea to rely on it, but while learning how to program, it is a question that may stay delayed.
9:06:57
pjb
clisp also has a number of modules included, so that you can write interesting programs without having to load any quicklisp libraries.
9:07:34
pjb
So you can spend a couple of years in clisp, without having to learn slime, asdf, quicklisp, quicklproject, etc. Just pure Common Lisp.
9:08:00
pjb
Once you know Common Lisp you can learn emacs and then include slime. And later you can include libraries with asdf and quicklisp.