freenode/#lisp - IRC Chatlog
Search
7:41:21
hectorhonn
the primary unit of abstraction in java is classes. what is the primary unit of abstraction in lisp?
7:53:00
hectorhonn
beach: i see its a chapter 5. looks like a good book, how do i get to the other chapters?
7:54:09
no-defun-allowed
beach: irrelevant, but how do you typeset those nice looking function/class/gf description lines in your documentation on closos and sicl? Is it something you made yourself or is it a common LaTeX library?
7:56:16
beach
no-defun-allowed: I am using a small library that came with the CLIM documentation called specmacros.tex
7:59:04
hectorhonn
beach: erm, what's the take away from chapter 5? i'm don't feel like i've learnt anything
8:03:19
hectorhonn
beach: so, the primary unit of abstraction in lisp is also classes? and generic functions?
8:04:57
hectorhonn
beach: for example, suppose i want to write a parser manually, as an exercise. should i represent the AST as a defclass?
8:07:49
verisimilitude
I'd think symbols and lists and functions and that manner of thing are the primary abstraction of Common Lisp.
8:08:11
verisimilitude
You could boil any language down to ``protocol'' as the primary unit of abstraction, if you wanted to.
8:09:04
verisimilitude
Common Lisp has an OO system called CLOS, hectorhonn, but you can rather entirely ignore it if you feel like it.
8:14:50
verisimilitude
Macros rely on the homoiconic nature of Lisp, related to its lists. Lists are important for abstraction.
8:16:47
hectorhonn
i guess what i really wanted to ask was, for example in java, i would write a XyzToken class for each type of token parsed, with a common base class Token, maybe with some common and specific operations. Then another class to represent a list of Tokens. so i have somehow represented (or abstracted?) this idea of "token" in the program,
8:17:16
hectorhonn
In haskell there would be a record sum type, and several functions that can act on the record. then another record type to represent a list of tokens
8:18:07
jackdaniel
(i.e it is less opinionated how you should write your program than Java or Haskell)
8:18:49
beach
In Common Lisp, you would choose whatever is appropriate in terms of performance. It could be symbols, lists, hash tables, arrays, standard objects, whatever.
8:19:03
jackdaniel
so while having "the one way" how to do things is comfortable it is also limiting
8:20:32
jackdaniel
you may arrange your program around protocols (like in haskell), you may create a class hierarchy with functions operating on it (like in Java), or you may write your own dsl with macros (like verisimilitude suggests). I think that finding the programming style which suits you best is a hard but worthwhile endavour
8:21:24
verisimilitude
Your main options are making a class for tokens which you instantiate, making a structure representing tokens, or just using an informal representation, such as a list of whatever you need, hectorhonn.
8:21:53
verisimilitude
Until you have a good idea of what you're doing, the list of whatever you need option is the easiest and most flexible.
8:22:01
jackdaniel
i.e there are libraries in Common Lisp which are referentially transparent (something often praised among programmers who fancy functional programing), but there are also many libraries depending heavily on OO
8:22:58
minion
hectorhonn: paip: Paradigms of Artificial Intelligence Programming. More about Common Lisp than Artificial Intelligence. Now freely available at https://github.com/norvig/paip-lisp
8:23:30
minion
hectorhonn: have a look at pcl: pcl-book: "Practical Common Lisp", an introduction to Common Lisp by Peter Seibel, available at http://www.gigamonkeys.com/book/ and in dead-tree form from Apress (as of 11 April 2005).
8:24:00
jackdaniel
and this book is more concentrated about mainstream (these days) style of CL programming heavily depending on CLOS (but starts from basics)
8:25:30
hectorhonn
haha... ever get that feeling when trying to start drawing something on a blank canvas? CL gives me that no restriction feeling
8:25:47
verisimilitude
Lisp is best, I think, when you don't quite know what you're doing yet, hectorhonn.
8:26:03
jackdaniel
hectorhonn: if you decide to listen to my advice, I'd recommend starting reading PAIP
8:26:08
verisimilitude
There are plenty of better languages if you know exactly what you're going to be doing, but Lisp is good for exploration.
8:26:41
jackdaniel
since it provides many case studies analyzing and evolving code bit by bit towards the sketched goal
8:27:39
verisimilitude
Also, hectorhonn, I noticed I've yet to recommend you any reading material, even in our last discussion, so I'll recommend something you already have.
8:27:50
hectorhonn
ok, so combining advice from beach, jackdaniel, and verisimilitude, i should start out with lists, explore different ways to find out which style i like best, and remember that i can use *anything* in lisp, there is no idiomatic way like in haskell or java. that right?
8:28:35
verisimilitude
There's a saying that if you give twenty different Lisp programmers something to do, you'll get twenty different programs, hectorhonn.
8:29:16
verisimilitude
The related saying is if you give twenty different Java programmers something to do, you'll get twenty copies of the same program.
8:29:18
jackdaniel
hectorhonn: another way of studying (which proves to be more engaging for some people) is to contribute to open source projects
8:29:54
jackdaniel
then you have some conventions already in place, so you are not left without any clues how to do things
8:32:00
ealfonso
I have a non-lisp source file vars.conf which I need to read from lisp. using a path relative to (uiop:current-lisp-file-pathname) works on the repl, but fails with no-such-file when the lisp source file is in ~/.cache/common-lisp: /home/USER/.cache/common-lisp/sbcl-1.3.14.debian-linux-x64/home/USER/git/path-to-file/vars.conf. How can I either make the compiler include the vars.conf next to the compiled source files, or refer to the
8:32:03
jackdaniel
I don't see much value in belittling programmers of other languages (or other programmers in general) [re java programmers]
8:32:27
hectorhonn
"The related saying is if you give twenty different Java programmers something to do, you'll get twenty copies of the same program" Actually this is exactly what a language should strive for, no? clear semantics
8:35:36
jackdaniel
hectorhonn: cffi maintainers are very nice people to work with. from other projects you could help with mcclim and ecl (I'm working on these); but I think that the best advice is to look for something you find useful and fun to work with
8:36:02
jackdaniel
slime project is also something benefitting whole community, so even small improvements have big impact
8:36:44
verisimilitude
If we're recommending Common Lisp projects now, I'd recommend you at least start with projects that are implemented in pure standard Common Lisp, hectorhonn.
8:38:39
verisimilitude
Put simply, there are plenty of Common Lisp programs or libraries that either only work on one implementation, usually SBCL, or use the CFFI and offload all of the work onto something written in a different language, both of which I believe should be avoided.
8:41:42
verisimilitude
I was writing a program with an interactive terminal interface and did take a look at the available libraries.
8:42:44
verisimilitude
You have Common Lisp, this nice language, and yet these libraries risk memory leaks for what amounts to printing text.
8:43:25
hectorhonn
verisimilitude: that's a pragmatic decision i guess, ncurses library already exists and can interface easily with the os
8:43:25
verisimilitude
Not only that, but it's so much more bothersome to lead a Common Lisp library that wants an entire C library with it.
8:46:52
verisimilitude
As a tangent, Github is awful, hectorhonn, and you should avoid it wherever possible.
8:47:17
verisimilitude
I'd much rather a company need to bother my VPS provider than just email Github and demand something be taken down, which happens.
8:48:55
hectorhonn
verisimilitude: i see. that's good to hear. stuff taken down probably violates copyright
8:49:51
verisimilitude
https://torrentfreak.com/fuckr-developer-right-or-not-backs-down-in-fear-of-grindr-copyright-lawsuit-181014
8:50:20
verisimilitude
It would be much harder to abuse copyright for taking down things you don't like, if so many people weren't all in a centralized location.
10:43:29
pjb
verisimilitude: lists are important for abstraction, only if you use them to represent everything. If you were ready to use CLOS classes for everything (like in Smaltalk, say), then classes would become an abstraction device. Until that, they're just a representation device. It can be used to represent external objects, and thus abstract _them_, but not as an internal abstraction, since you could also have structures, vectors,
10:45:53
pjb
verisimilitude: also, there is a way to distinguish the representation from the abstraction. This week, I had to debug a bug in C (it would be the same in lisp) where I had a typedef struct { void* data; int size } buffer; with a function buffer_new(int size) and a function buffer_free. The call to free failed on invalid pointer even thought it was allocated in buffer_new.
10:46:14
pjb
verisimilitude: the reason why that some client code used &buffer->data and incremented the pointer.
10:47:29
pjb
verisimilitude: the solution was to stop using this representation (the structure) and replace it with an abstraction: typedef struct buffer; void* buffer_data(buffer* b); int buffer_size(buffer* b); Then the client code could not increment the buffer data pointer. That representation was abtracted away, code become safe and correct.
10:53:48
Inline
ebrasca: now if clim was not loaded and hence not pushed onto the *features* list then it will skip that form
10:57:18
pjb
(setf *features* (delete :+ *features*)) (read-from-string "(a #++ b c)") #| --> (a c) ; 11 |# (pushnew :+ *features*) (quote (a #++ b c)) #| --> (a b c) |#
10:58:40
pjb
To give the feature + (assuming standard readtable and packages, ie. cl:+) to #+ you would write #+cl:+
11:00:44
pjb
#+#.(cl:if (cl:= (cl-user::version) 2) '(:and) '(:or)) (new-function) calls new-function only if (version) returns 2…
11:02:17
pjb
More simply: #+sbcl x #+ccl y #-(or sbcl ccl) (error "not implemented for ~S" (lisp-implementation-type))
11:10:18
pjb
(find "LITTLE" *features* :test (lambda (x y) (search x (string y)))) #| --> :little-endian-target |# in ccl
11:11:29
pjb
in sbcl and ecl we have :LITTLE-ENDIAN, and in abcl and clisp nothing. (those works on VM that abstract away the endianness. eg. clisp always writes binary files in little endian, even on big-endian architectures, so clisp binary files can be compatible between clisp on different platforms)
11:19:19
jackdaniel
sindan: you can't, because they are not standarized and they are pushed from different places
11:19:35
jackdaniel
i.e you may find a description in the implementation manual chapter about weak references
11:20:12
jackdaniel
check out https://github.com/trivial-features/trivial-features/blob/master/SPEC.md
11:21:53
sindan
I see. So, trivial-features and starting from implementation docs if they exist. I'm guessing there will be acceptable documentation for sbcl.
11:25:58
jackdaniel
regarding mezzano, I think that such contribution would be accepted in the library, but I don't really know; ask luis
11:26:40
jackdaniel
and as of gnu hurd: is there lisp which actually works on gnu hurd as of today? and if yes, I suspect gnu hurd being a posix system, so this is explained that "sysname" information from uname is used
11:29:53
jackdaniel
if you had read the pararaph as I have suggested, you would know, that on POSIX systems the "sysname" information from uname(3) should be used
11:38:15
jackdaniel
everyone is entitled to think what they desire to think, fact remains that this works exactly as specified, sysname value is "Linux" on systems powered by linux kernel
11:43:02
jackdaniel
ACTION resigns from trying to explain why it is irrelevant given how this *features* entry is specified in the document (with a disappointment)
11:45:19
jdz
ebrasca: Not sure what you are trying to accomplish here, but this is very off-topic, so I also resign from further discussion.
11:53:10
ebrasca
jdz: yea I have find it in my log. "<|3b|> ebrasca: no idea, haven't tried to run it since i stopped working on it :/"
11:58:24
pjb
sindan: for example, you can see the doc of *my* features for *this* project at: https://framagit.org/patchwork/patchwork/blob/master/notes.txt#L326
11:59:41
|3b|
cl-vulkan isn't "abandoned", but it also isn't currently being worked on, so if you want to use it, you will probably need to add to it
12:01:01
|3b|
ACTION intends to work on it more, it just isn't likely to make it to the top of my priority stack any time soon
12:01:25
pjb
You can make a CL implementation run directly on the Linux kernel. See an example with emacs: https://www.informatimago.com/linux/emacs-on-user-mode-linux.html for a CL implementation with (or new emacs with modules) FFI it would be easier, since we could do the mount directly.
12:01:41
elderK
It's like my tinkering on binary-typesy stuff has taken a backseat - past couple weeks I've been spending a ton of time learning about lisp implementation.
12:01:43
|3b|
(2 other unrelated projects ahead of it, then i probably want to work on spirv compiler some more before vulkan itself, and also get a better idea of how i want to use it)
12:02:30
|3b|
spirv is probably less important now than when i last worked on it though, since i think there are glsl extensions available that would be good enough for getting the rest working
12:03:03
|3b|
knowing how i (or anyone else for that matter) would want to use it is important though, hard to design good abstractions without knowing use cases
12:10:59
|3b|
trying to assemble a thermal camera (mostly just having trouble getting a working configuration of a 64bit arm board with all the drivers i need), and writing some simple utilities for android
12:11:23
|3b|
https://github.com/3b/cl-vulkan-samples/blob/master/initswapchain.lisp#L4 makes a vkSurfaceKHR
12:13:03
|3b|
https://github.com/3b/cl-vulkan/blob/master/vk/wrappers.lisp#L451 is the definition of the function/macro it uses, so you will need to write a linux version of that for whichever OS API you use
12:19:05
|3b|
ok, looks like glfw wants you to call its functions to create the surface, so you will have to look at bodge-glfw to figure that out
12:22:23
ebrasca
|3b|: Some years ago you helped me with cl-opengl. I like to be more like you and write good code and look like I know everiting.
12:23:26
|3b|
%glfw:create-window-surface + %vk:destroy-surface-khr should replace the vk:with-xlib-surface
12:24:30
|3b|
i'm not sure you are calling %glfw:create-window-surface correctly though, the last argument is a foreign pointer to the surface
12:24:59
|3b|
you will need to ask borodust how to call that, i'm not familiar with the wrapper generator it uses
12:28:50
jackdaniel
|3b|: new lesson learned! you look like you know everything , don't spoil it with "I'm not familiar…" talk ;-)
12:31:54
|3b|
ebrasca: #++ is my lazy way of commenting out forms. slightly shorter and easier to type than #+()
12:36:01
|3b|
and :+ on *features* seems sufficiently unusual that i'm willing to just let someone send me a patch to fix it if they come up with a good reason they need it
12:37:32
|3b|
(or remove them for that matter, though ideally most code would have pure CL fallbacks for non-bugfix cases)
12:37:41
jackdaniel
I'm taking my time to correct all #+nil 's to #+(or) when I encounter them in code I work with (for sake of correctness by default)
12:38:34
|3b|
i usually try to just remove them completely once i'm done actively working on something
12:39:22
|3b|
most of them are debugging and/or multiple attempts at something i haven't figured out yet
12:50:52
pjb
I prefer the more direct #+(and) included or #-(and) skipped. #+(or) is kind of a triple negative…
12:51:38
pfdietz
A tool that would use Eclector to produce a kind of parse tree that can be converted back to something that is character-for-character equivalent to the original file. Then, do rewrites on that representation to get rid of #+nil forms (the example above).
12:52:06
pfdietz
It would be easier if lisp files were directly equivalent to the forms after reading, but that loses comments and other reader-handled stuff.
12:53:19
|3b|
pjb: ideally it wouldn't show up much in 'released' code, unfortunately not much of my code makes it to that point :(
12:56:31
|3b|
ok, i'd probably apply that if sent, though i'd probably keep using #++ if i worked on it some more :)
12:56:38
scymtym
pfdietz: i made a very quick and dirty demo for something like this a few weeks ago (in this case replacing IF without alternative leg with WHEN): https://techfak.de/~jmoringe/refactor.png
12:59:52
pfdietz
Clone detectors? Lots of work on that in general. Dont know about for Common Lisp specifically.
13:06:37
ebrasca
|3b|: Have in mind I have done bad fat32 implementation and part of ext for mezzano.
13:18:03
pjb
I guess something like my electric-+-suppress https://pastebin.com/vYhbL47s could be achieved with abbrev too.
14:00:04
beach
Why do you care so much about specifying that? Just make sure that it does return an integer or a list of integers.
14:05:17
beach
hectorhonn: Some authors claim that statically typed languages force the programmer to supply information early on in a project; information that is then very likely to change later.
14:06:43
beach
More often than not, the information is about representation of objects, which is an implementation detail that can change later. If you want to supply type information, you should do it in terms of the abstract types of your protocol.
14:10:32
hectorhonn
beach: true. on the other hand, changing the return type of a function would require a change at all call sites, so imho its better to have that kind of information supplied early during design and set in stone. then write an wrapper as an abstraction for the function if things do change
14:36:45
scymtym
pfdietz: thank you for the idea. prototyping this revealed a few shortcomings in eclector: https://techfak.de/~jmoringe/bad-reader-conditionals.png
14:40:20
scymtym
the shortcomings were related to the fact that this reader client does not use host symbols or packages
16:20:41
jcowan
beach: that definition doesn't seem to be particularly CL-centric; I think it could apply to almost any language with (dynamic) types.
17:09:43
pjb
MoziM: however, Univac were nice computers. It would be fun to implement (or find) an emulator, and run this lisp.
17:10:49
pjb
Also, the compiler is written in lisp, so you could easily write a driver to run it in CL…
17:19:48
MoziM
is this an accurate way to summarize the "LISP" way of thinking? still trying to get my head around it https://i.imgur.com/m2BmyGa.png
18:16:41
drmeister
Hey folks - bordeaux-threads *default-special-bindings* is confusing me - in what thread are the forms supposed to be evaluated?
18:17:08
drmeister
It says in the documentation for *default-special-bindings*: "Forms are evaluated in the new thread or in the calling thread? Standard contents of this list: print/reader control, etc. Can borrow the Franz equivalent?"
18:19:53
drmeister
It makes more sense to me to evaluate the forms in the parent thread because then bindings like ( ('*print-pretty* . *print-pretty*)) will get the value of the *print-pretty* binding of the parent. If you evaluate *print-pretty* in the child thread - then you will get the global value.