freenode/#lisp - IRC Chatlog
Search
22:14:56
dim
if I (push :pgloader-image *features*) from a file where then I call sb-ext:save-lisp-and-die, should I expect the image built as a result to have #+pgloader-image?
22:34:04
dim
basically I want some handler-bind, lparallel:task-handler-bind and handler-case to act differently when in an interactive SLIME session and when in an image, to help me with debug facilities (empty condition handling) and to print something non-interactive when /usr/bin/pgloader is being used by a non CL developer
22:34:34
dim
seems I'm missing some things here and there still in the new save.lisp that I intend to use instead of buildapp when it's ready
23:52:11
sjl
Is there something like POSITION-IF that would give me a list of ALL positions that satisfy the predicate, instead of just the first?
23:52:26
sjl
(I can (already have) easily write my own, just wondering if there's something clever built-in I could use)
23:58:15
sjl
I think http://paste.stevelosh.com/8f7bed46c7fb4ca8bf8038741ed6f7e3bb4a6261 is probably good enough for what I need
0:18:03
verisimilitude
You can simply MAP the predicate and then have a SEQUENCE of where it does and doesn't aply, sjl.
0:19:03
verisimilitude
You could easily transform such a SEQUENCE into positional numbers or skip this intermediate step entirely.
0:21:14
sjl
Preferably it should use O(elements that satisfy the predicate) memory too, though I could live without that
0:21:52
sjl
Mapping the entire thing and transforming will allocate memory even for stuff that doesn't satisfy the predicate, which is a waste if only a couple of things do
0:23:51
verisimilitude
I write LOOP assuming COLLECTING is O(1), which any decent implementation would use.
0:24:36
sjl
But yeah, I'll just use my util function that I pasted earlier. It's efficient and works
0:24:44
verisimilitude
This is, again, just a basic implementation, of course; it works for what you want.
0:24:52
sjl
and it's not like I don't already have a giant utils library. what's one more function thrown on the pile
2:58:59
alandipert
is there a way to define a local function that has the function value of some expression? so that it can be called locally without funcall
3:01:39
alandipert
i was hoping to avoid funcall/apply but hey, this is CL, i need to learn to love lisp-2 :-)
3:02:11
verisimilitude
You could get away with using a symbol macro for this, I suppose, depending on what precisely you're doing.
3:02:32
alandipert
actually i think i figured out a more elegant way that doesn't need require doing this
3:21:07
psq
or perhaps I shouldn't worry about "approachability" and just go for what seems interesting?
3:22:05
verisimilitude
Alright; I have a well-documented terminal control library written in pure Common Lisp in less than one thousand lines.
3:23:36
verisimilitude
I've also written it to assume nothing about the character set the implementation uses, so it performs some tests for suitability and optimizes in the case of ASCII.
3:24:31
PuercoPop
pfdietz: Been skimming over the fuzzy-testing code in your ansi-test repo. Pretty cool. One question, what would 'something useful' on package errors be? build a list of the symbols that caused the package errors?
3:25:45
pfdietz
For the reader, it would suffice to have a restart so the code invoking the reader could suggest a package.
3:26:37
pfdietz
The goal of that was to stripmine a large corpus of Lisp for forms that are sort of reasonable.
3:27:10
pfdietz
And then mutate those and recombine them and throw them at the SBCL compiler, trying to get the compiler to signal errors.
3:29:44
pfdietz
I pulled in code from the entire quicklisp distribution and a bunch of other public lisp programs.
3:37:25
pfdietz
I would have liked to have read everything in the actual packages, but that's not possible if I want to read all of quicklisp, as there are many package name collisions.
4:24:43
beach
Commented-out code gives a very strange impression. What is the person reading the code supposed to think?
4:26:55
beach
Comments inside top-level expressions to be aligned with other expressions take two semicolons.
4:27:49
beach
Instead of using reader labels #= and ##, define an abstraction like a function or a macro. Code like that is quite unreadable.
4:29:59
beach
verisimilitude: I think it was a mistake to recommend your code as the first code for psq to read.
4:31:34
verisimilitude
ACUTE-TERMINAL-CONTROL is still a work in progress, but I will defend CL-ECMA-48 as something that is rather finished and good.
4:32:06
beach
verisimilitude: Why do you recommend unfinished unidiomatic code to read for a beginner?
4:32:56
verisimilitude
I recommended ACUTE-TERMINAL-CONTROL because they also wanted something interesting.
4:33:36
verisimilitude
I told them to read CL-ECMA-48 first, anyway; do you have any criticisms that apply to that, beach?
4:34:55
equwal
versimilitude: Because you need version control and git is the best version control system.
4:35:25
beach
verisimilitude: Your code seems to use car/cdr/rplaca/rplacd a lot. That indicates a lack of abstraction.
4:35:58
verisimilitude
The code in DEFCS could be cleaned a tad by introducing more variables to store some results, and I may do that, but it's still fine and nice.
4:36:01
beach
verisimilitude: They are not irrelevant. If you want to expose your code to others, especially to newbies, make sure you follow the established conventions.
4:37:20
beach
verisimilitude: I respect that, but then don't expose your code to others. Especially not to newbies.
4:37:57
beach
verisimilitude: It would be better to wait for a more idiomatic recommendation than to expose unidiomatic code.
4:38:06
equwal
verisimilitude: I don't have recommendations because I'd rather use my time doing something other than reading that.
4:38:44
verisimilitude
That's what the code actually looks like, equwal, and the actual program isn't written like that.
4:39:00
beach
psq: If you could tell us your current level of knowledge, the kind of code you would be interested in, and what other languages you already know, better recommendations could be given.
4:40:36
alandipert
i have a cyclic relationship between a struct and its :print-function (the print function uses accessor functions created by defstruct). is a "forward declaration" like (declaim (ftype (function (t t t) t) print-node)) the most reasonable way to muffle complaints about undefined functions?
4:41:01
equwal
Best recommendation: Make a git repo, put your code in Emacs, M-x downcase-region the code.
4:41:30
verisimilitude
Again, the actual cl-ecma-48.lisp isn't like that, equwal, if you'd actually look at it.
4:42:10
verisimilitude
I'd rather rid myself of torvalds' software than become more dependent on it, equwal.
4:42:28
Bike
alandipert: i think you should just be able to (defstruct ... (:print-function foo) ...) (defun foo ...) and that will be fine
4:43:18
minion
psq: 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).
4:43:28
alandipert
Bike thanks, that works, but sbcl emits a style warning about the undefined function that i wish to suppress
4:44:05
beach
psq: I seriously think you should skip the code that verisimilitude recommended. It is not idiomatic and verisimilitude doesn't think it is important to follow established convensions.
4:44:34
beach
psq: But to a beginner, it is absolutely essential that the code follow established convensions.
4:44:34
alandipert
oh, duh, they're in the same file but i'm not loading the file. i'm evaling things form by form manually in slime
4:45:07
beach
verisimilitude: You don't get it do you? It is not about your taste. It is about established conventions.
4:45:14
verisimilitude
You can read my program and see a rather finished, well-documented, well-used, and entirely portable Common Lisp library or you can follow the vague suggestion to read programs in a book, with no particular examples, psq.
4:45:58
psq
beach: I've looked at the books, I was thinking more along the lines of a project that I could wrap my head around
4:46:25
verisimilitude
Well, I still recommend my programs, psq, although I'm not looking for contributions.
4:51:12
beach
psq: Here is a library I am fairly proud of: https://github.com/robert-strandh/Cluffer
4:53:11
no-defun-allowed
would it be a good idea to split out any protocol defining code like defgenerics into another file?
4:53:39
beach
verisimilitude: What source did you use to determine the idioms of Common Lisp? Since you don't agree with my assessment, that means you think your code is idiomatic. Or do you think you are so good that you can establish the idioms yourself?
4:53:46
psq
Thanks for the suggestions, I'll check them out. I'd love to get into SBCL, I have a feeling I'll have to work up to that though
4:54:17
beach
psq: Yes, that might be tricky. If you want some compiler code, Cleavir will be easier to understand.
4:54:58
beach
psq: Check the Code/Cleavir subdirectory of SICL for that: https://github.com/robert-strandh/SICL
4:57:46
verisimilitude
I think your bemoaning my comments is irrelevant, considering there's few of them and the conventions you mention are, at best, a suggestion mentioned in passing.
4:59:11
verisimilitude
If you look at the original question, psq asked for ``approachable'' codebases.
5:00:12
verisimilitude
You're talking about the examples I gave in the documentation, no-defun-allowed?
5:01:21
no-defun-allowed
and if you're going to call xterm r*tarded you should do it at the bottom of the docs preferably in a low-contrast colour scheme
5:02:27
verisimilitude
I will concede that, at least at this point, ACUTE-TERMINAL-CONTROL isn't necessarily approachable, sure.
5:03:00
verisimilitude
I think CL-ECMA-48 is fine, though; I have five macros that do all of the work and everything's well-documented.
5:12:57
aeth
I think it's a lot clearer to use (list) (destructuring-bind (foo) list ...) instead of (list &aux (foo (car list)))
5:14:45
aeth
I don't think &aux should really be used. It doesn't even save a line in most cases. If your lambda-list is too long then each element should be on its own line so (... &aux (foo 42)\n(bar 43)\n(baz 44)) doesn't actually give you more lines over just having a let.
5:15:39
aeth
So you actually use one *more* line over the let, although you do have less indentation and one fewer level of parentheses
5:17:19
verisimilitude
If I'm to choose between a LET* to start the body with or an &AUX, I'm always going to choose the latter.
5:18:21
verisimilitude
It usually does save a line; can be considered more clear since you no longer need to see if the LET* applies to the entire body or not; and it does result in less indentation, which is good.
5:19:02
aeth
It only saves lines if you use your horrible style of (foo bar baz foobar\nquux foobarbaz barfoo) multiline lambda lists that should fail any code review.
5:19:06
verisimilitude
You can make the argument that properly-indented code does make it easy to see if a LET* always applies, but with an &AUX it doesn't matter if the code is well-indented; you know it applies to the entirety.
5:20:14
aeth
&aux encourages function-level scope for variables, which should be used as rarely as possible. Everything should have the tightest scope possible.
5:20:42
aeth
The latter behavior really makes it easier to refactor into smaller functions is a function grows too big
5:22:39
aeth
I just did a search and only a handful of libraries seem to use &aux (including stumpwm, unfortunately)
5:22:44
verisimilitude
If you're referring to the functions my DEFINE-CONTROL-FUNCTION generates, then there's clearly no need to refactor, since they're all automatically generated, and all I use the &AUX for is some special variables that are harmless to bind like this.
5:23:45
verisimilitude
I'm not insulting you, but I do find it a tad odd to not be aware &AUX exists and then to decry its usage.
5:24:34
verisimilitude
I learn languages by mostly reading standards and reference material beginning-to-end, so I don't tend to use a language until I'm at least well acquainted with all or most of it.
5:24:54
beach
verisimilitude: I would like to know YOUR source of idioms since you claim your code is idiomatic.
5:25:09
verisimilitude
So, what I mean is I never used CL:LAMBDA without being aware of &AUX, I don't believe, or at least not for long.
5:25:32
aeth
When people very familiar with the language have lack of familiarity with a feature, it might mean that that feature is discouraged idiomatically, like PROG or &AUX.
5:26:23
verisimilitude
I really don't see what's particularly unidiomatic about my programs, beach. All I'm doing is using what the language provides.
5:26:27
aeth
I learn by reading and writing a lot of code. If I've never encountered something at this point, that probably means that (almost) no one uses it.
5:26:54
beach
verisimilitude: I see. You don't understand the difference between grammatical phrases and idiomatic phrases. That's very interesting.
5:27:11
verisimilitude
I'd argue it's far worse to bring in a library such as ALEXANDRIA for trivial purposes. I'm not familiar with this ALEXANDRIA and I see so many programs that bring it in for such trivial things. This is just an example.
5:28:01
aeth
verisimilitude: Idiomatic usage of the language is writing code that other people are able to read and that other people would be able to take over maintaining if you stopped writing it. It's probably the most important part of using any programming language.
5:28:25
verisimilitude
In case it's not clear, I don't really spend much of my time reading other Common Lisp programs. I'm using the language well and in clear ways and never concerned myself much with patterns I didn't want to make macros.
5:28:29
beach
verisimilitude: Er, you just said you use what the language provides. That would be the grammatical phrases. Yet, you claim your code is idiomatic?
5:29:01
aeth
I mean, my programs aren't particularly idiomatic, either, but that means I have to document things heavily. (length (documentation 'define-function 'function)) => 2565
5:29:12
beach
verisimilitude: Oh, so you just said that you don't care whether your code is idiomatic or not. So you DO agree with my assessment, but you don't care.
5:29:49
aeth
I try my hardest not to surprise people even though a lot of my code isn't very idiomatic because of my custom macros, and I do that with substantial documentation (and I don't document enough). But I know the idioms and intentionally violate them in places, e.g. using 'foo?' instead of 'foop'
5:30:01
verisimilitude
I'm being told that using a standard lambda list keyword is unidiomatic, so I really don't care for what's considered idiomatic, then.
5:30:18
aeth
I'm perfectly capable of writing 100% idiomatic CL, and I do that in many programs when I don't want to pull in my extensive libraries and/or when I want to share it.
5:31:13
verisimilitude
Oh, yes, using ``p'' and ``-p'' for predicates is one of the few conventions I'm aware of and always follow.
5:31:42
aeth
verisimilitude: There are a lot of bad conventions and ideas in Common Lisp due to compatibility with historic Lisps. e.g. names like rplaca
5:31:53
verisimilitude
I find it amusing that you're calling my code unidiomatic while not even following that convention, aeth.
5:33:15
verisimilitude
There are very few and I really don't care if someone thinks I don't use enough semicolons.
5:33:23
aeth
Programming is art, and the best art breaks the established rules in places, but the artist first needs to learn those rules in order to violate the rules properly.
5:33:58
verisimilitude
So now I don't know the rules of the language, but I know more about the language than you do, it seems?
5:34:28
aeth
You overuse one obscure feature of a lambda list. That doesn't mean you know more of the language than I do.
5:35:15
aeth
There are plenty of people here who might know more of the language than I do. beach and Bike, for instance.
5:35:46
verisimilitude
Now, why don't you make a list of these idioms, beach, and I can tell you how many I've internalized and just didn't recall offhand and how many are just things you happen to like, such as your mistaken ideas concerning protocols.
5:37:47
aeth
ebrasca: This is the code we're talking about, I think: http://verisimilitudes.net/2017-12-31
5:41:38
aeth
verisimilitude: I would definitely throw quite a few DESTRUCTURING-BINDs in there. "caddr", "cadr", etc.
5:42:09
aeth
I caught a few bugs when I switched my style from CXR to using DESTRUCTURING-BINDs just about everywhere.
5:43:41
aeth
all stuff like CAADR do is hide implicit structure that DESTRUCTURING-BINDs can make explicit.
5:44:53
aeth
Additionally, those functions don't check the tail. With DESTRUCTURING-BIND, you have to explicitly ignore the tail like (destructuring-bind (foo bar &rest rest) (declare (ignore rest)) ...) which (if you don't do that) means you can catch non-conforming syntax you wouldn't otherwise catch.
5:46:26
aeth
verisimilitude: You may or may not have more cover-to-cover knowledge of the standard, but you don't know *when* to use what if your code is full of CAADRs imo.
5:47:32
verisimilitude
However, I didn't want to glut the code with frivolous checks, so I wrote the DEFCS code to carefully generate invalid code that would be caught by CL:LAMBDA, if my rules are violated.
5:49:00
aeth
And instead of ,@(mapcar 'caddr g) you should either (1) use destructuring-bind to reduce the problem so you're using a simpler function (in this case, car?) or (2) name it as an inline (if you care about performance so much) accessor macro like (defun foo (x) (caddr x))
6:06:10
verisimilitude
The code in DEFCS could be improved, yes, although I'd thought my documentation made up for it. I'll try to get it cleaned by the end of the year so I don't add more years to the copyright notice.
6:07:40
verisimilitude
I'd thought that by showing the macro usage and the code it generates, that was enough to sate most and would be a good aid to anyone wanting to fully understand it. I document the main cases of code generated.
7:51:28
phoe
verisimilitude: sure, your code is standard, but &AUX isn't used in most contemporary code, as agreed by means of an informal consensus of a bunch of lispers that has been perpetuated for some time now. Therefore a newbie who encounters that code might be confused about the features that are rarely used elsewhere. Sure, it's a good training in "this is standard Common Lisp", but it's a poor training in "that's
7:51:34
phoe
what the majority of contemporary Lisp code looks like and therefore what you can expect to see".
7:53:05
phoe
Which is why, to me, &AUX lands in the same place as symbol property lists, rplaca/rplacd, and a bunch of other things I can't recall off the top of my head at the moment - stuff that I won't use in code I write now.
7:53:13
dim
I've mostly seen &aux used for boa constructors in defstruct when handling with inter-dependent slot values being computed at instanciation time
8:13:12
verisimilitude
I've been thinking about what it means for there to be an idiom in Lisp, due to this conversation. I think there really aren't many idioms that are commonly agreed upon. The predicate naming came as one that few disagree with and I recalled a reason why that's the case: It's supported by the language itself through DEFSTRUCT.
8:13:36
verisimilitude
It's not a requirement to name predicates in this way, making doing so a convention, but it is nonetheless reinforced by the language.
8:14:21
jdz
There are also quite a few predicates defined in the language following that convention.
8:14:23
verisimilitude
There really aren't many idioms that qualify for this. Though I do recall one fellow getting rather angry at me when I told him Common Lisp was a language that supported English first, as it has facilities for generating English in FORMAT; that's a thought.
8:15:46
verisimilitude
Yes; I was just listing the sole exception that came to mind immediately, for effect.
8:15:59
verisimilitude
Another idiom would be the WITH- macros. I'd think Lisp has fewer idioms not only due to the freedom permitted, but also because macros eliminate repetitive code.
8:17:15
verisimilitude
But, really, I find it absurd to have people here tell me my code is unidiomatic because it uses things they don't like or weren't even aware of.
8:17:39
verisimilitude
It rubs me the wrong way and I'm glad I made my own understanding of Lisp rather than just asking others for their thoughts.
8:18:24
verisimilitude
As an example, this is #lisp, but there's no official Common Lisp IRC channel.
8:18:40
verisimilitude
Similarly, I just don't get the impression there's much of a set of established idioms.
8:18:55
phoe
There won't be an official Common Lisp channel because there's no one to make it official.
8:19:08
jdz
Some people ignore the commenting conventions (different number of semicolons); I find reading the code painful.
8:19:15
verisimilitude
What I mean is it's not like, say, Rust, where there's an official subreddit, mailing list, and other garbage.
8:19:31
phoe
So social constructs is as close as Lisp can get when it comes to idioms, conventions, and so on.
8:19:45
verisimilitude
Sure, beach, but I used Common Lisp for years, in my own Lisp community, without being aware this one even existed.
8:23:24
beach
verisimilitude: I think you are missing something essential. What is idiomatic and what is not, is rarely decided by some central power. And that goes for natural languages as well as programming languages.
8:23:29
beach
Just as a novelist must follow conventions of typography, of character building, etc, in order to be understood by readers, a programmer must use the conventions established over many years by experienced users in order for the code to be understood and appreciated by others.
8:23:30
beach
There is no central place where there is a list of idioms, not in natural languages and not in programming languages. Instead, you learn these idioms by years of studying what other authors do (something you refuse to do, apparently).
8:25:36
verisimilitude
Unlike Common Lisp, Ada is a language that actually enforces some conventions, at which point they stop being conventions.
8:26:22
verisimilitude
It would be easier to discuss what isn't idiomatic Common Lisp, beach, and the main example that comes to mind is modifying the reader table greatly, since that's very uncommon.
8:27:40
verisimilitude
As for conventions of programming in general, I'm not going to respect the conventions of a field that is less than a century old and still does many things wrong. So, I feel perfectly within my common sense and whatnot to do whatever I want when it comes to programming.
8:28:08
verisimilitude
There is very little in programming, compared to the whole, that is actually worth doing, because there's so many idiots writing software who don't know what they're doing.
8:28:46
verisimilitude
Of the Common Lisp that I do look at, I find that a great deal of it doesn't follow the standard perfectly, by assuming whatever SBCL does is the standard, assuming ASCII or even UTF-8 is the character set, or something else I find stupid.
8:29:24
flip214
verisimilitude: that's the same in every programming language, as far as I can tell.
8:30:06
flip214
verisimilitude: even if the field is not that old, there are still people that have been working in it for 40 or more years - and so they have a bit of experience.
8:30:30
verisimilitude
So, I'd much rather write a program that perfectly adheres to the standard where possible, even if it can get messy, and that seems relatively uncommon, where programmers are content to have it work on three or four implementations and don't care about the rest.
8:30:50
flip214
but when building a house there are still people who don't know what they're doing, and we've been doing _that_ for a few thousand years now ;)
8:30:56
dim
wow, this rant reminds me of my favorite Dilbert of all times: The direction acknowledge that we have a problem of communication in this company, but doesn't want to speak about it.
8:31:05
verisimilitude
It unsettles me when I look at a Common Lisp program and the main comment is ``This works on SBCL. Don't know about the others though.'' for something that has no place being unportable.
8:31:36
flip214
verisimilitude: unless CFFI, SB-* packages, etc. is involved, chances are very good that it's portable.
8:32:12
verisimilitude
The point is that it seems an unfortunate amount of Common Lisp code is only ever tested on SBCL and I'm perfectly happy not following the crowd when it comes to that.
8:33:10
jdz
verisimilitude: I've missed the beginning of this discussion. Can you point me to your code that started this?
8:33:36
flip214
verisimilitude: on the other hand, CL _has_ a standard - and a few implementations claiming to be compatible. so what's the point of testing standard-conforming code on every implementation?
8:34:01
verisimilitude
Well, I meant that people both don't know the standard and also don't test their code on multiple implementations.
8:34:40
verisimilitude
Now, a primary difference between programming and building houses is people actually care when the average house doesn't work, because that usually means someone died; programming has no same level of rigor for the average case.
8:35:27
flip214
verisimilitude: uh, yeah, but a small badness multiplied by a few million times is a big badness again (think smartphone app crashing)
8:37:16
verisimilitude
I have an iteration of a program in Common Lisp, but there's no standard way to recover from a STORAGE-CONDITION, which is one reason it's not quite reliable enough for my tastes.
8:40:13
verisimilitude
That really just means if you want to be able to handle memory exhaustion, your options are using implementation-specific mechanisms or not using Common Lisp.
8:40:46
jdz
verisimilitude: Your code looks very hard to read to me. All-caps, really? If you're going for the old-school terminal feel, why are your lines longer than 80 columns?
8:40:48
verisimilitude
For a C program, the popular handling method is to continue with garbage or die immediately.
8:41:07
flip214
yeah, but you can't do better than to close the file you're writing to, delete it (as it's half-written anyway), log an error, and hope for admin help.
8:41:43
verisimilitude
I have a program design that can handle it, actually, because it only uses unbounded memory consumption for a few things.
8:41:53
jdz
And I'd agree with anybody complaining about using sharpsign equal-sign reader macro in the code.
8:42:48
flip214
well, of course you can use (RUN-PROGRAM "resize2fs" ...) etc., but that might not be a good idea generally. So the options for handling "external" errors are limited anyway.
8:43:47
verisimilitude
What happened was I'd obsessed over a design, mulling over its memory behavior, and decided I should make it resistant to memory exhaustion since it could be made resistant.
8:45:06
flip214
but you won't stop other processes from allocating memory and running the whole _machine_ OOM. so non-consing is all good and nice, but you still have to plan for external interference - not all of which can be handled.
8:46:00
verisimilitude
I understand what you're telling me, flip214, but I don't want to bloviate about my particular program, the design of which can and will account for these things in the Ada reimplementation.
8:46:27
jackdaniel
phoe: aux is a very fine mechanism to avoid whole-body let, I don't buy your argument that some vague lispers consensus deemed it bad