freenode/#lisp - IRC Chatlog
Search
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
8:51:46
flip214
jackdaniel: but the &aux should be indented quite a bit, which limits its available width for expressions
8:54:56
jackdaniel
you mean a situation where you have a long function name and start arguments in the same line, so when you start newline for &aux variables it is not at the same level as body?
8:55:30
jackdaniel
I'm not saying aux is perfect or any kind of silver bullet, I'm just saying that it is not as obsolete as phoe pictured it
8:57:38
dim
people, if you are interested in a nice design of a C program that knows how to handle both Out Of Memory and File System Is Full conditions, may I direct your study to PostgreSQL? it is very good at handling that (service does not stop, works again as soon as disk space is made or memory is back available)
9:06:00
flip214
jackdaniel: right. my aesthetic question is about the indentation: https://pastebin.com/mj5FkDSp
9:06:39
Cymew
I remember someone said that to study good C for style, tex.c was a good start. Maybe PostgresSQL is also a good study object?
9:10:06
Cymew
I got the crazy idea last week that I might want to try my hand at writing C again. I wonder how fast the wonder fades?
9:10:23
dim
it's one of those few software projects that has been incrementally improved year after year for more than 20 years now, with constant refactoring and new features, so it shows several techniques allowing for long term project maintenance
9:11:33
jackdaniel
writing in C is fine until you start feeling this burning desire to use a closure ;-)
9:12:23
verisimilitude
I had a conversation with a C programmer about how some interfaces are baroque and unamicable to writing software that works correctly in all instances.
9:12:42
verisimilitude
His response was, paraphrasing, ``Who wants to write software that works correctly in every instance?''.
9:13:14
Cymew
dim: That sounds interesting. I might have a friend of mine who write C++ for a living, and mostly does maintenance, what he thinks of the code base.
9:44:37
ogamita
jcowan: But precisely; using portability libraries should be done sparingly. Or at least, orienting the dependencies so that the core of your code doesn't depend on it.
9:47:00
ogamita
sjl: there's com.informatimago.common-lisp.cesarum.array:positions and positions-of-subsequence
9:50:26
Cymew
verisimilitude: "Who wants to write software that works correctly in every instance?" to me sounds like a very sloppy programmer.
9:53:33
flip214
Cymew: well, if "correctly" means eg. "on out-of space, write an error to the console and the syslog, wait for a human to help out, and tell me to recover" vs. "bug out with an error", I'd typically choose the latter ;)
9:56:27
jcowan
Yet if you are writing a network server, just for instance, then nonstandard code is at the very heart of your application. As I said before, this is not about non-portability, as a program can be quite portable without being standard.
10:00:41
ogamita
alandipert: you can use a with-functions macro. https://github.com/informatimago/lisp/blob/10db6f161a49004c814fe8c6ccfb8f196a0d5d79/common-lisp/cesarum/utility.lisp#L176 (let ((f (lambda (x) (list x x)))) (with-functions (f) (f 2))) #| --> (2 2) |#
10:15:56
flip214
phoe: I believe it doesn't. for display purposes I quite happily use the 'jq' utility for that.
10:17:49
aeth
verisimilitude: I assume 64-bit and ASCII or ASCII-compatible Unicode, as well as assuming that optimizing for SBCL doesn't de-optimize for other implementations. This isn't because I'm a bad programmer, it's because you have to make assumptions somewhere and you can't support every possible CL implementation, only the ones you can test on.
10:18:16
ogamita
What's bother me more about cl-ecma-48 (and the same would apply to my own com.informatimago.common-lisp.cesarum.ecma048 and other libraries, when presented as read material to newbies, is the lack of specifications. psq could read and compare both libraries, but it would be rather useless, given that neither give very explicitely and clearly the specifications that led to their structure and implementation choices.
10:18:18
aeth
The thing is, making those assumptions can make things much easier and much more performant, and it's easy to go back and fix it if it causes issues on any actual implementation, rather than a hypothetical standards-conforming one
10:19:45
aeth
verisimilitude: Good Lisp uses libraries like these: https://github.com/Shinmera/float-features/blob/master/float-features.lisp
10:19:50
ogamita
Therefore my advice, would be to read PAIP, since it gives complete examples of code, but explaining where it comes from.
10:20:25
aeth
verisimilitude: The behavior of float-features is completely outside of the CL standard, but it becomes in a sense its own de facto standard by trying to portably run in every possible implementation. And then you just have to worry about a library, not sb-foo, ccl-foo, etc.
10:21:29
ogamita
verisimilitude: your first use of #=/## in cl-ecma-48.lisp is very inefficient, since you will insert in the code a mapcar 3 times, that will have to be evaluated 3 times in each situation listed in the eval-when. Instead you could have just defined a lexical variable!
10:21:29
aeth
Though, yes, lots of libraries use something lazy like #| fast route |# #+sbcl sb-int:with-float-traps-masked #| slow route |# #-sbcl progn
10:22:58
no-defun-allowed
You could also just call the function you define in that let too, and maybe remove the let and make the let values defvars as they seem fairly important.
10:23:31
aeth
verisimilitude: Oh and as long as you never use upper case anywhere, you could just do *print-case* to :downcase when generating your documentation code, if that's what's making it upper case.
10:23:33
ogamita
&AUX should only be used in macros, to add a lexical variable for a body, without having to parse its docstring and declarations to insert the LET.
10:26:20
aeth
In fact, I think I've seen them in defstruct before, and only there, and that's why I was surprised that they weren't just a defstruct thing
10:26:34
shka__
ACTION is frequently using &aux for stuff like (lambda (value &aux (value (funcall key value)))
10:31:41
ogamita
Some conventions are enforced by tools, eg. emacs will indent comments differently according to the number of semicolons. Those convention are better respected.
10:34:09
ogamita
There are dictionaries of idioms for natural languages, eg. https://www.amazon.fr/Essential-Idioms-English-Collocations-published/dp/B00F3ZYLS4/ref=sr_1_11?ie=UTF8&qid=1545042785&sr=8-11&keywords=us+english+idioms
10:34:44
ogamita
But I feel that for formal languages such as programming languages, idioms are very much less essential, because any valid form as a specified semantics.
10:35:29
aeth
"idiomatic" in programming is more about "if I post this to #lisp or /r/lisp or usenet or http://planet.lisp.org/ or wherever can other people read it?"
10:35:42
ogamita
Most of the grammatical natural language sentences are meaningless. Only idioms and conotations may give them some kind of meaning. And when you dig a little, often it's not even much of a meaning anyways.
10:37:47
ogamita
Technical aspects such as readability of #1# vs characters, or efficiency, or risk of errors (#=/## let you build circular sexps, and it's not conforming to give circular code to a CL compiler or interpreter!), are more important (and the only valid basis for "idiomaticity" in programming languages, IMO.
10:39:21
aeth
Imo, all of the cleverness in Common Lisp should be reserved for certain special macros.
10:39:43
aeth
Most of the time where you use #. you can do something similar with a macro at macro time.
10:40:33
aeth
I'm not sure there's much use for any reader cleverness at all, except perhaps for literally embedding another language within CL (and whether or not that's a good idea, that can be debated)
10:42:16
aeth
e.g. Some people use reader macros for literal hash table syntax. I tried a library that used #H for that and it wasn't very good. It's imo better just to have a (hash-table* :foo 42 :bar 43 ...) macro
10:42:45
ogamita
jdz: defconstant is of very limited use in CL. It's just to let the compiler perform a small optimization of inserting fixnum or character literals as immediate data in the binary code.
10:42:46
aeth
(I think you'd only need literal hash table syntax if you wanted to print a hash table readably.)
10:43:46
aeth
ogamita: but most constants are numbers (not just fixnum/single-float) or characters or keywords or symbols, and they tend to work correctly as constants
10:46:47
ogamita
aeth: Actually, for bignums and symbols, some processors allow full addresses as "immediate" values in the instruction codes, but notice that some other processors (usually risc, such as powerpc), need 2 instructions to load an address!
10:47:31
ogamita
In any case, defconstant is specified only for this purpose. For example, it doesn't play well with CASE.
10:48:27
aeth
ogamita: defining your own CASE is so common there should be a DEFINE-CASE-MACRO just like how there's a DEFINE-MODIFY-MACRO
10:49:34
ogamita
verisimilitude: your friend is wise: he's learned not to want what he can't attain (with C).
10:50:50
ogamita
and people, remember there's downcase-lisp and upcase-lisp in https://github.com/informatimago/emacs/blob/9e4fa739e2b6b49cafdb3e14a4b5b01f70c70c0f/pjb-sources.el#L410
12:30:42
dim
I have a backtrace that begins with COPY-LIST, which my code doesn't call, I'm not sure how to see what leads to COPY-LIST?
12:31:39
dim
I mean the backtrace has 0: (COPY-LIST <struct instance>) 1: (PGLOADER.CITUS:CITUS-DISTRIBUTE-SCHEMA ...), and citus-distribute-schema doesn't call copy-list
12:58:10
dim
I've spent some time on a bug that was also triggering a bug in my own print-object methods, which isn't that easy to figure out really
13:13:57
flip214
neirac: like the uppercase first character of german nouns I think it's helpful to get a quick overview.
13:15:05
neirac
beach I agree with that, I prefer highlight-sexp package in emacs instead of full syntax highlighting.
13:15:34
beach
neirac: What would be really useful would be to highlight symbols according to their roles.
13:15:46
specbot
Notes about Style for Semicolon: http://www.lispworks.com/reference/HyperSpec/Body/02_ddb.htm
13:16:24
beach
heisig: So, someone who claims to know the language well has no excuse not to follow it. :)
13:30:48
_death
I think it's OK for newbies to read an eccentric program, if that's not the only program they read..
13:35:45
pfdietz
"Then cry as you realize how beautiful their code is, compared to yours, which is so flawed, you imposter."
13:36:03
beach
Of course, it is not unheard of that inexperienced programmers dismiss the LUV slides because the advice given by these highly experienced programmers is contrary to the personal taste of those inexperienced programmers.
13:37:49
jackdaniel
if someone is strongly opposed to some "rule" then I think they shouldn't apply it. this is just an opinion (even if shared by a lot of people)
13:38:18
jackdaniel
i.e experienced programmers may say, that dynamic typing is slow and unsafe, not necessary something we could agree with
13:38:38
jackdaniel
or even following norvig we could decide to switch to python (since he is more experienced programmer and his language choice *must be good*, right?)
13:38:42
dim
those slides are top-notch advices, but I have not implemented enough discipline to follow them
13:39:16
dim
jackdaniel: he said that Python is a good enough Lisp IIRC... well we might disagree on that?
13:39:32
beach
Sure, there is this other problem that programmers who have programmed a long time are not necessarily experienced. As the saying goes, in software development, many people don't have ten years of experience. They have one year of experience ten times.
13:39:50
jackdaniel
dim: exactly my point, I strongly disagree with that opinion of a hacker known for his experience :)
13:40:27
dim
my reading was more that he had to capitulate at Google and they paid enough for him to switch to Python
13:40:52
pfdietz
Are those like 10x programmers? (which are programmers who create enough technical debt to keep 10 others busy)
13:44:26
dim
shka__: https://github.com/dimitri/sudoku and https://tapoueh.org/blog/2012/07/solving-every-sudoku-puzzle/ cover bits of it IIRC
13:57:35
phoe
I want to print a long list, but the printer inserts # in some places. What does it mean?
14:02:05
dlowe
if you want it printed nicely, you can define a print-object method specialized on your object type