Comments and continuing strings on the next line

ruby-talk
1

I have a tendency to write:

foo =
"this is a string "
“that is continued on a second line”

I’d like to write:

foo =
"this is a string " # this is a comment
“that is continued on a second line”

but this doesn’t work (I only get the second part of the string and the
first part is ignored). And:

foo =
“this is a string " # this is a comment
"that is continued on a second line”

is a syntax error.

I could write:

foo =
“this is a string " + # this is a comment
"that is continued on a second line”

but that is slightly different from the original example. Any ideas?

Paul

2

Paul Brannan pbrannan@atdesk.com writes:

foo =
"this is a string "
“that is continued on a second line”

foo =
"this is a string " + # this is a comment
“that is continued on a second line”

but that is slightly different from the original example. Any ideas?

I’m not sure it is different. I believe Ruby folds adjacent constant
strings at compile-time.

Cheers

Dave

3

Hi,

I don’t know whether it is different, but it seems this format also works,
although with more punctuations:

foo = %Q!
this is a string #{#some comment}
that is continued on a second line
!

Regards,

Bill

···

===========================================================================
Paul Brannan pbrannan@atdesk.com wrote:

I have a tendency to write:

foo =
"this is a string "
“that is continued on a second line”

I’d like to write:

foo =
"this is a string " # this is a comment
“that is continued on a second line”

but this doesn’t work (I only get the second part of the string and the
first part is ignored). And:

foo =
"this is a string " # this is a comment
“that is continued on a second line”

is a syntax error.

I could write:

foo =
"this is a string " + # this is a comment
“that is continued on a second line”

but that is slightly different from the original example. Any ideas?

Paul

4

Good point, although that breaks indenting:

foo = %Q!
this is a string #{#some comment}
that is continued on a second line
!

Paul

···

On Tue, Sep 17, 2002 at 05:12:11AM +0900, William Djaja Tjokroaminata wrote:

Hi,

I don’t know whether it is different, but it seems this format also works,
although with more punctuations:

foo = %Q!
this is a string #{#some comment}
that is continued on a second line
!

5

Hi,

foo = %Q!
this is a string #{#some comment}
that is continued on a second line
!

This style comment inside string no longer works in 1.7, right
brace and backslash are part of the comment. Instead, this
works in both of 1.6 and 1.7:

foo = %Q!
this is a string #{#some comment
}
that is continued on a second line
!

Once we had a little discussion on inline comment, but still no
conclusion.

···

At Tue, 17 Sep 2002 05:12:11 +0900, William Djaja Tjokroaminata wrote:

–
Nobu Nakada

6

Hi,

May we know the actual purpose of this? If the indenting is really
consistent, we can just try to “gsub” it:

foo = %Q!
this is a string #{#some comment}
that is continued on a second line
!
foo.gsub! (/ /, ‘’)

Regards,

Bill

···

=============================================================================
Paul Brannan pbrannan@atdesk.com wrote:

On Tue, Sep 17, 2002 at 05:12:11AM +0900, William Djaja Tjokroaminata wrote:

Hi,

I don’t know whether it is different, but it seems this format also works,
although with more punctuations:

foo = %Q!
this is a string #{#some comment}
that is continued on a second line
!

Good point, although that breaks indenting:

foo = %Q!
this is a string #{#some comment}
that is continued on a second line
!

Paul

7

Hi,

In my opinion, the #{expression} rule ought to take precedence than the
comment rule (comment from # until the end of line). Just like in C,
where a /* */ comment becomes ineffective inside a string, and also in
Ruby, so I usually regard #{…} as another “mini-interpreter” where
… is “eval”-ed in its own space.

Is there any drawback in the rule in 1.6 so that it should be changed in
1.7?

Regards,

Bill

···

==========================================================================
nobu.nokada@softhome.net wrote:

This style comment inside string no longer works in 1.7, right
brace and backslash are part of the comment. Instead, this
works in both of 1.6 and 1.7:

foo = %Q!
this is a string #{#some comment
}
that is continued on a second line
!

Once we had a little discussion on inline comment, but still no
conclusion.

–
Nobu Nakada

8

Well, I typed it misleadingly the first time. In code, you’d see
something like this:

def bar
foo = %Q!
this is a string #{#some comment}
that is continued on a second line
!
foo.gsub! (/ /, ‘’)
return foo
end

I suppose the gsub trick works, though if I’m going to go with an
inefficient solution, I think I’ll stick with “+”, as long as I have
only two lines.

I do recall one of the apocalypses mentioning a perl rfc that proposed a
<<< operator for ‘here documents’, which would remove whitespace from
the ‘here document’ (at compile-time) that matched the whitespace in
front of the terminator. Doesn’t seem like a bad idea for either perl
or ruby.

Paul

···

On Tue, Sep 17, 2002 at 10:33:35PM +0900, William Djaja Tjokroaminata wrote:

Hi,

May we know the actual purpose of this? If the indenting is really
consistent, we can just try to “gsub” it:

foo = %Q!
this is a string #{#some comment}
that is continued on a second line
!
foo.gsub! (/ /, ‘’)

9

Hi,

In my opinion, the #{expression} rule ought to take precedence than the
comment rule (comment from # until the end of line). Just like in C,
where a /* */ comment becomes ineffective inside a string, and also in
Ruby, so I usually regard #{…} as another “mini-interpreter” where
… is “eval”-ed in its own space.

Comments are from # until EOL, always. And also comment in
Ruby is ineffective too.

If you want “eval”-like effect, I guess it’s better to use
“eval”.

Is there any drawback in the rule in 1.6 so that it should be changed in
1.7?

Now you don’t need to escape quotes even inside a nested string
interpolation. And another issue, see the threads start from
[ruby-talk:40979] and [ruby-core:00042].

···

At Tue, 17 Sep 2002 23:53:48 +0900, William Djaja Tjokroaminata wrote:

–
Nobu Nakada

10

Hi,

I guess if it were for me whether I am going with the first solution

foo =
"this is a string " + # this is a comment
“that is continued on a second line”

or the second solution

foo = %Q!
this is a string #{#some comment}
that is continued on a second line
!

really depends on whether I write a lot of comments (in which case first
solution seems cleaner) or not (in which case we don’t have to type so
many "'s in the second solution). But then again, in the first solution
we can replace " with ', something that we cannot not do in the second
solution with %q, and this is not counting the overhead of gsub. It seems
the <<< operator is the best solution if it existed.

Regards,

Bill

···

==========================================================================
Paul Brannan pbrannan@atdesk.com wrote:

I suppose the gsub trick works, though if I’m going to go with an
inefficient solution, I think I’ll stick with “+”, as long as I have
only two lines.

I do recall one of the apocalypses mentioning a perl rfc that proposed a
<<< operator for ‘here documents’, which would remove whitespace from
the ‘here document’ (at compile-time) that matched the whitespace in
front of the terminator. Doesn’t seem like a bad idea for either perl
or ruby.

Paul

11

A happy new year,

I do recall one of the apocalypses mentioning a perl rfc that proposed a
<<< operator for ‘here documents’, which would remove whitespace from
the ‘here document’ (at compile-time) that matched the whitespace in
front of the terminator. Doesn’t seem like a bad idea for either perl
or ruby.

I thought a new syntax like this,

p <<-|EOS
  >  foo
  >    bar
EOS
# => "  foo\n    bar\n"

That is, a punctuation between << and the terminator, except
for quotations, directs to strip leading white-spaces till that
punctuation. Any line wihtout it results an syntax error.

The patch was posted in [ruby-dev:19261]. Any comments are
welcome.

···

At Tue, 17 Sep 2002 22:52:00 +0900, Paul Brannan wrote:

–
Nobu Nakada

12

My comment: it’s very nice!

Gavin

···

On Wednesday, January 1, 2003, 1:04:14 PM, nobu wrote:

I thought a new syntax like this,

p <<-|EOS
  >  foo
  >    bar
EOS
# => "  foo\n    bar\n"

[…]
The patch was posted in [ruby-dev:19261]. Any comments are
welcome.

13

nobu.nokada@softhome.net writes:

A happy new year,

I do recall one of the apocalypses mentioning a perl rfc that proposed a
<<< operator for ‘here documents’, which would remove whitespace from
the ‘here document’ (at compile-time) that matched the whitespace in
front of the terminator. Doesn’t seem like a bad idea for either perl
or ruby.

I thought a new syntax like this,

p <<-|EOS
  >  foo
  >    bar
EOS
# => "  foo\n    bar\n"

That is, a punctuation between << and the terminator, except
for quotations, directs to strip leading white-spaces till that
punctuation. Any line wihtout it results an syntax error.

The patch was posted in [ruby-dev:19261]. Any comments are
welcome.

I like this, though my biggest problem with << is that the
ruby-mode.el still wants to indent. If <<-| were understood by
ruby-mode.el, that’d be great.

···

At Tue, 17 Sep 2002 22:52:00 +0900, > Paul Brannan wrote:

14

I (try to) maintain the indent file for Vim, and here-docs are an
indentation nightmare. Emacs may be made to understand <<-|, but
consider this:

  • the - is optional (it means “EOS” or whatever may be indented)
  • the | could be one of many characters

Ruby, in general is very hard to write indenting rules for :slight_smile:

Gavin

···

On Wednesday, January 1, 2003, 7:34:54 PM, Matt wrote:

nobu.nokada@softhome.net writes:

I thought a new syntax like this,

p <<-|EOS
  >  foo
  >    bar
EOS
# => "  foo\n    bar\n"

I like this, though my biggest problem with << is that the
ruby-mode.el still wants to indent. If <<-| were understood by
ruby-mode.el, that’d be great.