Slime and string ~
in [Lisp]
|
Prev: New version!!!
Next: remote lisp in virtual linux
From: Peter Keller on 6 Jul 2010 15:21 Hello, For me, SLIME doesn't understand how to indent format control strings which cross line boundaries with the ~ character. Is there some configuration knob I need to tweak in order to make it recognize it? To see an example, copy this into your lisp buffer, indent it, and see how it doesn't work: (defun foo () (format t "this is a ~ long string~%")) I would have expected "long string~%" to have aligned with the 'l' being under the 't'. While poking at this, I realized that the ~ Newline construct is only a format string thing. How can I break up strings in a nice way when passing stuff to a function that isn't format, like: (a-function a argument or two then "this is a " "really long string" "which needs to be cut on a few lines" "and isn't four arguments worth." and some more arguments) Am I going to have to use something like (defun (str &rest x) (reduce #'(lamdba (a b) (concatenate 'string a b)) x)) And then do something like: (a-function more arguments then (str "this is a " "really long string " "which crosses newline " "boundaries") more arguments) I suppose I could make a reader syntax for general strings so they can act similar to format control strings concerning newlines, like: #"This is a ~ long string ~ which is recognized." But no matter what I do, SLIME still doesn't know how to indent it. :) Any ideas how to make SLIME to do the right thing? Thank you. -pete
From: Joshua Taylor on 6 Jul 2010 15:47 On 2010.07.06 3:21 PM, Peter Keller wrote: > While poking at this, I realized that the ~ Newline construct is only a format > string thing. How can I break up strings in a nice way when passing stuff > to a function that isn't format, like: > > (a-function a argument or two then "this is a " > "really long string" > "which needs to be cut on a few lines" > "and isn't four arguments worth." > and some more arguments) > > Am I going to have to use something like > > (defun (str &rest x) > (reduce #'(lamdba (a b) (concatenate 'string a b)) > x)) > > And then do something like: > > (a-function more arguments then (str "this is a " > "really long string " > "which crosses newline " > "boundaries") > more arguments) I've done this in some code that needs long strings. When all the string arguments are constant, you might prefix the call to STR with #. [1] so that the compiler just sees the string. E.g., (a-function #.(str "part 1 " "part 2 " "part 3.")) There's no reason, after all, to do that concatenation at run time every time you enter that section of code. //JT [1] http://www.lispworks.com/documentation/HyperSpec/Body/02_dhf.htm
From: Peter Keller on 6 Jul 2010 15:56 Joshua Taylor <tayloj(a)cs.rpi.edu> wrote: > On 2010.07.06 3:21 PM, Peter Keller wrote: >> While poking at this, I realized that the ~ Newline construct is only a format >> string thing. How can I break up strings in a nice way when passing stuff >> to a function that isn't format, like: >> >> (a-function a argument or two then "this is a " >> "really long string" >> "which needs to be cut on a few lines" >> "and isn't four arguments worth." >> and some more arguments) >> >> Am I going to have to use something like >> >> (defun (str &rest x) >> (reduce #'(lamdba (a b) (concatenate 'string a b)) >> x)) >> >> And then do something like: >> >> (a-function more arguments then (str "this is a " >> "really long string " >> "which crosses newline " >> "boundaries") >> more arguments) > > I've done this in some code that needs long strings. When all the > string arguments are constant, you might prefix the call to STR with #. > [1] so that the compiler just sees the string. E.g., > > (a-function #.(str "part 1 " > "part 2 " > "part 3.")) > > There's no reason, after all, to do that concatenation at run time every > time you enter that section of code. Hrm, this looks like it'll be good enough for my purposes. Thanks! -pete
From: Peter Keller on 6 Jul 2010 17:16 Joshua Taylor <tayloj(a)cs.rpi.edu> wrote: > On 2010.07.06 3:21 PM, Peter Keller wrote: >> (defun (str &rest x) >> (reduce #'(lamdba (a b) (concatenate 'string a b)) >> x)) >> >> And then do something like: >> >> (a-function more arguments then (str "this is a " >> "really long string " >> "which crosses newline " >> "boundaries") >> more arguments) > > I've done this in some code that needs long strings. When all the > string arguments are constant, you might prefix the call to STR with #. > [1] so that the compiler just sees the string. E.g., > > (a-function #.(str "part 1 " > "part 2 " > "part 3.")) > > There's no reason, after all, to do that concatenation at run time every > time you enter that section of code. Out of curiosity, is there a better reason to choose #. over a defmacro expansion? Like this: (defmacro str (&rest x) (flet ((str-helper (&rest x) (reduce #'(lambda (&optional a b) (concatenate 'string a b)) x))) (apply #'str-helper x))) I suppose my question is: What are the general guidelines in choosing when to use read time evaluation or compile time evaluation? Thank you. -pete
From: Rob Warnock on 7 Jul 2010 05:58
Peter Keller <psilord(a)cs.wisc.edu> wrote: +--------------- | Joshua Taylor <tayloj(a)cs.rpi.edu> wrote: | > (a-function #.(str "part 1 " | > "part 2 " | > "part 3.")) | > | > There's no reason, after all, to do that concatenation at run time every | > time you enter that section of code. | | Out of curiosity, is there a better reason to choose #. over a defmacro | expansion? +--------------- The main problem with a defmacro expansion is that all of the args have to be macro-expansion-time constants... or at least values that are accessible at macro expansion time, which may require some EVAL-WHEN hackery in some situations. Of course, the situation with "#." is even worse, since read time is even earlier than macro expansion time. I would tend to use LOAD-TIME-VALUE[1] for this sort of thing: (a-function (load-time-value (str "part 1 " "part 2 " "part 3."))) Yes, it's evaluated every time you LOAD the file containing it, but only once per such LOAD. -Rob [1] http://www.lispworks.com/documentation/HyperSpec/Body/s_ld_tim.htm ----- Rob Warnock <rpw3(a)rpw3.org> 627 26th Avenue <URL:http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 |