freenode/#lisp - IRC Chatlog
Search
1:52:35
Josh_2
I have https://imgur.com/ELuz2SF.png and https://imgur.com/8sPkVqG.png but when I try to call the following https://imgur.com/xzuHV0f.png I just get undefined function call, I thought if you :use a package in your own defpackage it pulls the symbols from that package into your new one
1:58:40
Josh_2
what am I missing with all this packaging stuff that means I can't call the functions from my the packages I :use?
2:01:23
aeth
Josh_2: you don't export 'write-pin you export '|write-pin| because you're using the symbol named "write-pin" not "WRITE-PIN". Things are upcased by default, not case-insensitive by default.
2:02:25
aeth
You can export "WRITE-PIN" and some people use it as a micro-optimization. This might be important if you're running it on a computer from the 1980s.
2:41:54
mister_m
When defining a macro, and using a let statement with a (gensym) invocation, is there a way I can provide a value to the let-binding in addition to having the macro expander generate a symbol for me? Or do I need to invoke (gensym) in one let binding, and then assign to the gen'd symbol in other using let*?
2:52:54
Xach
mister_m: i don't fully follow the question, but macros are just functions return source code, so you can use anything you like to form that returned code
3:00:49
mister_m
Xach right, but in a let binding i can provide a value (let ((thing "test")) ...) - can i provide a value if I also have to (gensym) the ``thing`` binding?
3:09:18
Xach
references to that symbol in other parts of the code only care about its identity, not its name or package
3:12:36
pjb
(let ((s1 (intern "FOO" #|in this package|#))) (unintern s1) (let ((s2 (intern "FOO" #|in this package|#))) (list (eq s1 s2) (symbol-name s1) (symbol-name s2) ))) #| --> (nil "FOO" "FOO") |#
5:59:28
mfiano
Is POSITION the idiomatic thing to use when checking for the presence of an element in a vector, when the vector can have nil elements and the element to be checked can also be nil?
6:01:26
mfiano
Ok. I'll just add a comment because I can see that confusing me at a later date (not using the integral return; this is simple for an ASSERT).
6:03:11
beach
The reader expects a Boolean value for IF and ASSERT, but POSITION does not return a Boolean value.
6:03:25
mfiano
Can you elaborate on the "don't do (assert (position ...)), or is that the PN/KP thing too?
6:04:25
aeth
beach: so would the correct behavior be to define a function that does (if (position ...) t nil) then?
6:05:13
mfiano
Is there a distinction in the spec that specifies that it cannot be a generalized boolean? Maybe I should just read this paper. Have a link, beach?
6:05:55
beach
mfiano: It has nothing to do with semantics. It has to do with the message that you send to the person reading your code.
6:06:22
beach
If we were only interested in semantics, there would be no problem with obfuscated code.
6:08:14
mfiano
Aha, ok. I was reading the title. That is the venue if I actually click through to one of them :)
6:15:21
mfiano
beach: So would you do (unless (null (position nil sequence)) t), (not (null (position nil sequence))), or other for ASSERT?
6:19:05
beach
Or more likely, I would signal an error, as in (when (null (position ...)) (error...))
7:28:49
pjb
beach: you are wrong: IF and ASSERT DO NOT EXPECT a BOOLEAN! They expect a generalized boolean. POSITION returns a generalized boolean. It's perfectly compatible with IF or ASSERT.
7:29:46
pjb
Of course, you are entitled to write your programs in a subset of CL, and nobody will reproach it to you. But people can use the full CL language.
7:31:11
aeth
it's funny that the three of us have different opinions here because I'd still say write a trivial function (inline it if performance is a concern, since its so trivial its implementation will never change) that is self-documenting in its name
7:47:20
beach
pjb: You must have read only part of the exchange. I explicitly said that it has nothing to do with semantics, and everything to do with communication with the person reading the code.
7:49:17
pjb
Still my point. (if (not (null (position …))) …) is a heavier cognitive load, to somebody who knows CL. When I see it, I start to wonder what's happening so special, why don't we just test (if (position …) …). And it's not even a double negation such as (not (not …)). You have to think hard to realize that it meant nothing.
7:50:01
pjb
beach: I realize that one can expect from smart and even not so smart compilers to optimize (not (null …)) out.
7:53:59
beach
I find it amusing that my arguments about conventions are nearly always met with individual opinions. Let me give a parallel concerning English prose.
7:54:06
beach
*I* might think it is fine to write text that has dangling participles, because after all *I* wrote it so *I* know what I meant. But that's not the point.
7:54:22
beach
The point is that even though *I* don't mind writing and reading such prose, I still don't write like that when it is meant for other people to read.
7:54:30
beach
When I write for other people to read, I can't ask each individual reader what they want, because I probably don't even know them. So I have to follow CONVENTIONS, whether I like those conventions or not.
7:54:32
beach
This aspect seems to be lost on many people here, very likely because they have little or no experience with working in teams, or with writing code that might some day be maintained by others.
7:55:11
pjb
beach: you are assuming what other people expect. I'm telling you that for me, it's harder to read (if (not (null (position …))) …) than (if (position …) …).
7:56:27
beach
I am not assuming what other people expect. I am posing that we should all adopt the same conventions, thereby getting used to what others expect. Of course, the way the community is made up right not, this is impossible.
7:58:06
pjb
When you call a function, you have to know what type of argument it expects, and what type of results it returns. If you write in a subset of the language that don't assume all the possible values, you are both limiting yourself and risking serious problems.
7:58:49
pjb
We see the problems all the time in C, because a lot of people don't know C, but assume some higher level language with C syntax…
7:58:50
MichaelRaskin
If you use English as analogy, let's consider the amazing convention of never splitting an infinitive and how it used to phrases that look tortured (and are still no easier to read)
7:59:02
fengshaun
is it possible to have the local copy of hyperspec be searchable (short of grep'ing the directory)?
7:59:39
pjb
fengshaun: there's a version of it in info format (it was distributed once with gcl IIRC).
7:59:47
beach
MichaelRaskin: That is not a convention. It is a stupid idea proposed by besservissers who have no training. Check Pinker for a more informed opinion.
8:00:38
beach
MichaelRaskin: I am quoting Norvig and Pitman for a reason. I consider them the analogue of Pinker.
8:01:07
MichaelRaskin
beach: it _is_ literally a convention. A Convention produced by people who didn't understand what they are doing, but now (unfortunately) widespread enough to become a convention in many places.
8:01:45
MichaelRaskin
I know that a lot of conventions proposed make code harder to read for me whenever they are literally followed
8:02:59
beach
MichaelRaskin: They only make it harder to read for people who stubbornly refuse to follow conventions established by smart, experienced, and knowledgeable people like Norvig and Pitman.
8:03:29
aeth
I personally follow a version of WP:IAR (ignore all [the] rules) in my projects. https://en.wikipedia.org/wiki/WP:IAR
8:03:45
aeth
e.g. my line length limit is 100 lines, but I go over that in a few places, because sometimes it makes things less readable to put a fake break in
8:04:20
beach
I think I totally fail to get this idea across, and I shouldn't be surprised. I will stop trying now.
8:04:29
MichaelRaskin
beach: when people who actually follow the specific authority are not easier to find than people who think this authority is harmful...
8:04:51
pjb
beach: and there is old code that you still have to be able to read. This is why I think my approach is better: stick to the CLHS.
8:05:12
beach
pjb: Yeah, and the other day we saw someone saying that "Norvig is a traitor", so we shouldn't listen to him either. Sheesh!
8:06:17
aeth
Speaking of Python, I think Python's a bit too dogmatic on the side of having one true style that must never be violated. CL generally seems to be a nice middle ground, keeping important conventions like parentheses, comments, and indentation (unlike C and C++, where indentation and bracket management is a bit of a nightmare)
8:06:18
MichaelRaskin
The idea that following a convention that doesn't fit one's way of thinking about things (and of writing in other languages) will make this convention feel natural is pretty optimisitic
8:07:12
aeth
In some languages, I have to use CamelCase libraries in my underscore_case project and, well, it's a bit ugly
8:07:36
MichaelRaskin
Which means that my mind will adapt to the entirety of what I do, not just to a specific style of Lisp
8:08:31
MichaelRaskin
(and of course if writing style conflicts with the mindset used for planning out the algorithms, either the latter wins out, or I become worse at making code correct)
8:12:53
pjb
Also, the question of style in Lisp cannot be resolved globally, because you can use different programming styles (and worse, mix them!) when you use embedded DSLs, or merely a new macro. Each program, each function can have its own style!
8:15:42
aeth
Imo... Programming is like art, as a special case of writing. You need conventions. You need to know the conventions. You need to mostly follow the conventions. But once you're good enough, you can break conventions in certain places.
8:16:00
aeth
Dogmatic linters to enforce 100% usage of conventions are too easy for programmers to write, but they're not necessarily the right thing to do.
8:16:03
pjb
A lot of programming team try to enforce a uniform style to depersonalize the code (and then use git history to find out who wrote what), but I like it when each programmer has a personal style and this can be seen in the code.
8:16:39
pjb
(By the way, recently AI algorithms determined that Molière wrote his pieces alone, and that Shakespear had help…).
8:26:55
no-defun-allowed
MichaelRaskin: Sticking to one convention for all languages is probably very, very bad. The closest to writing "Lisp" layout in C could be the GNU standard, and the reverse is the stuff you get on #clschool on a very bad day.
8:27:05
aeth
pjb: That sounds impractical. The Google Common Lisp Style Guide seems more pragmatic because a lot of the time when more than one convention exists, it says to use the existing convention in an area, which helps keep things somewhat locally uniform.
8:29:18
aeth
Well, I guess it's kind of vague there, too. e.g. "Choose wisely, but above all, consistently with yourself and other developers, within a same file, package, system, project, etc."
8:31:30
MichaelRaskin
no-defun-allowed: it's never the same convention, but some consistency of approaching semantically the same things
8:32:33
no-defun-allowed
Perhaps C and Lisp are a worse pair than average, but I don't think I would expect to write things with similar semantics in those, either.
8:33:14
aeth
MichaelRaskin: The problem is that Lisp's expression-oriented nature leads to very different idioms than in most languages. There's no need to set an intermediate variable in a COND, or even return to an intermediate variable in a COND, or even use a COND where an IF will do even if it would look too ugly/complicated with a "? ... : ..." ternary in most languages
8:36:20
aeth
The thing is, in CL nearly everything has a return value (only (values) doesn't, unless someone wrote code that returns (values), which is very unidiomatic and almost always implicitly inserts a NIL, anyway)... and almost all of those return values are meaningful (although it's kind of 50/50 with NIL)
8:37:23
aeth
CL for some reason is even more consistent and ideologically pure here than Scheme (very surprising), which often returns #<unspecified> or some other incredibly literal interpretation of its specification... which can mean different code even betwen CL and Scheme, two very close languages.
8:37:36
easye
I know someone who uses that to indicated that they have thought about the return at that point in the function and declare that it should return without values on purpose.
8:41:21
easye
(VALUES) Is actually preferable than RETURN-FROM 'cuz it makes changing function naming more difficult which often leads to mistakes.
8:44:27
easye
Still, I am probably happy to have RETURN-FROM require one to name the function that one is returning from, as I get a warning at compile time rather than have the program misbehave.
8:45:20
pjb
(defun foo () (block this-function (return-from this-function 'foo))) s/foo/bar/g (bar) still works.
8:46:33
pjb
(defmacro mydefun (name arglist &body doc-decls-and-body) `(defun ,name ,arglist ,@(doc-and-decls doc-decls-and-body) (block this-function ,@(body doc-decls-and-body))))
10:05:25
smokeink
How to tell asdf / sbcl to use the :system-cache ? :system-cache uses the contents of variable asdf::*system-cache* which by default is the same as using ("/var/cache/common-lisp" :uid :implementation-type) http://soc.if.usp.br/manual/cl-asdf/asdf/Controlling-where-ASDF-saves-compiled-files.html#Controlling-where-ASDF-saves-compiled-files
10:06:39
smokeink
I'm reading that doc page but I don't really grasp it. What to write in .sbclrc in order for it to use the system cache
10:10:14
jackdaniel
smokeink: I'm not aware of *system-cache* in asdf, maybe try setting *user-cache* instead?
10:11:23
smokeink
https://www.reddit.com/r/lisp/comments/23azqf/need_help_setting_asdf_cache_output_directory/
13:10:16
Xach
Yes, sorry, just missed the window. But I hope not to wait until the end of december for the december update.
13:10:42
Xach
This month's problems were caused by two libraries not working well together, compounded by my build hardware crashing sporadically
13:14:36
Lycurgus
so that, in your place, if debian is to be the reference, i'd wait a year from realease
13:20:02
jackdaniel
I imagine that testing just on one platform vs one implementation vs all libraries is demanding task
13:22:44
jackdaniel
Lycurgus: could you set such CI for current ql distributions? I think it would be useful for package and implementation maintainers regardless (I could use some reports for ecl i.e)