4 ms·

one thing I haven't found a solution for is how to make Lisp/Clojure play nice with version control and diffs you take something like this (defpackage my-

by geokon 7y ago

one thing I haven't found a solution for is how to make Lisp/Clojure play nice with version control and diffs you take something like this (defpackage my-package (:use :cl) (:import-from :alexandria :with-gensyms :curry)) and you want to add an item to the list.. so you need to change the :curry)) line to be :curry and then add a new item. anyone have a workaround? Of course if you had a lisp with no parans then you'd never have this problem to start with... defpackage my-package :use :cl :import-from :alexandria :with-gensyms :curry :new-thingy "Indentation is two lines per form" Emacs seems to always do one space for Elisp and Clojure and two spaces for 'let' and 'if' forms. or did I screw something up in my init file?

IronBacon 7y ago
I would add it at the beginning of the list instead of the end, if the list order wasn't important. I wouldn't put premptively the closing parens on a line alone tho.
- geokon 7y ago
  That would have the same effect of diffing two lines :)
  - IronBacon 7y ago
    Mmh, yeah. Sometimes I lack reading comprehension. So, I would think it's not a thing that can be solved with style guidelines, maybe a different diffing paradigm that handles elements addition or deletion from a list?
- malloryerik 7y ago
  Just out of curiosity, why not put the closing parens on their own line in the case of some rare instance when this improves functionality?
  - IronBacon 7y ago
    Probably because I learned to never put them on their own and now, when I see them, I found them somewhat awkward.
verisimilitudes 7y ago
This asinine importance of line-level differences is one reason I don't use these version control systems. In any case, the obvious solution is to add your new element as the new third entry, if you care about this. Now, moving on to this article, I agree with the parts of it that are directly influenced by the language, as that's clearly how one should write it; this isn't unique to this document nor to Common Lisp. I've had people criticize my Common Lisp just because I use parts of the language they weren't aware of or don't care for, which I find silly; people also enjoy trying to enforce usage rules where none exist and don't like seeing those broken, such as using #1= and #1# to indicate duplicated code where it's not otherwise easy to express. I disagree with using libraries merely because they exist. What, a lack of libraries is bad, but don't write more? In any case, I make certain all of my libraries are rather comprehensive and well-documented; that's not much in the way of advice, though, since it's obvious. Common Lisp libraries aren't likely to change significantly, especially after several years, which is nice. As for indentation, I generally use whatever Emacs gives me, except for LOOP, where I indent how I prefer it look; generally, two spaces is the indentation level, but here's an example where that isn't the case: (list 1 2) I agree with the line length note, as eighty is an asinine limit. I disagree with the comment conventions; I use a single semicolon for all of my comments. I use OR and AND for flow control more than WHEN or UNLESS, but this is my preference. There's nothing wrong with an IF that doesn't use both paths and claiming otherwise is silly arbitrary ruling. I further disagree with keeping conditions short; defining an entire function for a single condition is stupid. Having a single package to a file is treating Common Lisp like other languages; it's completely unnecessary. Avoiding :USE is another asinine quality of this style guide; again, libraries are unlikely to change significantly and you can always avoid using the most recent version. Using hierarchical names is a bad idea, since they're not actually hiararchical, but this could trick others into believing they are and, again, pretends Common Lisp is some other language. Lastly, I try to have my programs and libraries in a single file. What's nicer, looking through a single file or skulking around a large directory with many small files; I'll always prefer the former. If a file isn't even one thousand lines, why would you even consider breaking it into many files as other, poor languages are prone to do? This recommendation of ''Continuous Integration'' has nothing whatsoever to do with Common Lisp style and Common Lisp isn't a language that needs this. In brief, I don't care for this style guide, but it paints itself as authorative. My advice is to use Emacs and mimic the standard language where you can and, otherwise, do as you please until you derive your own rules; don't listen to others if you don't care to, although I believe my advice is good, you may disagree.
Grue3 7y ago
When I have a list of stuff that is likely to change often, I put the closing parens on their own line. Sure it's against the style guide but I don't care. Most commonly this affects list of slots in a defclass, long lists of local bindings in let/let*, long list of cond clauses and so on. As you might notice most of these have the form ((...) (...) ... (...)). Also in this particular case you don't have to put :new-thingy after :curry. They can be in any order, it doesn't matter at all.

by geokon 7y ago

IronBacon 7y ago

I would add it at the beginning of the list instead of the end, if the list order wasn't important. I wouldn't put premptively the closing parens on a line alone tho.

geokon 7y ago
That would have the same effect of diffing two lines :)
- IronBacon 7y ago
  Mmh, yeah. Sometimes I lack reading comprehension. So, I would think it's not a thing that can be solved with style guidelines, maybe a different diffing paradigm that handles elements addition or deletion from a list?
malloryerik 7y ago
Just out of curiosity, why not put the closing parens on their own line in the case of some rare instance when this improves functionality?
- IronBacon 7y ago
  Probably because I learned to never put them on their own and now, when I see them, I found them somewhat awkward.

verisimilitudes 7y ago

This asinine importance of line-level differences is one reason I don't use these version control systems. In any case, the obvious solution is to add your new element as the new third entry, if you care about this. Now, moving on to this article, I agree with the parts of it that are directly influenced by the language, as that's clearly how one should write it; this isn't unique to this document nor to Common Lisp. I've had people criticize my Common Lisp just because I use parts of the language they weren't aware of or don't care for, which I find silly; people also enjoy trying to enforce usage rules where none exist and don't like seeing those broken, such as using #1= and #1# to indicate duplicated code where it's not otherwise easy to express. I disagree with using libraries merely because they exist. What, a lack of libraries is bad, but don't write more? In any case, I make certain all of my libraries are rather comprehensive and well-documented; that's not much in the way of advice, though, since it's obvious. Common Lisp libraries aren't likely to change significantly, especially after several years, which is nice. As for indentation, I generally use whatever Emacs gives me, except for LOOP, where I indent how I prefer it look; generally, two spaces is the indentation level, but here's an example where that isn't the case: (list 1 2) I agree with the line length note, as eighty is an asinine limit. I disagree with the comment conventions; I use a single semicolon for all of my comments. I use OR and AND for flow control more than WHEN or UNLESS, but this is my preference. There's nothing wrong with an IF that doesn't use both paths and claiming otherwise is silly arbitrary ruling. I further disagree with keeping conditions short; defining an entire function for a single condition is stupid. Having a single package to a file is treating Common Lisp like other languages; it's completely unnecessary. Avoiding :USE is another asinine quality of this style guide; again, libraries are unlikely to change significantly and you can always avoid using the most recent version. Using hierarchical names is a bad idea, since they're not actually hiararchical, but this could trick others into believing they are and, again, pretends Common Lisp is some other language. Lastly, I try to have my programs and libraries in a single file. What's nicer, looking through a single file or skulking around a large directory with many small files; I'll always prefer the former. If a file isn't even one thousand lines, why would you even consider breaking it into many files as other, poor languages are prone to do? This recommendation of ''Continuous Integration'' has nothing whatsoever to do with Common Lisp style and Common Lisp isn't a language that needs this. In brief, I don't care for this style guide, but it paints itself as authorative. My advice is to use Emacs and mimic the standard language where you can and, otherwise, do as you please until you derive your own rules; don't listen to others if you don't care to, although I believe my advice is good, you may disagree.

Grue3 7y ago

When I have a list of stuff that is likely to change often, I put the closing parens on their own line. Sure it's against the style guide but I don't care. Most commonly this affects list of slots in a defclass, long lists of local bindings in let/let*, long list of cond clauses and so on. As you might notice most of these have the form ((...) (...) ... (...)). Also in this particular case you don't have to put :new-thingy after :curry. They can be in any order, it doesn't matter at all.