freenode/#lisp - IRC Chatlog
Search
19:42:45
pjb
minion: memo for didi: there are downsides in using :type : then you won't be creating a new type, so it'll be harder to distinguish those structure instances from lists (or vectors). So you would do that, only when this would be the point.
19:47:14
aeth
On the other hand, you can manually deftype, but that's only practical for specialized arrays, not lists.
0:04:57
asarch
I'm trying to run the example from the "A Guided Tour of CLIM, Common Lisp Interface Manager"
0:18:54
pjb
Yes, define it! (cl:defun use (cl:&rest packages) (cl:apply (cl:function cl:use-package) packages))
0:20:31
pjb
Bike: asarch has a problem understanding packages and keywords and qualified symbols. He needs some play and exercises wiht them.
0:21:56
asarch
As far I understand: (defpackage :wasser (:use :clim)) (in-package :wasser) ... ;The rest of the code of the example
0:25:36
pjb
(defpackage "TEST" (:use)) (remove-duplicates (list (read-from-string "defpackage") (read-from-string ":defpackage") (read-from-string "cl:defpackage") (read-from-string "keyword:defpackage") (read-from-string "test::defpackage"))) #| --> (defpackage :defpackage test::defpackage) |#
0:26:40
pjb
(let ((*package* (find-package "TEST"))) (read-from-string "defpackage")) #| --> test::defpackage ; 10 |#
0:28:34
pjb
(let ((*package* (find-package "KEYWORD"))) (read-from-string "(cl:defpackage \"FOO\" (use clim))")) #| --> (defpackage "FOO" (:use :clim)) ; 32 |#
0:28:47
pjb
(let ((*package* (find-package "CL"))) (read-from-string "(cl:defpackage \"FOO\" (use clim))")) #| --> (defpackage "FOO" (common-lisp::use common-lisp::clim)) ; 32 |#
0:28:58
pjb
(let ((*package* (find-package "CL"))) (read-from-string "(cl:defpackage \"FOO\" (:use #:clim))")) #| --> (defpackage "FOO" (:use #:clim)) ; 35 |#
0:33:46
pjb
asarch: didn't you notice the fucking importance of the *package* variable for the meaning of what is read?
0:36:53
asarch
One step at the time: 1. I start a fresh session of SBCL. 2. Load clim: (ql:quickload "clim") 3. Load the pure code of this example: (load "example-02.lisp") and I get:
0:37:45
pjb
asarch: the stereotypical file will contain (defpackage "FOO" (:use "CL" "AND" "STUFF")) (in-package "FOO") …
0:38:42
pjb
if you want to type (use "CL"…) then you need *package* to be bound to the keyword package, so you need: (in-package "KEYWORD") (cl:defpackage "FOO" (use "CL" …)) (cl:in-package "FOO") …
0:39:52
pjb
asarch: again, read clhs in-package and clhs use-package closely, and underline each difference!
0:42:20
asarch
Ok. How would you fix this code? How would you write something like: #include <clim.h> and voila!
0:43:48
pjb
I explained you above the stereotypical file structure. Why cannot you apply it to your file? What's wrong with the sentence "the stereotypical file will contain (defpackage "FOO" (:use "CL" "AND" "STUFF")) (in-package "FOO") …" ?
0:44:38
pjb
What do you need to be told to be able to take a good example and reproduce it in your code?
0:45:52
pjb
Note that if error messages are unclear or ambiguous, in general maintainers will take bug reports about them and clarify/correct them.
1:14:11
pjb
FOr example, I could ask you what the standard says about a thing, but you wouldn't understand why I'm asking you about that thing, because you can't read an error message.
1:16:54
pjb
asarch: for example, we gave you the clhs use-package to read, but you still don't understand that packages such as the :clim package are not used IN the REPL, but used BY other packages.
1:17:31
pjb
(also incidently, you've been told from the start the solution, but you couldn't apply it).
1:22:10
asarch
So, an example would be fine. If I do: (defpackage :asarch (:use :common-lisp)) (in-package :asarch) I understand I am making available all the functions from :common-lisp plus the functions from :asarch, right?
1:27:11
no-defun-allowed
IN-PACKAGE also means all new symbols in the file or REPL will be interned into ASARCH.
2:09:54
pjb
no-defun-allowed: no, using packages doesn't intern symbols. Symbols can be interned only in their home package.
2:12:49
pjb
notice however, that you can intern a symbol with more than one operator (intern, of course, but also import and shadow can intern a symbol).
2:14:32
pjb
Also, contrarily to intern and shadow, and import can intern an existing symbol (if it has no home package).
2:24:28
asarch
So, in the example, (I was re-reading all my notes): Instead of writing (clim:make−pane ...) I could do (use-package :clim), right
2:26:04
asarch
However, if I do that, I get USE-PACKAGE #<PACKAGE "CLIM"> causes name-conflicts in #<PACKAGE "COMMON-LISP-USER"> between the following symbols: COMMON-LISP:INTERACTIVE-STREAM-P, CLIM-LISP-PATCH:INTERACTIVE-STREAM-P
2:26:17
pjb
As long as you do that in a package that doesn't already have symbols with the same name as the symbols exported by the "CLIM" package.
2:38:25
no-defun-allowed
pjb: i believe i said "new symbols ... [are] interned into ASARCH" and "all the symbols from CL [are] used in ASARCH" which is correct
2:56:32
mfiano
It is bad practice to use use-package a lot. The solution is to not use it, and allow your code to be more readable. Alternatively, shadow the exports or imports.
3:01:58
asarch
beach, would you please help me with this code?. I have a mess with the package part: http://paste.scsys.co.uk/581400
3:02:03
beach
asarch: In your package FENSTER, you need to :USE something that contains Common Lisp symbols too. Either :COMMON-LISP or :CLIM-LISP.
3:02:47
beach
asarch: But as mfiano says, I recommend against :USE-ing packages other than :COMMON-LISP (or in this case :CLIM-LISP).
3:03:39
beach
asarch: Also, the system to install from Quicklisp is not called CLIM, it is called MCCLIM.
3:05:43
beach
asarch: You will find a very small (but working) example of using CLIM here: https://github.com/robert-strandh/Compta
3:06:38
beach
But you can study the compta.asd file, the packages.lisp file, and you can look at how symbols are prefixed.
4:23:10
didi
Sooo. I want to use `assert' within `defsetf'. The problem is, the place I use inside `assert' turns into an `undefined variable'. I can do it, if instead of `defsetf', I use `defun (setf ...) ...'. Is there a way to use `assert' within `defsetf'?
4:23:10
minion
didi, memo from pjb: there are downsides in using :type : then you won't be creating a new type, so it'll be harder to distinguish those structure instances from lists (or vectors). So you would do that, only when this would be the point.
4:31:41
Bike
in the expansion function, ONLY-NUMBER will be bound to a symbol. the expansion of setf will bind that symbol to whatever. so it names a place.
4:34:14
didi
Oh well. I should have actually tried, instead of reading the macro expansion. Sorry for the noise.
4:41:05
didi
Ah, right. The trouble program is https://paste.debian.net/hidden/cf0b6b87 . The issue is with the function parameter, not with the new value.
4:42:08
didi
Now SBCL complains. If I try (setf (my-place 0 (list 1 2 3)) 42), "Variable name is not a symbol: 0."
4:44:14
didi
I guess if I want to use `assert', I will have to live with the #'(setf ...) function call.
4:49:51
didi
OK, `(let* ((n ,n)) (assert (numberp n) (n)) (setf (nth n ,list) ,value)) works, but at what cost? Maybe it's better to use (setf my-place) after all.
4:50:46
pjb
didi: I think that the point is that when you use defsetf it doesn't create a (setf foo) function, but setf expands the expression inline.
4:53:18
didi
I also noted that (nth 42 '()) evals to NIL but (elt '() 42) signals a condition. Weird.
4:58:06
aeth
Well I expect the main difference to be that NTH will have an error if not given a list and ELT will work fine if given certain non-lists
5:02:58
pjb
Well, one could expect that elt would still avoid calling length on lists. So it could return nil or signal an error at the same cost.
5:03:18
pjb
But since nth already returned nil, it was more interesting to return an error, just like in the case for vectors.
5:51:00
beach
Yes, but I don't understand your first question. Mainly because I don't understand the grammar of the sentence.
5:51:59
sthalik
beach, there was this basic idea that the standard's immaculate, and it doesn't need anything new ever, at all
5:54:07
beach
sthalik: Also, fast portable sequence functions: http://metamodular.com/sequence-functions.pdf
6:19:20
sthalik
beach, having passed some datum to the pattern-matching macro, have the compiler guarantee that all cases are taken care of
6:26:46
aeth
You can define a member type with a custom macro that also defines a custom ecase. The custom ecase can verify that every member in the member type foo is a clause in the foo-ecase macro and only members of that member type foo. At compile time. Afaik. It doesn't sound particularly hard, either.
6:27:13
aeth
Now, that's just a tiny part of the problem, but I think the basic solution form would hold. Generate a function and a macro in a macro, and call that function in the macro to verify that the macro is valid
6:28:02
sthalik
aeth, compilers like SBCL have inference done on the matched datum. can you access that?
6:28:54
aeth
I don't think you can access SBCL's type inference. At least, I haven't seen a library do that. You'd have to use type declarations if you can't.
6:29:24
sthalik
aeth, can a pattern-matching library like that access, say, CHECK-TYPE or DECLARE TYPE?
6:30:06
aeth
specialization-store, an otherwise wonderful library for type-based generic functions, cannot access anything other than type declarations from DECLARE as well as FTYPE declarations afaik.
6:30:22
aeth
If you haven't seen it, this is the library. https://github.com/markcox80/specialization-store/
6:31:03
sthalik
aeth, but a pattern-matching library won't infer (or access the info from the compiler) whether the pattern is exhaustible, will it?
6:32:32
aeth
I don't think there's any more information available at compile time than the information that's in introspect-environment, but I could be wrong. If there is, it would be incredibly non-portable.
6:33:14
aeth
I'm guessing there isn't more because there are libraries that could benefit from more.
6:36:25
aeth
If someone could port some of SBCL's behavior to CCL, it would no longer become implementation specific!
6:41:07
aeth
sthalik: What do you have in mind? Can you put some invalid code in a pastebin that you wish would work?
6:44:59
sthalik
aeth, rather, what's potentially recognized as valid that ought be guaranteed recognized as invalid
7:00:44
lieven
ACTION must have missed the many times Harrop was right. The arrogant part is spot on.
7:03:04
sthalik
lieven, people engaging in the arguments on Lisp's side made a straw man out of type systems so Harrop had an easy time
7:05:06
sthalik
aeth, Lisp side: type systems peak at C89. pattern matching doesn't improve program flow
7:07:50
jackdaniel
sthalik: unless it is a type based on `satisfies', then function associated with it may compare object with anything
7:08:30
aeth
sthalik: The built in typed conses are... lacking in many ways. However, most implementations now (or hopefully soon) enforce :type in slots on structs, so you can create your own typed cons.
7:09:43
lieven
the lisp side argument was mostly that lisp is a dynamic language and that so far attempts to mesh a static type system with it are clumsy.
7:10:10
aeth
sthalik: https://gitlab.com/zombie-raptor/zombie-raptor/blob/93ddd7250aba57a22817defadf6cc45176109926/util/util.lisp#L402-463
7:10:32
aeth
It's getting increasingly messy, though, so I might use inline specialization-store specializations instead of prefixes.
7:11:17
aeth
The core of it is just a three line defstruct to have a car of type and a cdr of (or null type-cons)
7:11:37
aeth
Yes, it's not as powerful as a Lisp cons and is only for lists. A separate kind of cons could be created for trees that has less guarantees.
7:13:35
aeth
Now, there's lots of things about type systems that are lacking in CL, but typed conses via structs seem to be doable. Probably even immutable ones with :read-only, although probably not useful without the language itself optimizing them
7:14:35
sthalik
technically one can "freeze" a definition but then it's the "sufficiently smart compiler" fallacy
7:17:27
aeth
I do think that if CL has a weakness it's in its limited set of collections available, especially lacking in immutability and non-generic versions (except for specialized arrays).
7:18:26
aeth
e.g. If CL had built-in hash tables that could only hold type foo, then the compiler would know on the GETHASH what the type is (if it knew the type of the hash table), which would remove a lot of declare/the/check-type/etc.
7:21:21
aeth
One problem with :element-type is that you can't e.g. store (integer 0 10), it'll round it to probably (integer 0 15) or something.
7:21:50
aeth
Sure, internally, it should round it, but it would be nice if it actually remembered you wanted to store (integer 0 10) so the type information isn't lost across the function boundary.
7:23:29
aeth
SBCL has sb-ext:*derive-function-types* which when enabled allows the non-standard behavior of assuming that the ftype of a function will never change.
7:24:44
aeth
It's good to have that option, but you still lose information in data structures like hash-tables and lists
7:24:48
sthalik
what's the purpose of statically-knowing the element type being fixnum between 0 and 10?
7:25:42
aeth
If for some reason you add (- most-positive-fixnum 20) or something, it knows it stays as a fixnum and so uses much faster arithmetic