freenode/#lisp - IRC Chatlog
Search
3:21:30
beach
I started watching a talk by Robert Virding entitled "On Language Design", and I think the next time someone suggests a revision of the Common Lisp standard, I'll point them to that presentation.
3:23:15
beach
"Be very careful when making changes suggested by users" * They often don't see the whole picture of the changes they suggest. * They often don't know what they really need. * They often want help with a solution; not [with] solving a problem.
4:03:26
contrapunctus
Ironic, in the context of a language which is famous for trusting that the user knows best.
4:04:26
contrapunctus
(And that it should be possible for the user, if they wish, to get involved the design of the language.)
4:06:09
no-defun-allowed
Arguably a user is expected to involve themselves by "extending" a language via macros.
4:06:57
beach
Not really ironic. The users get involved by experimenting, using the existing features of the language, and only after extensive experimentation and user experience is the new proposal considered for standardization.
4:07:53
borei
im not sure if im on right direction or not, so i need some advise. Im working on the client for rados/ceph, and im hitting the following problem. To dump lisp object (instance of class) i need to pack object into flat array. I didn't find better solution then to use CFFI. I don't know lisp so deep and if there is "pure lisp" solution for that problem.
4:08:43
no-defun-allowed
That is a very strange solution, and it sounds like it would get very unportable very quickly, should it depend on the memory layout of standard instances.
4:10:07
bhartrihari
I think it's a fine barbell strategy. Instead of finding a balance in the middle, it balances two extremes—a safe side (conforming code), and the unsafe (and volatile) side (non conforming code but with useful features, eg. OS threads).
4:10:08
bhartrihari
The conforming code will always work, and the very useful non-conforming code can be made to work when it arises. Hence gaining from both the sides.
4:11:50
borei
i'll give you example - let say you say chemical element (which represented by clos class), let say it is helium.
4:12:12
no-defun-allowed
You could store a sequence of readers for the slots you need to dump (or slot names, but readers are a much better approach should you want to modify your representation later), and then iterate over that to get the values to dump.
4:12:32
borei
slots are - mass, charge, number of electrons, symbol (He) and long name (helium) that info need to go to ceph object
4:14:25
no-defun-allowed
Supposing a class definition like (defclass element () ((mass ... :reader mass) (charge ... :reader charge) ...)), you could have a macro like (define-output-format element (mass charge electrons symbol name)) which expands to something that eventually calls your serialisation code.
4:22:40
no-defun-allowed
That may be a property of the values stored (values have types in Lisp), or you may extend define-output-format to include types, like (define-output-format element (mass double) (charge double) (electrons unsigned-integer) (symbol string) (name string))
4:26:18
borei
ok, i have type, and i can use it (and actually im using it) but i don't see solution excepts (setf (mem-ref buffer :int 0) charge)
4:27:40
borei
knowing size of data stored in slot, im using proper offset and loading all data from all slots
4:35:45
borei
i'd be more then happy to avoid C-like data representation - but i can't find lisp way to load data of different type into allocated memory
4:46:09
beach
This talk by Robert Virding is quite interesting. He i an Erlang language developer, but the talk is about general principles, and he might as well talked about Common Lisp as an example of good design. Furthermore, his example of what NOT to do, fits very well with how C++ is "designed".
6:50:08
p_l
beach: he also made a lisp for erlang, based on CL (though not compatible and without the same standard library - the point was to enable writing in Lisp on the Erlang's Open Telecom Platform)