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" <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:
>
> > > Hi,
>
> > > 2009/4/4 samppi <[email protected]>
>
> > > > 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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
