Great! The code that uses it would be kind of bulkier than I wanted, but it's okay. I can at least make my code much more readable without hurting its runtime performance. Thanks a lot.
On Apr 4, 4:16 pm, Stuart Sierra <the.stuart.sie...@gmail.com> wrote: > This can be macro-ized: > > (defmacro bigstr [& strings] > "Concatenates strings at compile time." > (apply str strings)) > > user> (macroexpand-1 '(bigstr "This is a really long string " > "that I just felt like using " > "in my program.")) > "This is a really long string that I just felt like using in my > program." > > You want line breaks? > > (defmacro bigjoin [separator & strings] > "Concatenates strings at compile time, with separator between them." > (apply str (interpose separator strings))) > > user> (println (bigjoin "\n" "This is a really long string" > "that I just felt like using" > "in my program.")) > This is a really long string > that I just felt like using > in my program. > > -Stuart Sierra > > On Apr 4, 11:26 am, samppi <rbysam...@gmail.com> wrote: > > > I see—perhaps using (str) would indeed be the best answer. I'll be > > doing that for now, but I wonder what Rich Hickey thinks of this. > > Indeed, this is a big headache in just about every programming > > language I've encountered. I'd rather not have to do this: > > > (...lots of indented code > > (if (= m :auto-detect) > > (if (<= detected-indent n) > > (raise parse-error i > > "first nonempty line in a literal > > \ > > scalar is indented by %s, but it > > \ > > must be indented further in than > > \ > > the indentation level that the \ > > scalar is in (at level %s)" > > [detected-indent n]) > > detected-indent) > > ...more indented code) > > > Vincent, I'm not so sure about auto-concatenating strings—how would > > that not be ambiguous? For instance, how would (fn-that-wants-two- > > strings "A" "B") not be interpreted as (fn-that-wants-two-strings > > "AB")? I'm more in favor for backslashing or triple-quoting because > > they are not as radical and more consistent: one basically just adds > > one more escape sequence, while the other simply adds a new type of > > token. > > > (By the way, I'm more partial to backslashing breaks, because then I > > can choose what lines I want folded and what lines I want to keep > > separate.) > > > On Apr 3, 11:48 pm, "William D. Lipe" <atmc...@gmail.com> wrote: > > > > Implementing the multi-line strings with the backslash is simple > > > enough (see my earlier post; I got the line number wrong, by the way, > > > it's around 421) but causing them to ignore following whitespace is > > > probably a bit harder. It seems to me that this is a typical problem > > > in many programming languages. Probably the real solution is just to > > > use (str ...) and ignore the resultant extra code; unless you're > > > printing multi-line messages in a tight loop, I can't imagine it > > > having any effect on your program's performance whatsoever. > > > > On Apr 4, 1:35 am, samppi <rbysam...@gmail.com> wrote: > > > > > I don't really want it so much for documentation strings—they're > > > > already formatted in a standard way—than just being able to embed > > > > large literal text in my code without making the code nigh unreadable. > > > > Here's an example: > > > > > (...lots of indented code > > > > (if (= m :auto-detect) > > > > (if (<= detected-indent n) > > > > (raise parse-error i "first nonempty > > > > line in a literal scalar is indented by %s, but it must be indented > > > > futher in than the indentation level that the scalar is in (at level > > > > %s)" [detected-indent n]) > > > > detected-indent) > > > > ...more indented code) > > > > > (...lots of indented code > > > > (if (= m :auto-detect) > > > > (if (<= detected-indent n) > > > > (raise parse-error i "first nonempty > > > > line in a literal scalar is indented by %s, but it must be indented > > > > futher in than the indentation level that the scalar is in (at level > > > > %s)" [detected-indent n]) > > > > detected-indent) > > > > ...more indented code) > > > > > I'd also like to emphasize the importance, for me, of making the > > > > folded lines' indentation disappear. It would be annoying and ugly if > > > > literal text had to be mushed against the left edge of the code. I'd > > > > be fine with triple quotes or backslashed line-breaks, as long as they > > > > do this—that is, as long as they make the code more readable. > > > > > I suppose I could put those long strings inside Java resource bundles, > > > > since they're intended for the end user anyway, but is that really > > > > necessary for a script? :( > > > > > On Apr 3, 11:02 pm, Laurent PETIT <laurent.pe...@gmail.com> wrote: > > > > > > Hi, > > > > > > 2009/4/4 samppi <rbysam...@gmail.com> > > > > > > > I wish I could do this: > > > > > > > (code... > > > > > > "Long error string that doesn't fit within 80 characters but is > > > > > > descriptive, \ > > > > > > which is good, right?" > > > > > > ...more code...) > > > > > > > (The string above would say, "Long error string that doesn't fit > > > > > > within 80 characters but is descriptive, which is good, right?") > > > > > > > People put code on many lines because it's much more readable if > > > > > > lines > > > > > > don't get too long. > > > > > > Yeah, this is seen a lot e.g. for functions docstrings. And it makes > > > > > creating a graphical representation more difficult, you have to guess > > > > > when > > > > > there are real new lines, and where not. > > > > > > But are willing to ask the user to explicitly place new line > > > > > characters ? > > > > > How would that work ? And if that would work, I guess the readability > > > > > and > > > > > usability would suffer from this. > > > > > > I guess the simplest solution for the docstrings problem would be to > > > > > rewrite > > > > > correctly the docstring, no matter your own conventions are for the > > > > > number > > > > > of characters per line in the rest of the code. > > > > > > Or maybe have 2 flavors of strings : > > > > > "this kind of strings can span multiple lines > > > > > but newlines will be interpreted as just a single space > > > > > " > > > > > > and > > > > > """this kind of strings is for real multiline > > > > > strings where each newline will be interpreted as a newline in > > > > > the resulting string.""" > > > > > > OR maybe as you suggested, a special symbol at the end of the line > > > > > indicating the reader to not include a new line : > > > > > "this string will have just one line \ > > > > > thanks to the "\\"+<newline> separator. Any other occurence of the > > > > > slash > > > > > separator not followed by newline or one of the allowed java > > > > > characters > > > > > would be a compilation error." > > > > > > > But this is not possible for strings without doing > > > > > > calling (str ...). This is relatively expensive, right? (str) has to > > > > > > create a new StringBuilder object. > > > > > > > Anyways, it'd be really cool if the Clojure reader did this. My > > > > > > ideal > > > > > > would be that indentation before the continuing line would become > > > > > > one > > > > > > space, or perhaps something similar. I don't think it would make > > > > > > Clojure too much more complicated—in my mind, any small complication > > > > > > would be worth the readability. How hard would this be to implement? > > > > > > Would this be syntactically ambiguous? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
