Slime and string ~
in [Lisp]
|
Prev: New version!!!
Next: remote lisp in virtual linux
From: Thomas A. Russ on 7 Jul 2010 17:55 Peter Keller <psilord(a)cs.wisc.edu> writes: > 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) I think in general most lisp users don't really worry about it. I will tend to just go ahead and use a long string in the code. Emacs wraps the string and I'm not generally bothered by this. If it gets to be an issue I will then generally just handle it by putting the string into a DEFCONSTANT at the top of the file. > Am I going to have to use something like > > (defun (str &rest x) > (reduce #'(lamdba (a b) (concatenate 'string a b)) > x)) Assuming you don't go overboard with the number of arguments (c.f. CALL-ARGUMENTS-LIMIT), you can also just take advantage of the fact that concatenate takes a variable number of arguments to just do (defun (str &rest x) (apply #'concatenate 'string x)) or even simpler (defmacro (str &rest x) `(concatenate 'string ,@x)) But your REDUCE-based approach is more robust if you expect to have really long argument lists. [Yes, CALL-ARGUMENTS-LIMIT is allowed to be absurdly small, but in practice it isn't that bad.] Either the #. or the constant macro-expansion route will also work. I guess my approach would be to use #. if they are literal constants. One place I might do that is to define seconds-per-day as #.(* 24 60 60) to make it more readable. Constructing a constant in a macro is not something I normally do. But that's a personal preference without much else to back it up. On the other hand, some systems like to turn *READ-EVAL* off for security reasons, although it doesn't really make sense for code that you are going to compile anyway. -- Thomas A. Russ, USC/Information Sciences Institute
From: Peter Keller on 7 Jul 2010 21:53 Thomas A. Russ <tar(a)sevak.isi.edu> wrote: > Either the #. or the constant macro-expansion route will also work. I > guess my approach would be to use #. if they are literal constants. One > place I might do that is to define seconds-per-day as #.(* 24 60 60) to > make it more readable. Out of curiosity, I would have assumed any of the popular CL implementations would have done some kind of optimization with (* 24 60 60), so why would you explicitly state it to be compiled at read time? > Constructing a constant in a macro is not something I normally do. But > that's a personal preference without much else to back it up. On the > other hand, some systems like to turn *READ-EVAL* off for security > reasons, although it doesn't really make sense for code that you are > going to compile anyway. I actually do have to worry about #. and *read-eval* in my project, since it is possible for the application writer to send code over to another daemon for compilation and execution--so I'm making my tradeoffs by choosing one method over another. I also realize how awesomely dangerous this idea is, but for now it is quite useful for the problems I need solving. What I found I really need is the equivalent of perl's here documents. An example is a usage function for a program which takes many command line arguments. Without heredocs, it is amazingly tedious to write. Thank you. -pete
From: Joshua Taylor on 7 Jul 2010 22:31 On 2010.07.07 9:53 PM, Peter Keller wrote: > What I found I really need is the equivalent of perl's here documents. > > An example is a usage function for a program which takes many command line > arguments. Without heredocs, it is amazingly tedious to write. For things like heredocs, don't normal Lisp strings work just fine? In the cases we've been looking at, we wanted to break a single line string over multiple lines in the source file. With a heredoc, don't the multiple lines in the source file correspond to multiple lines in the string? That's no problem in CL: CL-USER > (defparameter *bigstring* "Here's a big multiple line string that is multiple lines in source and has real newlines inside of it.") *BIGSTRING* CL-USER > (progn (print *bigstring*) nil) "Here's a big multiple line string that is multiple lines in source and has real newlines inside of it." NIL CL-USER > (position #\newline *bigstring*) 12
From: Peter Keller on 7 Jul 2010 23:42 Joshua Taylor <tayloj(a)cs.rpi.edu> wrote: > On 2010.07.07 9:53 PM, Peter Keller wrote: >> What I found I really need is the equivalent of perl's here documents. >> >> An example is a usage function for a program which takes many command line >> arguments. Without heredocs, it is amazingly tedious to write. > > For things like heredocs, don't normal Lisp strings work just fine? In > the cases we've been looking at, we wanted to break a single line string > over multiple lines in the source file. With a heredoc, don't the > multiple lines in the source file correspond to multiple lines in the > string? That's no problem in CL: Just before I read this message, I indeed found the same thing. In fact plain lisp strings do work just fine for my needs when I need a heredoc-like thing. The usual place where it is unhappy is if I have some chunk of code on the right hand side of the screen and want a long string to be wrapped in a meaningful manner in accordance with the indention levels around the string. Thank you for helping me. -pete
From: Jorge Gajon on 8 Jul 2010 00:57
On 2010-07-08, Peter Keller <psilord(a)cs.wisc.edu> wrote: > > What I found I really need is the equivalent of perl's here documents. > Doug Hoyte shows how to implement a 'heredoc' reader in his book "Let Over Lambda". You can actually read that chapter at it's website: http://letoverlambda.com/index.cl/guest/chap4.html#sec_3 -- Jorge Gajon Mexico City http://gajon.org |