Pythonic indentation (or: beating a dead horse)

My claims were it's impossible with a Pythonic lexer and a backing context
free grammar. I certainly didn't claim that if you throw enough regexes at
the problem it won't go away.

Tony, while I may be a newb to Ruby, I assure you that I'm no stranger
to mailing lists and Usenet, and I'm aware of these things called
"archives". Perhaps you are too. If not, allow me to demonstrate:

> I think code blocks are cool, and I love Ruby's very flexible
> expressiveness. I dig the way every statement is an expression
These are both incompatible with a Python-style indentation sensitive
syntax. You can have the Pythonic indent syntax or a purely expression
based grammar with multi-line blocks. You can't have both.

And yet here I've _demonstrated_ having both, while repeatedly asking
you for examples to exhibit the "incompatibility", and repeatedly
shooting down every one you've so proudly produced. In the quoted text
above, please note the absence of words like "lexer" and "backing
context free grammar". In fact, you were quite explicit about Pythonic-
style indentation _syntax_ being the problem. You stood behind that
claim several times. Now tell me, Tony, was that claim correct, or was
it wrong?

Now getting back to your amended claim, that it's impossible with a
Python lexer and a backing context free grammar, well, let's not
forget that Ruby-style blocks themselves are impossible. Yes,
completely impossible! Can't be done! You just can't have Ruby-style
blocks, there's no way to make them work... with the Commodore BASIC
interpreter, a ham sandwich, and half a ton of elephant dung. I
realize that this is a bold claim to make, but I'm gonna stand by it
without fear.

As I've said before, this isn't Python. And whether or not my proposal
would be possible in a Python parser is of absolutely no interest to
me. Clearly it _is_ possible in Ruby's parser, it's even possible in
Ruby itself.

Well great! I'm not really sure how that script works, but cool. However,
what you have there is a marked departure from how Python actually works.

Oh noes!! You mean my Ruby script is a marked departure from Python?
Heaven forfend!

And sorry to be frank about this:

No, you're not. Not even a tiny bit.

I've been cordial and fact oriented in
this discussion,

Actually, Tony, I've found you to be arrogant and condescending
throughout. I've merely responded in kind.

Not only are you strawmanning me here, you're being a right c--t.

I'm strawmanning? *I'm* strawmanning?? Thanks for the tip, Mr. Your-
Proposal-Is-Impossible-But-Only-If-I-Set-Ridiculous-Conditions-Such-As-
Requiring-Python's-Parser-For-Some-Reason. And have you forgotten
this?

And a bit of supplemental information: I conducted a poll of what Rubyists'
favorite features are in the language. Blocks were #1 by a wide margin.

Clearly, this one deserves at least honorable mention on the all-time
list of most flagrant strawmen. I think you're projecting.

And by the way, I've heard that in other English-speaking countries,
the profanity you used is not considered as shockingly offensive as it
is in the United States. Perhaps you're from one of those countries
and are unaware that in America it's among the most vile of curse
words. I know that you, with your emphasis on cordiality and fact-
orientation, will appreciate me bringing this to your attention.

That being said I will plead guilty to being a terrible spokesman for
my ideas (and this extends well beyond the current discussion) because
I lack tact, empathy, and sensitivity... in short, I'm an asshole (and
not, as you suggested, someplace a couple of inches anterior.) This
has bitten me more times than I can say, but in the end, I gotta be me.

···

On May 21, 10:33 pm, Tony Arcieri <t...@medioh.com> wrote:
On May 19, 3:23 pm, Tony Arcieri <t...@medioh.com> wrote:

On Tue, May 19, 2009 at 3:40 PM, J Haas <Myrd...@gmail.com> wrote:

If we're admitting that a parser is possible, but would only be complex, I
would say yes, it's worth it.

Ruby itself is based on the idea that the computer should work for you, not
the other way around. The language should be made simpler for a human to
understand and work with, even if it makes the implementation more complex and
slower. My understanding is, this is the founding principle of Ruby -- the
whole reason it was invented in the first place.

Of course, the more important question is whether this can be done in such a
way that is either wholly backwards compatible, or which doesn't irritate
people who like Ruby's current syntax?

The social aspect seems to be the larger issue, here.

···

On Wednesday 20 May 2009 05:28:34 pm Tony Arcieri wrote:

You are proposing a Rube Goldberg contraption whereby the scanner would
require some degree of grammatical awareness. This is a complex solution.
The minor flaw is that you don't like "end" statements. Is the minor flaw
of having repeated end statements really worth the level of complexity the
solution would require?

If you break up code into more files, or use a folding editor, or use
an editor that lets you jump to code by a method name, scrolling is a
non-issue.

Rick's point remains. If this is an issue you're facing, get a better editor.

-greg

···

On Wed, May 20, 2009 at 3:44 PM, Juan Zanos <juan_zanos@talkhouse.com> wrote:

On May 20, 2009, at 2:51 PM, Rick DeNatale wrote:

On Wed, May 20, 2009 at 2:35 PM, J Haas <Myrdred@gmail.com> wrote:

On May 20, 8:51 am, Rick DeNatale <rick.denat...@gmail.com> wrote:

Seriously, if you measure things by avoiding extra keystrokes, get a
better editor. I value readability over parsimony of lexical items.

Cluttering up your code with "end" everywhere makes it less readable,
not more.

Honestly, that's subjective. Some people prefer delimiters some don't.

Is it subjective? Neither method is ambiguous. So no problem there. But
scrolling 16% more often? That must have some cost to readability.

Well, to be fair to Guido, in the case of Python it already has indent-based
syntax. The language is already structured in a way that precludes indent
blocks in expressions, and to him the problem of adding multi-line indented
expressions is a far more difficult tradeoff as compared to changing some
fundamental assumptions of the language.

However, to a Rubyist, taking away multi-line blocks would be a cardinal
sin...

···

On Wed, May 20, 2009 at 11:29 PM, Bill Kelly <billk@cts.com> wrote:

My preferences are opposite to Guido's, above. A flexible
lambda, for instance, is *far* more important to me than
what I consider to be a minor nuisance of nested 'end'
statements. (And non-nested 'end' statements don't bother
me at all. Some percentage of extra scrolling in the
editor isn't of any relative importance to me.)

--
Tony Arcieri
medioh.com

Another concern I have about this idea, though, is having essentially
two forks of Ruby lexically speaking. It's not much of an obstacle,
but it is a minor difference that someone who comes along later to
maintain your code might find confusing or off-putting. And even
though this particular change might be relatively minor, where do we
draw the line? What makes us decide whether another optional syntax
change should be integrated into the language? Even many small
changes add up to a big difference in the way the code looks and the
ease of maintainability.

Good point. There might be a way to go back and forth between the two,
though,if that were any help.
i.e.
a = proc { 3+3 }.
a.to_ruby_indented.to_ruby or what not (viz ruby2ruby).

And the authors of gems using this syntax could require them
transparently, i.e.
some method like require_indented 'filename' or what not.

Macros, as I suggested above, would _really_ move in the direction of
potential Ruby code that looks radically different. But the payoff
would be enormous expressive power, the ability to mold the language
to suit the application domain in a very comprehensive way. The
removal of 'end', by contrast, would be only a slight improvement. It
would remove some visual noise and might attract a few Python
programmers. As I said, I think it's worth it if it's easy to
implement, but not if it's more difficult.

Interesting--it's been awhile since I used C...what would
macros...essentially do? An example of them?

Tgarding the OP suggestion: I think it's an interesting idea. Start
something for it on github and I'd be happy to help out. Here's some
resources for it:
http://ruby-toolbox.com/ "testing frameworks"

The only real concern with it is that there is may be ambiguity if
someone were to use the "a ? b : c" syntax (whatever it's called) and
split that onto multiple lines just the "perfectly wrong way"

a ? b :
c

Then that would break a naive pre processor. But not many people I know
split those constructs across multiple lines, and they definitely
wouldn't within a file they know to be using "ruby indented blocks" or
whatever you want to call it. There's also the possible collision with
1.9's new symbol
b: == :b
but again, if you disallow that on end of line's then you're good to go.

Best of luck.
-=r

···

--
Posted via http://www.ruby-forum.com/\.

Oh yes, things like Ruby's lexer/parser feedback involved in interpolated
strings makes my eyes bleed. That's sure begging for a PEG.

That said, as messy as lexer/parser feedback is we're talking about
something worse here: including grammatical knowledge in the scanner which
cannot be expressed as a CFG at all. As bad as Ruby already is, the
solution is even messier than anything which already exists.

It would involve some ad hoc grammatical analysis by the lexer for the
purposes of having a pushdown deeper in the stack terminate one which is
higher up by sneakily injecting "end" tokens. Aiee!

···

On Thu, May 21, 2009 at 4:29 PM, Ryan Davis <ryand-ruby@zenspider.com>wrote:

To be fair, if you looked at ruby's lexer and parser you'd know that we're
already down a rabbit hole.

--
Tony Arcieri
medioh.com

It doesn't really. Or at least only simplistically; by re-writing the
input code, attempting to place 'end' in the proper place based on
indentation. It breaks silently if you happen to misplace your
whitespace incorrectly, placing an 'end' in the wrong place.

As I said when I posted it:

It's very short, and pretty simple. I have no doubt that it
would need a lot of work to be robust.

In its present form, this is not something I want to do in production
code. It does however serve at least one valuable purpose: it
demonstrates that the code snippet that Tony posted, that he
specifically contrived as an example of a piece of Ruby code that
would be utterly impossible to parse without 'end' statements, was in
fact quite easily parsable.

···

On May 22, 6:32 am, Reid Thompson <reid.thomp...@ateb.com> wrote:

Tony, while I may be a newb to Ruby, I assure you that I'm no stranger
to mailing lists and Usenet, and I'm aware of these things called
"archives". Perhaps you are too. If not, allow me to demonstrate:

Tony's point was that certain constructs, like case statements, won't be
transformable into indentation only blocks. Does that make sense?
If you feel frustrated then maybe take a walk (to cool down) before
posting :slight_smile:
Take care.
-=r

···

--
Posted via http://www.ruby-forum.com/\.

Well, everything else aside: if you can't present your ideas or engage in
discussion without being an asshole, you're going to have a hard time
getting people to listen to you. I've been trying to give constructive
criticism, but when you come back at me with personal attacks I'm left to
wonder why I should even bother.

···

On Fri, May 22, 2009 at 9:30 AM, J Haas <Myrdred@gmail.com> wrote:

That being said I will plead guilty to being a terrible spokesman for
my ideas (and this extends well beyond the current discussion) because
I lack tact, empathy, and sensitivity... in short, I'm an asshole (and
not, as you suggested, someplace a couple of inches anterior.) This
has bitten me more times than I can say, but in the end, I gotta be me.

--
Tony Arcieri
medioh.com

Reid Thompson wrote:

Well great! I'm not really sure how that script works, but cool.
However,
what you have there is a marked departure from how Python actually
works.
But if you're happy with it, great. Go for it and see how popular you
can
make it.

It doesn't really. Or at least only simplistically; by re-writing the
input code, attempting to place 'end' in the proper place based on
indentation. It breaks silently if you happen to misplace your
whitespace incorrectly, placing an 'end' in the wrong place.

This is an interesting aspect of indentation-sensitive syntax.

I've had Yaml files that, technically, were valid Yaml, but I had mistakenly added some extra indentation. I then had to puzzle over some odd errors when running my program.

It seems like an easy enough mistake to make, with the unfortunate risk of creating proper Yaml, so you don't get any errors from the parser.

I've wondered if this sort thing is a problem in Python; perhaps it is less likely there that any accidental indent or out-dent will still give you well-formed code.

···

On Fri, 2009-05-22 at 14:33 +0900, Tony Arcieri wrote:

--
James Britt

www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff
www.neurogami.com - Smart application development

J Haas wrote:

My claims were it's impossible with a Pythonic lexer and a backing context
free grammar. I certainly didn't claim that if you throw enough regexes at
the problem it won't go away.

Tony, while I may be a newb to Ruby, I assure you that I'm no stranger
to mailing lists and Usenet, and I'm aware of these things called
"archives". Perhaps you are too. If not, allow me to demonstrate:

# rampant snideness elided

However justified you may feel, you're now presenting yourself really poorly here.

You may disagree that Tony was being civil (he certainly struck me as civil), but replying to perceived offense with even more rudeness is tacky. Worse, it seems a good way to kill what could continue to be a good thread.

Tacking on self-deprecating comments doesn't change that, either.

···

On May 21, 10:33 pm, Tony Arcieri <t...@medioh.com> wrote:

--
James Britt

www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff
www.neurogami.com - Smart application development

"David Masover" <ninja@slaphack.com> schrieb im Newsbeitrag news:200905251330.22874.ninja@slaphack.com...

The social aspect seems to be the larger issue, here.

This is pointing to the right direction.
But it depends on your particular semantic of "social".

(1) It would not only be a beer-table issue.
(Although many resources are always useless wasted for holy wars.)

It would probably spoil team projects and code reuse.
Given a team where one developer is familiar to pythonesque insertion.
Even if he is not one of these talibanesque people, he would probably use this technique somewhere in his scripts.
Even if it's explicitely forbidden in the project, danger is, it would be used unintentionally.
When this code is reused, other people which are not familiar to pythonesque insertion may be trapped.
Maybe when trying to adapt the code, maybe by some automatic beautifying by the editor, maybe when forced to debug this code.
This would possibly waste hours by hours while timelines fly by.

As OPoster unintentionally demonstrated in OP, some people aren't even able to format postings in NG's properly.
(As I get caught already in this trap too, I rely on capabilities of modern news_readers_.)

So, it would effectively split Rubyists into two fractions. Those, who use PyI and those who don't.
We used Ruby for writing test scripts for safety related software. PyI would have been a serious issue against using Ruby.
For not breaking existing code it would be necessary to be explicitely allowed by a special switch, not to be allowed by default. This would limit number of users.
(Maybe it is possible to implement it as a gem? This would change the picture completely.)

(2) Further, resources needed for a clean implementation and maintenance of PyI could be used for more urgent issues. (IMHO)
For example (I currently do not know the kernel of current Ruby-versions nor all current extensions because I'm still forced to use 1.6.8 or 1.8.6 for compatibility reasons.):
I would like to wait for generic Events in the central loop, not only for file descriptors and timeouts. (Limitations of "C-Lib"-select()).
Independence of OS-platform should be increased in the kernel.
Real-Time capabilities would be nice.
There are, fore sure, many issues on the wish-list for future Ruby kernels which have a higher priority.

(3) Isn't there a list where such issues are discussed? I think, Ruby is mature enough to establish such a process.
For further development, it should be tried to implement a standard like this one for "C" or "C++".
IMO, Ruby is so widely used there is more than enough reason for doing so.

Best Regards,
Michael B.

···

On Wednesday 20 May 2009 05:28:34 pm Tony Arcieri wrote:

You want me to have even more files and spend even more time folding and unfolding things. And you assume I use a crummy editor and there is a better one that magically makes a surprising number of wasted lines irrelevant. I think you accidentally illustrated that extra lines have a cost.

I can understand that people grow attached to certain styles. That's no big deal. I really like Ruby a lot. I like it better than Python. I believe in most ways it's a better language. But I'm willing to admit that Python programs are generally shorter and that is an advantage. It's silly to pretend it isn't.

Maybe it's too hard to get rid of the redundancy. Or maybe we just don't know how yet. I'm not sure. But let us at least admit it's there. We should give people credit for trying to solve the problem.

···

On May 20, 2009, at 3:50 PM, Gregory Brown wrote:

On Wed, May 20, 2009 at 3:44 PM, Juan Zanos > <juan_zanos@talkhouse.com> wrote:

On May 20, 2009, at 2:51 PM, Rick DeNatale wrote:

On Wed, May 20, 2009 at 2:35 PM, J Haas <Myrdred@gmail.com> wrote:

On May 20, 8:51 am, Rick DeNatale <rick.denat...@gmail.com> wrote:

Seriously, if you measure things by avoiding extra keystrokes, get a
better editor. I value readability over parsimony of lexical items.

Cluttering up your code with "end" everywhere makes it less readable,
not more.

Honestly, that's subjective. Some people prefer delimiters some don't.

Is it subjective? Neither method is ambiguous. So no problem there. But
scrolling 16% more often? That must have some cost to readability.

If you break up code into more files, or use a folding editor, or use
an editor that lets you jump to code by a method name, scrolling is a
non-issue.

Rick's point remains. If this is an issue you're facing, get a better editor.

-greg

But, the amount of meaningful code displayed in a single screenshot
still suffers. A screenful is a chunk of code
you can see without scrolling or jumping. The more meaning it
contains, the better you understand the code (as long as the meaning
is cleanly laid out, of course).

The point, I think, is what you gain by having "end"s
and what you lose. Since the gain is much smaller ON THE
PROGRAMMERS' PART than the loss, it's better NOT to have
"end"s. The lack of "end"s may be a headache for compiler writers.
I don't know if it's the case.

I have the same opinion as the OP, from my tiny experience with
Haskell. After only an hour or so of Haskell programming, I already
appreciated the blessing of not being forced to add
an extra line just to close a block. An "end" line doesn't add any
meaning but takes up a line.

Regards,
Ryo

···

On May 20, 9:50 am, Gregory Brown <gregory.t.br...@gmail.com> wrote:

On Wed, May 20, 2009 at 3:44 PM, Juan Zanos <juan_za...@talkhouse.com> wrote:

> On May 20, 2009, at 2:51 PM, Rick DeNatale wrote:

>> On Wed, May 20, 2009 at 2:35 PM, J Haas <Myrd...@gmail.com> wrote:

>>> On May 20, 8:51 am, Rick DeNatale <rick.denat...@gmail.com> wrote:

>>>> Seriously, if you measure things by avoiding extra keystrokes, get a
>>>> better editor. I value readability over parsimony of lexical items.

>>> Cluttering up your code with "end" everywhere makes it less readable,
>>> not more.

>> Honestly, that's subjective. Some people prefer delimiters some don't.

> Is it subjective? Neither method is ambiguous. So no problem there But
> scrolling 16% more often? That must have some cost to readability.

If you break up code into more files, or use a folding editor, or use
an editor that lets you jump to code by a method name, scrolling is a
non-issue.

Rick's point remains. If this is an issue you're facing, get a better editor.

I was thinking more like Lisp macros. Check out:

     http://www.defmacro.org/ramblings/lisp.html

steven

···

On May 21, 2009, at 8:06 AM, Roger Pack wrote:

Interesting--it's been awhile since I used C...what would
macros...essentially do? An example of them?

Perhaps a minimalist example of the "expression problem" is in order.

Take this example (in normal Ruby):

result = 2 * [1,2,3].inject(0) do |a, b|
  a + b
end
puts result

prints "12"

Here the 2 * takes precedence over the method invocation (with a block).
Furthermore, nothing precludes us from sticking additional expressions at
the end of the block:

result = 2 * [1,2,3].inject(0) do |a, b|
  a + b
end + 1
puts result

Here the 2 * [method_with_block] is lower precedence than the plus operand,
so we get a parse tree ala:

(+ (* 2 [method_with_block]) 1)

And that doesn't even include setting "result"!

But through funky lexer tricks, we want indent blocks to terminate the
entire expression stack somehow. We want [method_with_block] when it hits a
dedent to pop all the way up the pushdown stack. It also means that a
method with a block must always be the rightmost operand in any pushdown.

That is not an easy problem to solve, and afaict cannot be done in a context
free grammar. It also limits some of the expressivity that Ruby normally
provides. Quite frequently I do something like:

str = [a, b, c].map do |x|
  thing1 = do_something_to x
  thing2 = do_something_else_to x
  "#{thing1}:#{thing2}"
end.join(",")

An ident-sensitive grammar would preclude that sort of thing.

But hey, if anyone's still about trying to make an indent-sensitive Ruby,
here's a nice simple example based on the one above to cut your teeth on:

result = 2 * [1,2,3].inject(0) do |a, b|
  a + b
puts result

Parse that. I dare ya.

···

On Thu, May 21, 2009 at 5:20 PM, Tony Arcieri <tony@medioh.com> wrote:

It would involve some ad hoc grammatical analysis by the lexer for the
purposes of having a pushdown deeper in the stack terminate one which is
higher up by sneakily injecting "end" tokens. Aiee!

--
Tony Arcieri
medioh.com

James Britt wrote:

I've wondered if this sort thing is a problem in Python; perhaps it is less likely there that any accidental indent or out-dent will still give you well-formed code.

I've only minimally looked at python, but I'm pretty sure that it will throw an error when indentation is fouled.

Well, everything else aside: if you can't present your ideas or engage in
discussion without being an asshole, you're going to have a hard time
getting people to listen to you. I've been trying to give constructive
criticism, but when you come back at me with personal attacks I'm left to
wonder why I should even bother.

It looks like another recap will be necessary.

In the beginning, I began a thread containing a proposal to implement
Python-style syntactically significant indentation in Ruby (this
proposal, I might add, was entirely optional, and would leave in place
a system which would support _either_ indentation-delimited code
blocks or keyword-delimited code blocks.) At the time I posted it, I
expected opposition. I expected to be told that the requirement to
fill the code base 1/6th full of 'ends' actually _improved_
readability, and I was not disappointed. I expected ridiculous
strawman arguments involvingremovalofallspacesfromEnglish, and I was
not disappointed. I expected to have my motives questioned, with
insinuations that I secretly hated Ruby, and I was not disappointed.
Furthermore, I was prepared to ignore every one of these arguments, as
every one is fallacious. I trust in rational people to see the fallacy
behind each and will not do the fallacies the dignity of treating them
as though they were serious arguments, worthy of respectful rebuttal.

What I did _not_ expect to hear, however, was a claim that my proposal
was actually _impossible_.

You can have the Pythonic indent syntax or a purely expression
based grammar with multi-line blocks. You can't have both.

This took me by surprise, and for all I know, it might well be true.
As you may have surmised, I do not claim syntactical parser design or
theory among my areas of expertise. For all I know, there was some
reason I wasn't aware of why what I proposed was impossible, even in
theory. And yet, I know I'd seen a script awhile ago, which I thought
I had saved on an old hard drive somewhere, which could actually _do_
Pythonic indentation in Ruby. And so I asked you for clarification.

I'm having a hard time following why. Can you provide an example of a
Ruby snippet that couldn't be done with scoping defined by
indentation?

That's all I needed. If there were a theoretical reason why Python-
style indentation were incompatible with some fundamental concept in
Ruby, it should be easy to provide an example of a Ruby construct
which would be impossible to parse without the use of 'end' or some
other keyword as a block delimiter. That's all it would take. That's
all I asked for. Did I get it?

A multi-line block returning a value, e.g.
foo = somemethod do |arg1, arg2, arg3|
  x = do_something arg1
  y = do_something_else x, arg2
  and_something_else_again y, arg3
end

Or for that matter, a multi-line lambda:

foo = lambda do |arg1, arg2, arg3|
  x = do_something arg1
  y = do_something_else x, arg2
  and_something_else_again y, arg3
end

I looked at these and was flabbergasted. In what way were these at all
incompatible with syntactic indentation? What would be impossible to
parse about this?

foo = somemethod do |arg1, arg2, arg3|:
  x = do_something arg1
  y = do_something_else x, arg2
  and_something_else_again y, arg3

Or this?

foo = lambda do |arg1, arg2, arg3|:
  x = do_something arg1
  y = do_something_else x, arg2
  and_something_else_again y, arg3

How on Earth did these examples meet the test of being incompatible
with Python-style indentation? You provided a number of other examples
that similarly baffled me as to how they were supposed to support your
thesis. It was at this point that I began to lose patience with you
and suspect that you might be talking out of your ass.

You keep on saying this, yet I have not seen one example of code that
demonstrates that using dedent couldn't work. Basically, we're looking
for some code which, if you removed the all ends, a script following
simple deterministic rules would not be able to unambigiously decide
where to put them back.

Your response was:

Okay, you just want an example I guess.

(jh: what was your first clue?)

Here is an example Ruby program:

foo = [1,2,3]
x = foo.map do |n|
  n += 1
  n *= 2
end
result = case x
when Array
  x.map! do |n|
    n *= 3
    n += 4
  end
when NilClass
  x
end
result = if result.size > 10
  result[0..2]
else
  result
end
p result

The output of this program is:

[16, 22, 28]

Show me how you would parse the equivalent program in an
indentation-sensitive Ruby, e.g.:

Finally, I thought, an example! Time to dig out that old Ruby script
for preprocessing Python-style Ruby files... ah, there it is, on the
old MacBook Pro... copy it over to the current computer... hmm, no
doc... throw in a few quick and dirty patches to make it run; after
all, this is just a proof-of-concept, right? Edit the file, remove the
'end's and insert colons after the keywords which began those blocks,
run it through and... hey, whaddaya know, [16, 22, 28], first time
through. Looks like ol' Tony really _was_ talking out of his ass, eh?

I did not trouble to hide my lack of respect in my response conveying
that your proof of impossibility was false on its face. However, I do
not think that anything at all in that post could have been construed
as a "personal attack". If you disagree, please point out an example.

Your next response to me was full of backpedaling falsehoods, such as:

My claims were it's impossible with a Pythonic lexer and a backing context
free grammar.

And this:

I certainly didn't claim that if you throw enough regexes at
the problem it won't go away.

Just what do you think a regular expression engine is? Hint: it's a
parser. If application of regular expressions can solve a problem, the
problem is not insoluble by a parser.

Well great! I'm not really sure how that script works

"...but it must be magic, since it does the impossible!"

However, what you have there is a marked departure from how Python actually works.

I know I already responded to this gem with mockery, but not nearly as
much as it deserves.

But if you're happy with it, great. Go for it and see how popular you can
make it.

I don't care about being popular. If I did, I wouldn't be such an
asshole.

And then, without even waiting for a reply:

you're being a right c--t

This is, as far as I know, the first and only personal attack in this
thread, unless you want to count my self-description as an asshole to
be a personal attack. But either way, never fear, Tony, your own
precious person has yet to be attacked.

And this brings us to your most recent post in this thread.

Well, everything else aside: if you can't present your ideas or engage in
discussion without being an asshole, you're going to have a hard time
getting people to listen to you.

No, Tony, that's wrong. If I can't present my ideas or engage in
discussion without being an asshole, I'm going to have a hard time
getting people like _you_ to listen to me. People who are logical,
programmers who want the best possible language with the greatest
flexibility and expressiveness, will know that _ad_hominem_ is a
fallacy and will look to the arguments, not to the person making them.

I've been trying to give constructive
criticism, but when you come back at me with personal attacks I'm left to
wonder why I should even bother.

And now we reach the present. Tony, _what_ personal attacks? Please
cite them. Your relief at being able to use an alleged personal attack
as a fig leaf to escape your obligation to back up your claims is
palpable. An honorable person would either substantiate the claim or
retract it, rather than running and hiding and pretending to hurt
feelings.

Now, having said all that: I do not _know_ that Tony's claim is false.
As I said, I was surprised to be told that my proposal was impossible
and I lack the theoretical background to prove otherwise. So if anyone
out there agrees with Tony that Pythonic indentation in Ruby would not
be merely ill-advised but _impossible_ I'd appreciate an example. Then
I can stop wasting my time.

···

On May 22, 1:02 pm, Tony Arcieri <t...@medioh.com> wrote:

No, it doesn't, because I don't see why case statements are not
transformable into indent-only blocks. I've _done_ them using the
quick-and-dirty hacky script and they work just fine. (In cases like
Joshua's impossible.rb I had to make a minor modification to the
script to have it inject 'end ' rather than 'end\n', but it still
worked fine.)

Code speaks louder than words, right? Here's some real-world code...
it's application_controller.rb from the AuthLogic example (http://
github.com/binarylogic/authlogic_example/tree):

···

On May 22, 9:01 am, Roger Pack <rogerpack2...@gmail.com> wrote:

Tony's point was that certain constructs, like case statements, won't be
transformable into indentation only blocks. Does that make sense?

-----------------

# Filters added to this controller apply to all controllers in the
application.
# Likewise, all the methods added will be available for all
controllers.

class ApplicationController < ActionController::Base
  helper :all
  helper_method :current_user_session, :current_user
  filter_parameter_logging :password, :password_confirmation

  private
    def current_user_session
      return @current_user_session if defined?(@current_user_session)
      @current_user_session = UserSession.find
    end

    def current_user
      return @current_user if defined?(@current_user)
      @current_user = current_user_session &&
current_user_session.record
    end

    def require_user
      unless current_user
        store_location
        flash[:notice] = "You must be logged in to access this page"
        redirect_to new_user_session_url
        return false
      end
    end

    def require_no_user
      if current_user
        store_location
        flash[:notice] = "You must be logged out to access this page"
        redirect_to account_url
        return false
      end
    end

    def store_location
      session[:return_to] = request.request_uri
    end

    def redirect_back_or_default(default)
      redirect_to(session[:return_to] || default)
      session[:return_to] = nil
    end
end

-----------------

Nothing particularly special about this code, right? Pretty standard
Ruby, if a bit simple? 37 non-blank, non-comment lines, of which 9
consist of the bare word "end". I defy anyone to tell me that the code
would be less readable as this:

-----------------

# Filters added to this controller apply to all controllers in the
application.
# Likewise, all the methods added will be available for all
controllers.

class ApplicationController < ActionController::Base
  helper :all
  helper_method :current_user_session, :current_user
  filter_parameter_logging :password, :password_confirmation

  private
    def current_user_session:
      return @current_user_session if defined?(@current_user_session)
      @current_user_session = UserSession.find

    def current_user:
      return @current_user if defined?(@current_user)
      @current_user = current_user_session &&
current_user_session.record

    def require_user:
      unless current_user:
        store_location
        flash[:notice] = "You must be logged in to access this page"
        redirect_to new_user_session_url
        return false

    def require_no_user:
      if current_user:
        store_location
        flash[:notice] = "You must be logged out to access this page"
        redirect_to account_url
        return false

    def store_location:
      session[:return_to] = request.request_uri

    def redirect_back_or_default(default):
      redirect_to(session[:return_to] || default)
      session[:return_to] = nil

Juan Zanos wrote:

I'm willing to admit that Python programs are generally shorter

Are you sure of that? Care for a round of golf?

···

--
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407