%L, %l revisited

[Tom_Sawyer]

silver% grep -r -e ‘^.<<-\w\s*,.*$’ ./

regexp often confuse me, why did this not catch these? oh well.

jenny:/project/remacs> grep ‘<<’ *
buffer.rb: doc(self, :create, <<-HERE, [:destroy, [Memory, :mmap]])

documentation.rb: doc(“Module”, :class_variables, <<-HERE, nil)

that is an good use of HERE docs. i did not know you could embed them in
methods until i ran this. that’s useful. i like them more now.

Now it is 21+9=30.

well, that’s better. in this context, i.e. embedded as method argument, i see
how one might be inclined to use them. for myself i think i’d still lean
toward assigning variables to pass into the method for clearity, especially
if there’s more than one, but to each his own.

given this (and in all honestly i did before too) i do like the orgininal
notion myself (i.e. margin control for HERE docs). i would just very much
like to have a literal string contructor that allowed margin control. i think
a HERE document form of this would be good too, in addition to the idea of
%L. it was only that in our earlier discussion of this idea there was some
quirks in implementing it for HEREs, mostly i think it had to do with having
%Q vs. %q forms of it. That’s why the %L, %l idea arose.

obviously HERE docs have a lot of power, and that’s why we have them. IMHO
they are not the most elegant structure on the block, but they do the job,
and do it well.

yet we don’t have such a tool for multi-line margin controlled strings. that’s
okay, we can use #tabto or what have you. but i also think that this is even
less elegant. for myself, i simply know that i would use %L for multiline
strings more than any other contruct if we had it.

perhaps only adding coal to a dead fire, but it occured to me that the %L, %l
contruct could even do a little more perhaps. for example:

puts %L|How about this | << [1,2,3].collect { |x| x * 3 }.join(‘,’)
>And it keeps going…
>And going…
>Til>, ‘The End’

How about this 3,6,9
And it keeps going…
And going…
Til
The End

anyway. Shell scripting languages already have it before there was
perl. But, I do not know if it originated from sh or something even
more ancient.

really, that old?

···

On Wednesday 05 February 2003 08:08 pm, Yohanes Santoso wrote:

–
tom sawyer, aka transami
transami@transami.net

[Tom_Sawyer]

Hal,

i thought Nobu already hacked out an initial HERE doc version. that’s how all
this got started.

···

On Thursday 06 February 2003 02:23 am, Hal E. Fulton wrote:

I didn’t mean the parser would have problems of
that nature. I meant the parser would have to
undergo radical changes and here-docs as we
know them would be broken.

–
tom sawyer, aka transami
transami@transami.net

[Dossy]

that is an good use of HERE docs. i did not know you could embed them in
methods until i ran this. that’s useful. i like them more now.

You ought to read this very well-written article on here-docs, written
by Randal Schwartz:

Unix Review Column 12 (January 1997)
http://www.stonehenge.com/merlyn/UnixReview/col12.html

My personal favorite and not commonly known feature of here-docs:

irb(main):015:0> puts <<SHELL
irb(main):016:0 for i in *; do irb(main):017:0 echo $i
irb(main):018:0 done irb(main):019:0 SHELL
[…my files snipped…]
nil

for myself i think i’d still lean toward assigning variables to pass
into the method for clearity,

Here-docs improve clarity, usually.

anyway. Shell scripting languages already have it before there was
perl. But, I do not know if it originated from sh or something even
more ancient.

really, that old?

Yes, that old.

The Traditional Bourne Shell Family
http://www.uni-ulm.de/~s_smasch/bourne/

This page links to Version 7’s Bourne shell manpage (supposedly from
1979) which documents here-docs (without calling them here-docs way back
when) like so:

 <<word
  The shell input is read up to a line the same as  word,
  or  end  of  file.   The resulting document becomes the
  standard input.  If any character  of  word  is  quoted
  then no interpretation is placed upon the characters of
  the document; otherwise, parameter and command  substi-
  tution  occurs,  \newline  is ignored, and \ is used to
  quote the characters \ $ ` and the first  character  of
  word.

Apparently, the improvement of “<<-word” here-docs that strip leading
tabs only came two years later, in 1981:

o here document with trailing dash "<<-" strips leading tabs 

It seems that Ruby’s here-doc doesn’t implement this:

irb(main):001:0> p <<-“EOT”
irb(main):002:0" this is
irb(main):003:0" a test
irb(main):004:0" EOT
“\tthis is\n\ta test\n”
nil

I’m generating the tabs using ^V^I in irb … at least Ruby parsed it as
a here-doc, even if it didn’t strip the tabs …

– Dossy

···

On 2003.02.06, Tom Sawyer transami@transami.net wrote:

–
Dossy Shiobara mail: dossy@panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
“He realized the fastest way to change is to laugh at your own
folly – then you can let go and quickly move on.” (p. 70)

[HAL_9000]

Hal,

i thought Nobu already hacked out an initial HERE doc version. that’s how
all
this got started.

But he enhanced functionality without breaking
any existing functionality. It’s the breakage
that I’m concerned with.

Hal

···

----- Original Message -----
From: “Tom Sawyer” transami@transami.net
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, February 06, 2003 5:18 AM
Subject: Re: %L, %l revisited

[Mauricio_Fernndez]

In Ruby <<-EOF means that EOF can be indented.

puts <<EOF
bla b
bla
EOF
bfdbd
EOF #real EO here-doc

…
puts <<-EOF
bla
bla
EOF
…

···

On Thu, Feb 06, 2003 at 08:45:16PM +0900, Dossy wrote:

o here document with trailing dash "<<-" strips leading tabs 

It seems that Ruby’s here-doc doesn’t implement this:

irb(main):001:0> p <<-“EOT”
irb(main):002:0" this is
irb(main):003:0" a test
irb(main):004:0" EOT
“\tthis is\n\ta test\n”
nil

I’m generating the tabs using ^V^I in irb … at least Ruby parsed it as
a here-doc, even if it didn’t strip the tabs …

–
_ _

__ __ | | ___ _ __ ___ __ _ _ __
'_ \ / | __/ __| '_ _ \ / ` | ’ \
) | (| | |__ \ | | | | | (| | | | |
.__/ _,|_|/| || ||_,|| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

After 14 non-maintainer releases, I’m the S-Lang non-maintainer.
– Ray Dassen

[Tom_Sawyer]

You ought to read this very well-written article on here-docs, written
by Randal Schwartz:

Unix Review Column 12 (January 1997)
Here documents (jan 97)

good little read, thanks. did you catch the line:

"Sorry for the strange indentation, but here-docs have significant leading 

whitespace. Grr."

My personal favorite and not commonly known feature of here-docs:

irb(main):015:0> puts <<SHELL
irb(main):016:0 for i in *; do irb(main):017:0 echo $i
irb(main):018:0 done irb(main):019:0 SHELL
[…my files snipped…]
nil

very cool too. execute and build dynamic shell scripts. does #{x} work within
shell form of heres?

Here-docs improve clarity, usually.

well, in the simple cases i think yes. but like this:

for (<<‘EOF’ =~ /(.+)/g) {
fredf:Fred Flintstone:$25
barneyb:Barney Rubble:$100
bettyb:Betty Rubble:$0.05
EOF
($email, $person, $owe) = split /:/;
print <<EOM;
## mail for $person
mail -s “$person, you deadbeat!” $email <<INPUT
Hey, $person, you owe us $owe!
Pay up, or else!
INPUT
## end of mail for $person
EOM
}

my eyes start to blur. just for comparision (psuedo):

$pl = %l|fredf:Fred Flintstone:$25
>barneyb:Barney Rubble:$100
>bettyb:Betty Rubble:$0.05

for ($pl =~ /(.+)/g) {
($email, $person, $owe) = split /:/;
print %L|## mail for $person
>mail -s “$person, you deadbeat!” $email <Hey, $person, you owe us $owe!
>Pay up, or else!
>INPUT
>## end of mail for $person
}

a little better i think, but still a bit blury b/c it’s shell AND Perl!

Yes, that old.

Apparently, the improvement of “<<-word” here-docs that strip leading
tabs only came two years later, in 1981:

o here document with trailing dash "<<-" strips leading tabs

well, that’s interesting in its own right. the <<- is not only to allow the
EOT (or what have you) to be indented, but to remove all initial tabs in the
text itself. curious ruby dosen’t do. i wonder if perl does…duh! first
quote of this email; it would indicate perl doesn’t either. that might offer
an more elegant solution for HERE docs at least:

puts <<-TOHERE
this is
untabed
TOHERE

this is
untabbed

puts <<-TOHERE
this is
untabed
TOHERE

this is
untabbed

of course don’t ask me what would happen if one did:

puts <<-TOHERE
this is
untabed
TOHERE

···

On Thursday 06 February 2003 04:45 am, Dossy wrote:

–
tom sawyer, aka transami
transami@transami.net

[Gavin_Sinclair]

Have we come full circle? You (and others) disliked Nobu’s idea
because it wasn’t intuitive (although I love it). Now you’re singing
the praises of it, albeit in only one respect, and compared with a
specific proposal…

The original idea makes as much sense as here-docs themselves.

Gavin

···

On Friday, February 7, 2003, 3:55:05 AM, Hal wrote:

Hal,

i thought Nobu already hacked out an initial HERE doc version.
that’s how all this got started.

But he enhanced functionality without breaking
any existing functionality. It’s the breakage
that I’m concerned with.

[Tom_Sawyer]

But he enhanced functionality without breaking
any existing functionality. It’s the breakage
that I’m concerned with.

elaborate, what’s going to break? consider that the HERE document form of this
was never fully worked out and %L, %l is a whole new construct.

perhaps we should review, it all started with:

[ruby-talk:50473]. In his idea, if you assign a character (except
quotes) after the here-document indicator “<<-”, All blanks and
assigned character at the head of each line will be deleted.
Here is a example assigning ‘|’:

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

many showed initial support.

note this is contrast to PERLs version:

Paul Brannan wrote:
"From what I can gather, the proposed perl solution would look like this in
Ruby:

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

(that is, strip any leading whitespace that is indented the same as the
terminator)."

but in reviewing a number of opions suggested that the Perl version is not as
good.

Gavin Sinclair brought up an interesting point in contrast to using a method
to strip the tabs:

“One more difference. tabto strips after string interpolcation,
whereas here-doc does before it.”

Peña, Botp suggested it support mixture:

s1 = <<|EOS
>#{hi}
> do not have the indenter
> how are you?
me, too… but ruby takes care of me
EOS

a number of suggestions were made at this point (many incompatible with
current here docs). the most important point though was probably that the
deliminator should be redefinable. but no specific solution was derived for
this.

that’s when i suggested:

%Q-| try
> this

which led to the %L form. and so…

···

On Thursday 06 February 2003 09:55 am, Hal E. Fulton wrote:

–
tom sawyer, aka transami
transami@transami.net

[Dossy]

Ah, so this is where Ruby’s here-doc implementation deviates from the
shell … okay.

Perl, being Evil, gives you hackery like this:

(my $x = <<EOT) =~ s/^\t*//gm;
this is
a test
EOT

Which roughly approximates the <<-word here-doc behavior of the shell,
which strips leading tabs off lines in the here-doc.

I guess one could apply a similar regexp in Ruby as well …

– Dossy

···

On 2003.02.06, Mauricio Fernández batsman.geo@yahoo.com wrote:

In Ruby <<-EOF means that EOF can be indented.

–
Dossy Shiobara mail: dossy@panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
“He realized the fastest way to change is to laugh at your own
folly – then you can let go and quickly move on.” (p. 70)

[HAL_9000]

Hmm, I’ve lost my way in this (not especially interesting)
thread.

I don’t think I ever commented on Nobu’s idea at all. Offhand
I don’t even remember its details.

But I am opposed to breaking existing functionality, and I
think Nobu was on the same side of that, whereas Tom was
saying “nobody really uses that” in response to functionality
that’s more than twenty years old.

But this has grown old. I’m glad Matz makes those decidions
instead of any of us, including myself.

Hal

···

----- Original Message -----
From: “Gavin Sinclair” gsinclair@soyabean.com.au
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, February 06, 2003 11:53 AM
Subject: Re: %L, %l revisited

On Friday, February 7, 2003, 3:55:05 AM, Hal wrote:

Hal,

i thought Nobu already hacked out an initial HERE doc version.
that’s how all this got started.

But he enhanced functionality without breaking
any existing functionality. It’s the breakage
that I’m concerned with.

Have we come full circle? You (and others) disliked Nobu’s idea
because it wasn’t intuitive (although I love it). Now you’re singing
the praises of it, albeit in only one respect, and compared with a
specific proposal…

[Tom_Sawyer]

[ruby-talk:50473]. In his idea, if you assign a character (except
quotes) after the here-document indicator “<<-”, All blanks and
assigned character at the head of each line will be deleted.
Here is a example assigning ‘|’:

p <<-|EOS

  >  foo
  >    bar

EOS
# => "  foo\n    bar\n".

a number of suggestions were made at this point (many incompatible with
current here docs). the most important point though was probably that the
deliminator should be redefinable. but no specific solution was derived for
this.

my mistake, assigning character was built in. i think this was generally over
looked. great! i think that gives us this:

A NEW HERE DOCUMENT FORM PROVIDING MARGIN CONTROL:

p <<-:EOS
		:#{foo}
		:example
	EOS

all here variants work, ex-

p <<)'EOS'
	)foo
	)example
EOS

ADDITIONALLY A NEW COMPLIMENTRY DELIMITED INPUT:

p %L|#{foo}
         >example

and provides likewise for the variances, ex-

p %l)foo
       )example

potential additional suggestions:

the construct can be termintated with the deliminator to be able to apply
methods to it:

p %l)foo
       )example).upcase

further the %L, %l delimited input can be terminated per-line and have
per-line aggregating method calls:

p %L|#{foo}| << ' bar'
	>example>.upcase

if possible, there could be two forms of this. perhaps %A, %a for the above
and instead use %L, %l for a non-aggregating form. to show the difference:

p %a|foo|.upcase
            >BAR>.downcase

foo bar

p %l|foo|.upcase
           >BAR>.downcase

FOO bar

but i don’t know if these expansions of the main idea are actually possible.

···

On Thursday 06 February 2003 11:10 am, Tom Sawyer wrote:

–
tom sawyer, aka transami
transami@transami.net

[HAL_9000]

elaborate, what’s going to break? consider that the HERE document form of
this
was never fully worked out and %L, %l is a whole new construct.

This topic has gotten tangled in my mind,
as to who said what.

I probably have gotten confused to the point
where I don’t know what I’m talking about.

My biggest concern is that I don’t want to
lose the ability to embed a reference to a
here-doc arbitrarily in the middle of a line,
e.g.:

mymeth 123, <<-EOF, 456
this is my
here-doc
EOF

So IF someone is proposing a syntax that
won’t allow this, I’m against it.

Hal

···

----- Original Message -----
From: “Tom Sawyer” transami@transami.net
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, February 06, 2003 12:10 PM
Subject: Re: %L, %l revisited

[Tom_Sawyer]

oh yea! add more PERLisms to the fire!

Nobu where are you!

···

On Thursday 06 February 2003 06:00 am, Dossy wrote:

Perl, being Evil, gives you hackery like this:

(my $x = <<EOT) =~ s/^\t*//gm;
this is
a test
EOT

I guess one could apply a similar regexp in Ruby as well …

–
tom sawyer, aka transami
transami@transami.net

[David_Alan_Black1 (David Alan Black)]

Hi –

In Ruby <<-EOF means that EOF can be indented.

Ah, so this is where Ruby’s here-doc implementation deviates from the
shell … okay.

Perl, being Evil, gives you hackery like this:

(my $x = <<EOT) =~ s/^\t*//gm;
this is
a test
EOT

Which roughly approximates the <<-word here-doc behavior of the shell,
which strips leading tabs off lines in the here-doc.

I guess one could apply a similar regexp in Ruby as well …

But with a chance to show off how cool the non-need for /gm can be

irb(main):018:0> str = <<EOE.gsub!(/^\t*/,‘’)
irb(main):019:0" abc
irb(main):020:0" def
irb(main):021:0" EOE
“abc\ndef\n”

David

···

On Thu, 6 Feb 2003, Dossy wrote:

On 2003.02.06, Mauricio Fernández batsman.geo@yahoo.com wrote:

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

[Tom_Sawyer]

i’m sorry i ever said that b/c it misdirected the conversation, and was far
that %L did not need to support appending ,x just because HERE docs did.
that’s all. but i also see that it would be better if they did so i would
just like to see a solution rather than abandoing the whole idea, which many
agreed was good for HERE docs in the first place.

···

On Thursday 06 February 2003 11:16 am, Hal E. Fulton wrote:

But I am opposed to breaking existing functionality, and I
think Nobu was on the same side of that, whereas Tom was
saying “nobody really uses that” in response to functionality
that’s more than twenty years old.

from my point. i wasn’t ever suggesting breaking things. i was only saying

tom sawyer, aka transami
transami@transami.net

[Tom_Sawyer]

no, no. not at all.

i know the converstaion has sort of gone on and on at this point. so i’ll let
it rest for now. hope you read my 2 summary posts, to help clear it up for
you.

anway, as you said matz has say so. hopefully he’ll catch some of this and
eventually we’ll get the ability to create margin controlled mutliline
strings either in here docs or delimited input forms, or, as i hope, both.

thanks, HAL

···

On Thursday 06 February 2003 02:01 pm, Hal E. Fulton wrote:

So IF someone is proposing a syntax that
won’t allow this, I’m against it.

–
tom sawyer, aka transami
transami@transami.net

[Tom_Sawyer]

indeed! or the lovely new tabto:

str = <<EOE.tabto(0)
abc
def
EOE

yet,

showing_off != most_efficient or most_elegant

both still require add-on processing.

···

On Thursday 06 February 2003 06:28 am, dblack@candle.superlink.net wrote:

But with a chance to show off how cool the non-need for /gm can be

irb(main):018:0> str = <<EOE.gsub!(/^\t*/,‘’)
irb(main):019:0" abc
irb(main):020:0" def
irb(main):021:0" EOE
“abc\ndef\n”

–
tom sawyer, aka transami
transami@transami.net

[Dossy]

I’d rather control the add-on processing than bloat the lexer to
understand the funny indent-delimited here-doc that you’re proposing.

The rare times I actually care about indenting the here-doc (rarely) are
the only times I want to incur the overhead of trimming out the
indentation.

Adding this “feature” to the language means making the parser
unnecessarily larger … for an interpreted language, that’s just
wasteful.

– Dossy

···

On 2003.02.06, Tom Sawyer transami@transami.net wrote:

yet,

showing_off != most_efficient or most_elegant

both still require add-on processing.

–
Dossy Shiobara mail: dossy@panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
“He realized the fastest way to change is to laugh at your own
folly – then you can let go and quickly move on.” (p. 70)

[Tom_Sawyer]

Nobu, did your patch bloat the parser?

···

On Thursday 06 February 2003 09:10 pm, Dossy wrote:

Adding this “feature” to the language means making the parser
unnecessarily larger … for an interpreted language, that’s just
wasteful.

–
tom sawyer, aka transami
transami@transami.net

[Nobuyoshi_Nakada]

Hi,

···

At Fri, 7 Feb 2003 14:38:59 +0900, Tom Sawyer wrote:

Adding this “feature” to the language means making the parser
unnecessarily larger … for an interpreted language, that’s just
wasteful.

Nobu, did your patch bloat the parser?

Well, 139 lines larger, including both styles of ‘<<|’ and
‘<<<’. No doubt it makes the parser larger.

–
Nobu Nakada