libera/#commonlisp - IRC Chatlog
Search
7:11:09
phantomics
Is there a reason I can't alter lists that are properties of objects? For example...
7:11:34
phantomics
If I do this: (setf bbb nil) (setf (getf bbb :cc) (list :ee)) (setf (getf (rest (getf bbb :cc)) :ii) 10)
7:13:03
phantomics
However, if bbb is replaced with (obj-plist myobject), where obj-plist is the list accessor for the class of myobject, then the list does not get changed
7:21:37
pjb
phantomics: this is not a valid p-list: (progn (setf bbb nil) (setf (getf bbb :cc) (list :ee)) (setf (getf (rest (getf bbb :cc)) :ii) 10) (getf bbb :cc)) #| --> (:ee :ii 10) |#
7:24:15
phantomics
That way it can be passed to various places and it'll share the same storage everywhere including newly added properties
7:30:43
phantomics
Here it is, should be somewhat clear. The shape-of method populates a metadata slot that's part of an object, while the render method attempts to modify a part of the metadata
7:32:16
phantomics
I've also tried (setf (getf (rest (getf (varray-meta varray) :gen-meta)) :index-width) stuff) and that doesn't work either, (varray-meta) is the accessor for the metadata slot
7:38:03
phantomics
Ok, I figured it out, I was running something that overwrote the metadata that got reassigned
7:40:29
beach
phantomics: By the way, the indentation on that page is messed up, so either your code contains TABs, or it is incorrectly indented.
7:41:17
phantomics
I've noticed that the recent version of Emacs I had does indenting in a different way
7:42:30
beach
For LOOP I use the slime-indentation contribution which is basically required for it to be right.
7:42:40
phantomics
Are the :for and :collect in the loop clauses toward the bottom supposed to be aligned? In older Emacs the :for would be further left
7:55:55
beach
If you submit code that is manually aligned, that means the person reading it can't trust the indentation, so you force that person to count parentheses.
8:06:11
verisimilitude
Regardless, no indentation can be trusted, because these programs are unfortunately distributed as text files.
9:02:24
fiddlerwoaroof
verisimilitude: I was under the impression that there was a clause along the lines of "the user must use the return value of SORT" in the standard and that the state of the input sequence was undefined after SORT exits
9:04:27
verisimilitude
I believe I checked for just that before I wrote the implementation of grade I shared earlier, because it also occurred to me.
9:05:16
jackdaniel
fiddlerwoaroof: basically yes ("The sorting operation can be destructive in all cases. In the case of a vector argument, this is accomplished by permuting the elements in place. In the case of a list, the list is destructively reordered in the same manner as for nreverse. " - from the standard)
9:05:52
fiddlerwoaroof
Yeah, although if you're assuming a vector, I think it's safe to assume the input sequence hasn't been ruined?
9:06:32
fiddlerwoaroof
For lists, this clause in NREVERSE seems to apply: "The result might or might not be identical to sequence"
9:06:55
acma
SLIME indents the LOOP clauses correctly anyway, so never had to bother about taking special care myself to indent them
9:07:45
jackdaniel
in case of nreverse and co the head may end up in the middle of the sequence, so the new head is in a different place (so the old variable may reference a cons that is in not at the beginning of the sequence)
9:08:00
beach
acma: As I recall, it has to do with slime-indentation being the default, but perhaps it did not use to be.
9:08:05
jackdaniel
(in case of nreverse it will be probably at the end of the sequence, not the middle of course)
9:10:35
fiddlerwoaroof
The standard seems to restrict operations on vectors to reordering items, in both cases
9:12:04
jackdaniel
that said all depends on your definition of being "ruined" - sometimes you don't want to modify the original sequence order (in this case a vector)
9:12:21
jackdaniel
then calling sort on it may be undesired, because the original order will be ruined
9:28:06
pjb
(let ((list (list 5 4 3 1 2))) (list list (sort list #'<))) #| --> (#1=(5) (1 2 3 4 . #1#)) |#
15:52:07
gamaliel
Hi, I'm relatively new to Lisp, and was wondering if there was some way to wrap docstrings when documenting my functions. For now I am using (concatenate 'string "<doc-piece1>" ... "<doc-piece-n>") and it seems awfully clunky.
15:55:51
gamaliel
Sorry, I meant, it places the cursor directly on the first column of the code after the newline instead of respecting the indentation of the previous line.
15:56:40
gamaliel
So, if I start on the 8th space to write my docstring, placing newline moves the rest of the docstring to the 1st space.
15:58:05
semz
if you want to get rid of the linebreaks entirely for aesthetic reasons or want to indent your docstrings in the source without that showing up in the docstring itself, you could do #.(format nil "your docstring here~<newline> bottom text"), which results in "your docstring herebottom text".
15:58:27
semz
~<newline> is a format command that ignores the newline and all whitespace at the beginning of the next line
16:04:02
gamaliel
Ok, so to be clear, for writing a docstring I'd wrap it around #.(format nil "<my-docstring-text-piece1>~<newline><my-doc-string-text-piece2>") and add enters, spaces, etc. for manually indenting. Format would then take care of eliminating all extra space.
16:05:41
_death
gamaliel: the indentation makes sense, because the text starts after the first double quote
16:05:41
edgar-rft
gamalie: If you start the doctring on the 8th space in your code and also indent all following lines in the docstring by 8 spaces, then when the docstring gets printed the first line will start at line position 0 (because the docstring starts with the double quotes) and all subsequent lines will be printed with an indentation of 8 spaces. This is probably not what you want.
16:07:34
semz
gamaliel: Pretty much, although keep in mind that ~<newline> by itself won't add a space between the concatenated pieces (you'd have to put one before the ~<newline>). You can test this without the #. in the REPL, it's just a format call after all
16:08:06
semz
actually I suppose you can test it with the #. in the REPL as well, it makes no difference
16:10:02
beach
gamaliel: Here is what we do: https://github.com/robert-strandh/SICL/blob/master/Code/Conditions/Portable-condition-system/docstrings-english-conditions.lisp
16:11:23
beach
gamaliel: The ~@<newline> FORMAT directive means that initial space on the next line is ignored, so the lines of the documentation string are aligned in the left column even though the lines in the code are indented.