Forum: Ruby Pythonic indentation (or: beating a dead horse)

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
J Haas (Guest)
on 2009-05-20 01:40
(Received via mailing list)
Greetings, folks. First time poster, so if I breach
any etiquette I sincerely apologize. I'm a bit of a Ruby N. who's
been
bouncing around between Python and Ruby, not entirely satisfied with
either
and wishing both were better. Two years ago I had no familiarity with
either
language, then I quit working for Microsoft and learned the true joy
of
programming in dynamic languages.

I am not a zealot and have little tolerance for zealotry, and I have
no
desire to get involved in holy wars. I'm a little apprehensive that
I'm
about to step into one, but here goes anyway. In general, I prefer
Ruby's
computational model to Python's. I think code blocks are cool, and I
love Ruby's
very flexible expressiveness. I dig the way every statement is an
expression,
and being able to return a value simply by stating it rather than
using the
'return' keyword. I hate Python's reliance on global methods like len
() and
filter() and map() (rather than making thesem methods members of the
classes
to which they apply) and I absolutely loathe its reliance on __magic__
method names. Ruby's ability to reopen and modify _any_ class kicks
ass, and
any Python fan who wants to deride "monkeypatching" can shove it. It
rocks.

That being said, I think monkeypatching could use some syntactic sugar
to
provide a cleaner way of referencing overridden methods, so instead
of:

  module Kernel
    alias oldprint print
    def print(*args)
      do_something
      oldprint *(args + [" :-)"])
    end
  end

...maybe something like this:

  module Kernel
    override print(*args)
      do_something
      overridden *(args + [" :-)"])
    end
  end

But I digress... the purpose of this post is to talk about one of the
relatively
few areas where I think Python beats Ruby, and that's syntatically-
significant
indentation.

Before I get into it, let me say to those of you whose eyes are
rolling way
back in your skulls that I have a proposal that will allow you to keep
your
precious end keyword if you insist, and will be 100% backward
compatible with
your existing code. Skip down to "My proposal is" if you want to cut
to the
chase.

When I encounter engineers who don't know Python, I sometimes ask them
if they've heard anything about the language, and more often than not,
they
answer, "Whitespace is significant." And more often than not, they
think that's
about the dumbest idea ever ever. I used to think the same. Then I
learned
Python, and now I think that using indentation to define scope is
awesome.
I started looking over my code in C++ and realized that if some
nefarious
person took all of my code and stripped out the braces, I could easily
write a simple script in either Python or Ruby ;-) to restore them,
because
their locations would be completely unambiguous: open braces go right
before
the indentation level increases, close braces go right before it
decreases. And
having gotten used to this beautiful way of making code cleaner, I
hate that
Ruby doesn't have it.

I've read the two-year-old thread at
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/...
(well, most of it, anyway) and I'll answer some of the objections
raised
in it, but first let me illustrate the scope of the problem with the
output
of a quick and dirty script I wrote:

> 2: 4082
> 1: 16505

My friends, when ONE OUT OF EVERY SIX of your code lines consists of
just the
word "end", you have a problem with conciseness. I recognize that
syntactically-
significant indentation is not perfect, and it would bring a few pain
points
with it. But let me say that again: ONE OUT OF EVERY SIX LINES, for
crying out
loud! This should be intolerable to engineers who value elegance.
"Streaks"
means what you'd expect: there are four places in the scanned files
that look
like this:

            end
          end
        end
      end
    end
  end
end

This is *not* DRY. Or anything remotely resembling it. This is an
ugly blemidh on a language that otherwise is very beautiful. The
problem of
endless ends is exacerbated by Ruby's expressiveness, which lends
itself to  very short methods, which can make defs and ends take up a
large amount of space relative to lines of code that actually do
something.

Even if you can find some ways in which the explicit "end" keyword is
preferable
to letting indentation do the talking... one out of every six lines.

Matz's objections in the cited thread were:

  * tab/space mixture

Well, tough. Programmers shouldn't be using freakin' tabs anyway, and
if they
are, they _definitely_ shouldn't be mixing them with spaces. I don't
think
it's worthwhile to inflate the code base by a staggering 20% to
accommodate
people who want to write ugly code, mixing tabs and spaces when
there's no
reason to. And if for some reason it's really, really critical to
support this
use case, there could be some kernel-level method for specifying how
many
spaces a tab equates to, so the interpreter can figure out just how
far indented
that line with the tabs is.

  * templates, e.g. eRuby

Not having used eRuby and therefore not being very familiar with it, I
don't
want to comment on specifics other than to note that plenty of Python-
based
template systems manage to get by.

 * expression with code chunk, e.g lambdas and blocks

I don't really see the problem. My blocks are generally indented
relative to
the context to which they're being passed, isn't that standard?

My proposal is to, first, not change a thing with respect to existing
syntax. Second, steal the : from Python and use it to signify a scope
that's marked by indentation:

  while some_condition
    # this scope will terminate with an 'end' statement
    do_something
  end

  while some_condition:
    # this scope will terminate when the indentation level decreases
to the
    # level before it was entered
    do_something

  %w{foo bar baz}.each do |val|
    print val
  end

  %w{foo bar baz}.each do |val|:
    print val

A valid objection that was raised in the earlier thread was regarding
a
quick and easy and common debugging technique: throwing in print
statements

  def do_something(a, b, c)
print a, b, c  # for debugging purposes
    a + b + c
  end

  def do_something(a, b, c):
print a, b, c  # error! unexpected indentation level
    a + b + c
  end

We can get around this by saying that braces, wherever they may
appear,
always define a new scope nested within the current scope, regardless
of
indentation.

  def do_something(a, b, c):
{ print a, b, c }  # this works
    a + b + c

Alternatively, perhaps a character that's not normally valid at the
start of a
line (maybe !) could tell the interpreter "treat this line as though
it were
indented to the level of the current scope":

  def do_something(a, b, c):
!print a, b, c
    a + b + c

Well, I think that's probably enough for my first post. Thank you for
your
time, and Matz, thanks for the language. Thoughts, anyone?

--J
Joel VanderWerf (Guest)
on 2009-05-20 01:59
(Received via mailing list)
J Haas wrote:
> My friends, when ONE OUT OF EVERY SIX of your code lines consists of
> just the

John McCain, is that you? ;)

> word "end", you have a problem with conciseness. I recognize that
> syntactically-

A line consisting of just /\s+end/ is of very low complexity, however.

>             end
>           end
>         end
>       end
>     end
>   end
> end
>
> This is *not* DRY. Or anything remotely resembling it. This is an
> ugly blemidh on a language that otherwise is very beautiful.

It's a blemish all right, but not on the language.
Benjamin K. (Guest)
on 2009-05-20 02:21
(Received via mailing list)
On Tue, May 19, 2009 at 17:40, J Haas <removed_email_address@domain.invalid> 
wrote:
>
> Well, tough. Programmers shouldn't be using freakin' tabs anyway, and
> if they are, they _definitely_ shouldn't be mixing them with spaces. I don't
> think it's worthwhile to inflate the code base by a staggering 20% to
> accommodate people who want to write ugly code, mixing tabs and spaces when
> there's no reason to. And if for some reason it's really, really critical to
> support this use case, there could be some kernel-level method for specifying how
> many spaces a tab equates to, so the interpreter can figure out just how
> far indented that line with the tabs is.

Well, tough?

I like to use tabs to indent, and spaces to align. (a la
http://www.emacswiki.org/emacs/IntelligentTabs )

Don't like it? Well, tough.

All kidding aside, who cares? Write a preprocessor.

Benjamin K.
Tony A. (Guest)
on 2009-05-20 02:24
(Received via mailing list)
Let me get right to the heart of the issue here.  It really comes down
to
this:

On Tue, May 19, 2009 at 3:40 PM, J Haas <removed_email_address@domain.invalid> 
wrote:

> 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.

In Python, all indent blocks are statements.  This is why Python can't
have
multi-line lambdas using Python's indent rules: lambdas are only useful
as
expressions, but all indent blocks in Python are statements.  The same
issue
carries over to blocks, as a good deal of the time you want a method
which
takes a block to return a value (e.g. map, inject, filter, sort, grep)

There's quite an interesting interplay of design decisions to make
Python's
indent-sensitive grammar work the way it does.  Indent blocks in Python
have
no terminator token, whereas every expression in a Ruby-like grammar
must be
terminated with ";" or a newline.  This works because Python's
expressions
are a subset of its statements, so it can have different rules for
statements versus expressions.

Implicit line joining works in Python because the only syntactic
constructions which can exist surrounded in [...] (...) {...} tokens are
expressions, so you can't put an indent block inside of these.  If you
have
an indent-sensitive Ruby with implicit line joining, you limit the
expressiveness of what you can do inside any syntactic constructs
enclosed
by these tokens.

If you want to have indent blocks in a purely expression-based grammar,
you
need to use a syntax more like Haskell.  I've seen a somewhat
Python-looking
language called Logix which uses Haskell's indent rules.  It was created
by
Tom L., who has since gone on to author Hobo in Ruby, and for what
it's
worth now says he prefers Ruby's syntax.  Go figure.

P.S. I tried to make a Ruby-like language with an indentation-sensitive
syntax.  These are the lessons I learned.  I gave up and added an "end"
keyword.
J Haas (Guest)
on 2009-05-20 02:25
(Received via mailing list)
Well, I found one of those breaches of etiquette I was worried
about... apparently wrapping my lines at 80 characters was not a good
idea. Sigh.

On May 19, 2:59 pm, Joel VanderWerf <removed_email_address@domain.invalid> 
wrote:
> John McCain, is that you? ;)

C'mon, you know perfectly well that John McCain can't use a
computer. :P

> > word "end", you have a problem with conciseness. I recognize that
> > syntactically-
>
> A line consisting of just /\s+end/ is of very low complexity, however.

Takes up just as much vertical space on the screen as the most complex
line you'll ever see. And even so... very low complexity or not, it's
_unnecessary_, which means any degree of complexity above zero is bad.

> > This is *not* DRY. Or anything remotely resembling it. This is an
> > ugly blemidh on a language that otherwise is very beautiful.
>
> It's a blemish all right, but not on the language.

If not the language, then where? In the library code? Maybe those four
places where "end" is repeated seven consecutive times are poorly
engineered and could be refactored, but how about the nearly thousand
times "end" is repeated three or more times? Is every one of those the
result of poor engineering on the part of the library programmers, or
were at least some of them forced on the programmers by the language?

One statistic that I didn't print out from my script was that there
are an average of 135 lines of "end" per file. For a language that
prides itself on expressiveness and brevity, this is just plain silly.

--J
J Haas (Guest)
on 2009-05-20 02:31
(Received via mailing list)
On May 19, 3:20 pm, Benjamin K. <removed_email_address@domain.invalid> wrote:
> Well, tough?

I could probably have found a more tactful way of putting this. Sorry.

> I like to use tabs to indent, and spaces to align. (a 
lahttp://www.emacswiki.org/emacs/IntelligentTabs)

This wouldn't be a problem, at least it's not a problem in Python and
needn't be a problem in Ruby. Having an unclosed paren, bracket, or
brace results in automatic line continuation and you can put whatever
combination of spaces and tabs you'd like on the next line. It'll be
logically considered part of the line before.

Also, I should add that mixing tabs and spaces would only be a problem
if you did something like this: (leading dots represent spaces)

......while some_condition:
\t\tdo_something  # interpreter can't tell indentation level here

You could freely mix tabs and spaces as long as they match up from the
start:

......while some_condition:
......\tdo_something  # interpreter can tell that this indentation
level is "one more" than previous

> All kidding aside, who cares? Write a preprocessor.

Don't need to; it's already been done. But I'd rather see the language
improved.

--J
J Haas (Guest)
on 2009-05-20 02:50
(Received via mailing list)
On May 19, 3:23 pm, Tony A. <removed_email_address@domain.invalid> wrote:
> On Tue, May 19, 2009 at 3:40 PM, J Haas <removed_email_address@domain.invalid> wrote:
> > 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.

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?

> In Python, all indent blocks are statements.  This is why Python can't have
> multi-line lambdas using Python's indent rules: lambdas are only useful as
> expressions, but all indent blocks in Python are statements.

This seems like a problem with Python, not a problem with indentation.

> The same issue
> carries over to blocks, as a good deal of the time you want a method which
> takes a block to return a value (e.g. map, inject, filter, sort, grep)

Again, I would really like to see an example of the sort of thing
you'd want to do here that simply requires "end" to work.

> There's quite an interesting interplay of design decisions to make Python's
> indent-sensitive grammar work the way it does.  Indent blocks in Python have
> no terminator token, whereas every expression in a Ruby-like grammar must be
> terminated with ";" or a newline.

Well, every expression in a Ruby-like grammar must be terminated by a
token. What that token must be depends on the grammar. Why not
something like this? (and please forgive the highly unorthodox
pseudocode syntax)

parse_line_indent:
  if indentation = previous_line_indentation: do_nothing
  if indentation > previous_line_indentation:
push_indentation_to_indent_stack_and_enter_new_scope
  if indentation < previous_line_indentation:
    while indentation > top_of_indent_stack:
      insert_backtab_token   # here's your statement terminator
      pop_top_of_indent_stack
    if indentation != top_of_indent_stack: raise IndentationError

In other words, the parser treats an indentation level less than the
indentation level of the previous line as a statement-terminating
token.

> Implicit line joining works in Python because the only syntactic
> constructions which can exist surrounded in [...] (...) {...} tokens are
> expressions, so you can't put an indent block inside of these.  If you have
> an indent-sensitive Ruby with implicit line joining, you limit the
> expressiveness of what you can do inside any syntactic constructs enclosed
> by these tokens.

This sorta makes sense but I'd really like to see a concrete example
of what you're talking about. It doesn't seem like this would be an
insurmountable difficulty but it's hard to say without the example.

> If you want to have indent blocks in a purely expression-based grammar, you
> need to use a syntax more like Haskell.

Being completely unfamiliar with Haskell (functional programming's
never been my strong suit) I can't really comment.

> P.S. I tried to make a Ruby-like language with an indentation-sensitive
> syntax.  These are the lessons I learned.  I gave up and added an "end"
> keyword.

I'll be glad to take the benefit of your practical experience, but at
the risk of seriously violating DRY, some sort of demonstration of
something that you can do with "end" but couldn't do with indentation
would be nice.

--J
Tony A. (Guest)
on 2009-05-20 03:41
(Received via mailing list)
On Tue, May 19, 2009 at 4:50 PM, J Haas <removed_email_address@domain.invalid> 
wrote:

> 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?
>

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'm sure you're aware the "multi-line lambda" problem is somewhat
infamous
in the Python world.  Guido van Rossum himself has ruled it an
"unsolvable
problem" because of the statement-based nature of Python indent blocks.
Lambdas must be expressions or they are worthless, and there is no way
to
embed an indent block inside of a Python expression.

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.

This seems like a problem with Python, not a problem with indentation.
>

As I said, a Haskell-like syntax would facilitate including indent
blocks in
a purely expression-based grammar.  It's Python's statement-structured
syntax that's incompatible.  However the sort of syntax you would get
from a
Haskell-like approach is going to be different than Python's.

You can have a look at Logix, which is a purely expression based
language
which tries to mimic Python's syntax while using Haskell-styled indent
rules.  This is about the best you can do:

http://web.archive.org/web/20060517203300/www.live...

Well, every expression in a Ruby-like grammar must be terminated by a
> token. [... snip ...]


> In other words, the parser treats an indentation level less than the
> indentation level of the previous line as a statement-terminating
> token.
>

Because there are statements which contain multiple indent blocks, such
as
if or try/catch.  If you wanted to carry over Rubyisms, this would
include
the case statement, e.g.

case foo
when bar
  ...
when baz
  ...

Therefore you can't just treat a "dedent" as a statement terminator,
because
a single statement may itself contain multiple "dedent" tokens.

The best solution I could think of for this was a syntactically relevant
blank line, which sucks.  It also requires lexer logic more complex than
Python to handle the case of a syntactically relevant newline, which in
turn
pollutes the grammar.



> of what you're talking about. It doesn't seem like this would be an
> insurmountable difficulty but it's hard to say without the example.
>

This is valid Ruby:

on_some_event(:something, :filter => proc do
  something_here
  another_thing_here
  etc
end)

Implicit line joining removes any newline tokens inside of (...) [...]
{...}
type syntactic constructions.  So it becomes impossible to embed
anything
with an indent block inside of expressions enclosed in any of these
tokens.

And now we've hit an entirely new can of worms: how do you make implicit
line joining work when parens are optional?
Eric H. (Guest)
on 2009-05-20 03:53
(Received via mailing list)
On May 19, 2009, at 15:25, J Haas wrote:
>>> This is *not* DRY. Or anything remotely resembling it. This is an
>>> ugly blemidh on a language that otherwise is very beautiful.
>>
>> It's a blemish all right, but not on the language.
>
> If not the language, then where? In the library code? Maybe those four
> places where "end" is repeated seven consecutive times are poorly
> engineered and could be refactored,

They almost certainly could be, this is a sign of strong code-smel

> but how about the nearly thousand
> times "end" is repeated three or more times? Is every one of those the
> result of poor engineering on the part of the library programmers, or
> were at least some of them forced on the programmers by the language?
>
> One statistic that I didn't print out from my script was that there
> are an average of 135 lines of "end" per file. For a language that
> prides itself on expressiveness and brevity, this is just plain silly.

Does anybody complain about terminating '}' in C, C++ or Java?  Does
anybody complain about terminating '.' on sentences?  (There's a
folowing capital letter for disambiguation!)  I think we need to
remove all useles constructs from all languages
Benjamin K. (Guest)
on 2009-05-20 03:59
(Received via mailing list)
On Tue, May 19, 2009 at 19:49, Eric H. <removed_email_address@domain.invalid> 
wrote:
> Does anybody complain about terminating '}' in C, C++ or Java?

Python programmers?

:-)

> Does anybody
> complain about terminating '.' on sentences?  (There's a following capital
> letter for disambiguation!)

I agree with your point, but I don't this argument helps - computer
languages and human languages are two fairly distinct classes, with
different origins, requirements, and, um...parsers.

In my opinion they aren't always comparable.

Ben Kudria
Eric H. (Guest)
on 2009-05-20 04:12
(Received via mailing list)
On May 19, 2009, at 16:58, Benjamin K. wrote:

>> capital
>> letter for disambiguation!)
>
> I agree with your point, but I don't this argument helps - computer
> languages and human languages are two fairly distinct classes, with
> different origins, requirements, and, um...parsers.
>
> In my opinion they aren't always comparable.

I may have ben too sutle  Maybe your email program spel-chex  I
certainly didnt have useles double leters in my original
Gregory B. (Guest)
on 2009-05-20 04:19
(Received via mailing list)
On Tue, May 19, 2009 at 5:40 PM, J Haas <removed_email_address@domain.invalid> 
wrote:

> Well, I think that's probably enough for my first post. Thank you for
> your
> time, and Matz, thanks for the language. Thoughts, anyone?

Implement it, post it on github, then post back here and see if people
like it.   These conversations in which people pretend to try to
convince one another just to assert their views are much less
productive than just solving whatever the original problem is.

-greg
Benjamin K. (Guest)
on 2009-05-20 04:27
(Received via mailing list)
On Tue, May 19, 2009 at 20:11, Eric H. <removed_email_address@domain.invalid> 
wrote:
> I may have ben too sutle  Maybe your email program spel-chex  I certainly
> didnt have useles double leters in my original

Doh :-)

I have a compulsive habit of correcting (perceived!) typos in quotes.
I should probably stop.

Ben
Aaron P. (Guest)
on 2009-05-20 04:28
(Received via mailing list)
On Wed, May 20, 2009 at 08:58:44AM +0900, Benjamin K. wrote:
>
> I agree with your point, but I don't this argument helps - computer
> languages and human languages are two fairly distinct classes, with
> different origins, requirements, and, um...parsers.
>
> In my opinion they aren't always comparable.

Did you include Comparable and implement <=> ?
Brian C. (Guest)
on 2009-05-20 14:45
J Haas wrote:
> I'm a bit of a Ruby N.
...
> I have a proposal

Funny how suggestions for radical changes mainly come from people who,
by their own admission, have not used Ruby seriously in its current
form. But I certainly don't hold this against anyone, because I was the
same myself at first.

Space-delimited syntax has its place: it works well for HAML, which I
love. But I'd hate it for Ruby. I want to be able to disable blocks of
code by wrapping them with

  if false
    ...
  end

and generally throw code around without having to re-indent it (even
though I *do* normally stick strongly to standard indentation). In
practice, it's much less frequent that I comment out a block of HAML,
say.

There's one case where the current behaviour *does* trip me up, and
that's in DSLs. For example:

  context "a test" do    <<<
    setup do             <<<
      @foo = Foo.new
    end
    should "be empty" do <<<
      assert @foo.empty?
    end
  end

Miss one of the magic 'do's and you get an error later (perhaps much,
much later, say at the end of the file). These can be hard to find;
sometimes I resort to a binary chop. However if I happen to have ruby1.9
lying around I can run it through that, and it gives me warnings about
where indentation is not as expected.

But even then, this does not bug me as much as having Python syntax
would.

Of course, syntax in itself adds nothing to the functionality of the
language, but people have extremely strong preferences. LISP programmers
are strongly wedded to its syntax; Python programmers are strongly
wedded to its syntax too. So if you like Python syntax (and that's more
important to you than other language features), then program in Python.
Juan Z. (Guest)
on 2009-05-20 18:04
(Received via mailing list)
On May 19, 2009, at 5:40 PM, J Haas wrote:
> My friends, when ONE OUT OF EVERY SIX of your code lines consists of
> just the word "end", you have a problem with conciseness. I

Yes, it's a problem.  There is no point in pretending otherwise. The
language
would be even better if this issue were solved. It sounds like it
could be
adequately solved with some type of meaningful indentation.

It doesn't seem like it has to be one way or another.  You could have
meaningful indentation and still use end for ambiguous cases.  That
would be
nice.  This would also be consistent with Ruby's optional parens for
function
use and declaration.  Backward compatibility would also make it
possible to
make the transition.
J Haas (Guest)
on 2009-05-20 19:06
(Received via mailing list)
On May 19, 4:49 pm, Eric H. <removed_email_address@domain.invalid> wrote:
> Does anybody complain about terminating '}' in C, C++ or Java?

I do, now. Redundancy irritates me.

> Does anybody complain about terminating '.' on sentences?

If the period accounted for one-sixth of English text, perhaps they
would.
J Haas (Guest)
on 2009-05-20 19:10
(Received via mailing list)
On May 19, 5:19 pm, Gregory B. <removed_email_address@domain.invalid> wrote:
> Implement it, post it on github, then post back here and see if people
> like it.   These conversations in which people pretend to try to
> convince one another just to assert their views are much less
> productive than just solving whatever the original problem is.

Ugh, pass. I've wasted far too much of my life coding what I thought
were useful features for open-source projects only to find that the
committers didn't share my opinion. I ain't touching something like
this unless there's at least some reasonable chance the patch might
actually get accepted.

If you want to try this out, as I said earlier in this thread,
preprocessors exist. And seem to work, which kind of belies the claim
that this change would be impossible.
Charles J. (Guest)
on 2009-05-20 19:24
(Received via mailing list)
On May 20, 2009, at 10:10 AM, J Haas wrote:

> Ugh, pass. I've wasted far too much of my life coding what I thought
> were useful features for open-source projects only to find that the
> committers didn't share my opinion. I ain't touching something like
> this unless there's at least some reasonable chance the patch might
> actually get accepted.
>
One of the nice advantages of an open source project like ruby is that
you can fork it, and take it in directions not held by the original
developers. Become your own committer. That should be the least of
your worries. If you really do have a better mouse-trap you will have
no problems about finding people who will join *you* rather than the
other way around.

Cheers--

Charles
---
Charles J.
Advanced Computing Center for Research and Education
Vanderbilt University
Rick D. (Guest)
on 2009-05-20 19:53
(Received via mailing list)
On Wed, May 20, 2009 at 11:05 AM, J Haas <removed_email_address@domain.invalid> 
wrote:
> On May 19, 4:49 pm, Eric H. <removed_email_address@domain.invalid> wrote:
>> Does anybody complain about terminating '}' in C, C++ or Java?
>
> I do, now. Redundancy irritates me.
>
>> Does anybody complain about terminating '.' on sentences?
>
> If the period accounted for one-sixth of English text, perhaps they
> would.

wellwhydontwegetridofallpunctuationthingslikespacescommassemicolonsquotesetcperiodcertainlytakeupmuchmoreofourprosethantheydeserveandcapitalizationeatsupvaluableverticalspaceandnoneedforparagraphseparationeither

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



--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
Michael Bruschkewitz (Guest)
on 2009-05-20 20:06
(Received via mailing list)
"J Haas" <removed_email_address@domain.invalid> schrieb im Newsbeitrag
news:removed_email_address@domain.invalid...
..."pythonic insertion"...

I have some suspicion this was a joke thread.
(Hint: Format of OP)
However.
I don't want to discuss this issue because people using non-existing
whitespaces for serious coding probably have a value system which is
orthogonal to my value system.
This sort of structuring pieces of code stopped me from trying Python
seriously.
However.

Isn't there an Syntax-Highlighting Editor out there which allows
assigning
1-Point size to End-Only-Lines?
Or, why not just use white-on-white for "end"-statement?
(Maybe you additionally should use CTRL-BS as macro for "end"...)

Wouldnt this be the easiest way to solve your problem?

Regards,
Michael B.
Juan Z. (Guest)
on 2009-05-20 20:34
(Received via mailing list)
On May 20, 2009, at 11:51 AM, Rick DeNatale wrote:

>
> Blog: http://talklikeaduck.denhaven2.com/
> Twitter: http://twitter.com/RickDeNatale
> WWR: http://www.workingwithrails.com/person/9021-rick-denatale
> LinkedIn: http://www.linkedin.com/in/rickdenatale
>

That would be a valid criticism if J Haas's suggestion made things
less readable.   But having to scroll less makes things more readable.
Joshua B. (Guest)
on 2009-05-20 21:04
(Received via mailing list)
On May 19, 2009, at 5:40 PM, J Haas wrote:

> means what you'd expect: there are four places in the scanned files
>
> This is *not* DRY. Or anything remotely resembling it. This is an
> ugly blemidh on a language that otherwise is very beautiful.

It's at this point that I started to wonder if you've had a look-see
at _why's new language, Potion? Specifically:
Roger P. (Guest)
on 2009-05-20 21:22
> ...maybe something like this:
>
>   module Kernel
>     override print(*args)
>       do_something
>       overridden *(args + [" :-)"])
>     end
>   end

Yeah the inheritance chain thing is hard.
The closest you can come is with modules.

class Class
 def override &block
   m = Module.new
   m.module_eval &block
   include m
 end
end

# now

class Object
 override do
   def print *args
     super *(args + [" :-)"])
   end
 end
end

>> print 3
3 :-)

ref: http://www.ruby-forum.com/topic/176080#new last post
http://yehudakatz.com/2009/03/06/alias_method_chai...


> But I digress... the purpose of this post is to talk about one of the
> relatively
> few areas where I think Python beats Ruby, and that's syntatically-
> significant
> indentation.

Not having the "end" is indeed very clean and kind on the eyes--kind of
reminds me of what Ruby does, which is try to make things look better
for you.

The only complaint I've heard about it was from Tony A.'s post
wondering "how do you return anything from blocks?"

i.e. in Ruby "array.collect{|a|}.reject{|b| true}"

how to do that with indented blocks.

That being said, splitting it up into 3 neat python blocks doesn't look
bad at all, so it's not a big loss there.  I'm not too familiar with
Python syntax so I'm not exactly sure what's possible, either.  What
would a good syntax be to return values from indented blocks?

> My proposal is to, first, not change a thing with respect to existing
> syntax. Second, steal the : from Python and use it to signify a scope
> that's marked by indentation:

I did note Matz recent comment on using the ":" as a separator:
http://redmine.ruby-lang.org/issues/show/1389

Perhaps you could take your pitch to him :)

>   while some_condition:
>     # this scope will terminate when the indentation level decreases
> to the
>     # level before it was entered
>     do_something

Interesting--so you propose to use : when you want a block but *dont*
care about using its return value, is that right?


> We can get around this by saying that braces, wherever they may appear,
> always define a new scope nested within the current scope, regardless
> of indentation.
>
>   def do_something(a, b, c):
> { print a, b, c }  # this works
>     a + b + c

and then afterward it picks up the previous indentation? I
suppose...that would work.  It's an odd use for {}'s though which are
already pretty heavily used.

Overall I like the idea--making "end's" optional would indeed be kind.
It is better than a similar idea I had recently, which was to use : for
single line blocks (only), i.e.

if a == b : do_something
instead of
if a == b; do_something; end

but your suggestion seems to include even more than that.

The other concern is that "the allure of magic indentation wears thin
for large docs" which fact "worked to ensure you kept your methods
short."[1]

Also could parsers handle it?
Thoughts?

=-r
[1] http://www.artima.com/forums/flat.jsp?forum=123&th...
Joel VanderWerf (Guest)
on 2009-05-20 21:37
(Received via mailing list)
Joshua B. wrote:
>> The closing "_ say" ends the block saved to "say" var.
Or maybe some variation on Lisp's superparenthesis?

http://www.gavilan.edu/csis/languages/parentheses.html
J Haas (Guest)
on 2009-05-20 22:35
(Received via mailing list)
On May 20, 8:51 am, Rick DeNatale <removed_email_address@domain.invalid> 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.

On May 20, 9:01 am, "Michael Bruschkewitz"
<removed_email_address@domain.invalid> wrote:
> I have some suspicion this was a joke thread.
> (Hint: Format of OP)

Nope, I'm sincere. As I said before, I'm new. The formatting was a
misguided attempt to make things look nice by manually wrapping them
at 80 columns. Oops.

> This sort of structuring pieces of code stopped me from trying Python
> seriously.

And I specifically addressed this in my OP. A lot of engineers who
haven't done work in Python think that the idea of giving syntactical
significance to whitespace is a ridiculous idea. I used to be one of
them. Now I know better. Don't knock it until you've tried it.

> Isn't there an Syntax-Highlighting Editor out there which allows assigning
> 1-Point size to End-Only-Lines?

Aside from the fact that this wouldn't solve the problem that I'd
still have to _write_ the damned things, this is possibly the
kludgiest solution imaginable.

> Wouldnt this be the easiest way to solve your problem?

The easiest way to solve _my_ problem would be for me to use one of
the preprocessing scripts that impose Python-like indentation syntax
on Ruby. But that wouldn't solve the larger problem, which is that
Ruby could be better than it is.

On May 20, 10:04 am, Joshua B. <removed_email_address@domain.invalid> wrote:
> It's at this point that I started to wonder if you've had a look-see
> at _why's new language, Potion?

Nope. but I'll check it out. Thanks.
Rick D. (Guest)
on 2009-05-20 22:51
(Received via mailing list)
On Wed, May 20, 2009 at 2:35 PM, J Haas <removed_email_address@domain.invalid> 
wrote:
> On May 20, 8:51 am, Rick DeNatale <removed_email_address@domain.invalid> 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.

In general I'm not a fan of languages whose syntax depends on the
number of rather than just the presence of whitespace characters.  I
find it hard to count blanks while reading.

I tried hard to like haml for instance. It has a lot of good points,
but the pythonic style of nesting just doesn't work for me.

In code, the real solution is not to nest so deeply that it becomes a
problem, learn to use the composed method pattern.



--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
J Haas (Guest)
on 2009-05-20 23:10
(Received via mailing list)
On May 20, 10:23 am, Roger P. <removed_email_address@domain.invalid> wrote:
>
> >> print 3
>
> 3 :-)

Nifty! Thanks.

> The only complaint I've heard about it was from Tony A.'s post
> wondering "how do you return anything from blocks?"
>
> i.e. in Ruby "array.collect{|a|}.reject{|b| true}"
>
> how to do that with indented blocks.

I still have a tough time understanding this objection. What I'm
essentially proposing is that at least in the case of code blocks that
start with a colon, a de-dent takes the place of an end. Given that, I
just don't see what it is that could be done without end that couldn't
be done without dedenting. In this example, the braces would continue
to work as expected (and there are no end statements), but for
something like this:

array.reject do |b|
  true
end

... it would just be:

array.reject do |b|:
  true

I guess with the collect thrown in, the current implementation with do-
end rather than braces would be

array.collect do |a|
end.reject do |b|
  true
end

..is that right? Using indentation to deliniate blocks does have the
problem that you can't have a null block like the one passed to
collect here. Python gets around it with the keyword "pass", as in:

for x in xrange(50):     # Python equivalent of (0...50).each do |x|
end
  pass

So this could be:
arra.collect do |a|:
  pass
.reject do |b|:
  true

> Interesting--so you propose to use : when you want a block but *dont*
> care about using its return value, is that right?

No, not exactly. The issue with return values is orthogonal to this.
My proposal is to use the : if you want dedent to substitute for end
to terminate the block. I still don't see why return values are
affected.

> >   def do_something(a, b, c):
> > { print a, b, c }  # this works
> >     a + b + c
>
> and then afterward it picks up the previous indentation? I
> suppose...that would work.  It's an odd use for {}'s though which are
> already pretty heavily used.

True, and I'm not too thrilled with the solution, but maybe there's
something better. {} is heavily used, but on the other hand one of its
common uses is to divide code into blocks, and that's what it's doing
here.

> Overall I like the idea--making "end's" optional would indeed be kind.
> It is better than a similar idea I had recently, which was to use : for
> single line blocks (only), i.e.
>
> if a == b : do_something
> instead of
> if a == b; do_something; end

This suggestion is not at all incompatible with mine, and in fact
that's the way Python does it too (except you'd have to put parens
after do_something :)...

if a==b:
  # Nothing follows the colon, so this starts a new scope indented
past the if statement
  do_something()
do_something_else()

if a==b: do_something()  # code follows the colon, so it constitutes
the entire block
do_something_else()

if a==b:
do_something_else()  # error, the parser expects a new level of
indentation

if a==b: do_something()
  do_something_else() # error, the parser does not expect a deeper
indent

> The other concern is that "the allure of magic indentation wears thin
> for large docs" which fact "worked to ensure you kept your methods
> short."[1]

Well, all I can say is, that's his opinion. Hasn't lost its allure for
me. And if it did lose its allure, I would think that it wouldn't be
for large docs, it would be for deeply _nested_ docs. I definitely
sympathize with his mockery of the notion that this limitation is a
blessing in disguise because it encourages you to keep your methods
short... it reminds me of how I felt when I first heard that Java's
lack of pointers meant you couldn't write any pointer bugs. But my
employer imposes a strict 80-column limit on source files including
Python, we have a lot of Python code, and it all works out.

> Also could parsers handle it?

I think so, especially since the preprocessor I've used (wish I could
remember its name... it's not Lazibi [1]) does it in a fairly clever
way in Ruby itself, so I don't see why the parser couldn't do what it
does.

Thanks for your comments, I appreciate the feedback.

[1] http://lazibi.rubyforge.org/
Tony A. (Guest)
on 2009-05-20 23:25
(Received via mailing list)
On Wed, May 20, 2009 at 1:10 PM, J Haas <removed_email_address@domain.invalid> 
wrote:

> I still have a tough time understanding this objection. What I'm
> essentially proposing is that at least in the case of code blocks that
> start with a colon, a de-dent takes the place of an end.  Given that, I
> just don't see what it is that could be done without end that couldn't
> be done without dedenting.


I already responded to this.  I guess you didn't see it.  There are
several
types of statements which contain multiple indent blocks (and thus
multiple
dedent tokens).  These would include if statements:

if foo
  blah
elsif bar
  blah2
else
  baz

Begin statements (ala try/catch in Python)

begin
  somecode
  morecode
rescue FooError
  some_rescue_action
rescue BarError
  another_rescue_action
ensure
  something_gets_done

Case statements:

case foo
when bar
  do_something
when baz
  do_something_else

Each of these statements is an expression with multiple clauses.  How do
you
tell when these expressions are complete?  Obviously a naive "dedent =
end
of expression" approach doesn't work in these cases.

These work in Python because Python has a special grammar for statements
which doesn't require a statement separator for any statements which
have
indent blocks.  This doesn't work in a language where everything is an
expression, because all expressions must be treated the same and all
expressions must have an expression terminator (newline or semicolon)
Tony A. (Guest)
on 2009-05-20 23:40
(Received via mailing list)
On Wed, May 20, 2009 at 1:25 PM, Tony A. <removed_email_address@domain.invalid> 
wrote:

>  do_something
> when baz
>  do_something_else
>

And yet another consideration with this in Ruby vs. Python: in Ruby
these
are all expressions (as has been stated repeatedly) and therefore you
can do
this sort of thing:

x = case foo
when bar
  do_something
when baz
  do_something_else
else
  whatever
end

i.e. the case statement returns the value of the last expression
evaluated
in the taken branch.

This is not the case in Python (well first because Python doesn't have
case
statements) where no expressions can contain indent blocks.
Juan Z. (Guest)
on 2009-05-20 23:45
(Received via mailing list)
On May 20, 2009, at 2:51 PM, Rick DeNatale wrote:

> On Wed, May 20, 2009 at 2:35 PM, J Haas <removed_email_address@domain.invalid> wrote:
>> On May 20, 8:51 am, Rick DeNatale <removed_email_address@domain.invalid> 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.
Joshua B. (Guest)
on 2009-05-20 23:48
(Received via mailing list)
On May 20, 2009, at 3:10 PM, J Haas wrote:

>> Also could parsers handle it?
>
> I think so, especially since the preprocessor I've used (wish I could
> remember its name... it's not Lazibi [1]) does it in a fairly clever
> way in Ruby itself, so I don't see why the parser couldn't do what it
> does.

A friendly suggestion: One of Ruby's strengths (one that it shares
with Perl) is its power to manipulate and parse strings. If you're new
to Ruby, a script which takes your colon/de-indent syntax and turns it
into the proper do/end syntax sounds like a great project to get
started. Since you desire to write Ruby code in this way, it would
also give you a great excuse to approach this problem using TDD. That
is, write the code in the way you would like it to appear as a test,
then write the parser/de-re-mangler to have the test pass. I honestly
think you could have done this with the same amount of effort as it
has taken to reply to each of the e-mails in this thread.

Let me be frank: Your suggestion is not new. Code speaks louder than
words. When you _do_ implement this alternative Ruby syntax, I think
you may be surprised at the number of corner and edge cases. Ruby is
currently in the process of being standardized. I would imagine the
last thing that Ruby needs while undergoing the standardization
process is a new, optional syntax with a multitude of corner and edge
cases.

Cheers,

Josh
Gregory B. (Guest)
on 2009-05-20 23:51
(Received via mailing list)
On Wed, May 20, 2009 at 3:44 PM, Juan Z. <removed_email_address@domain.invalid>
wrote:
>>> 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
Robert K. (Guest)
on 2009-05-21 00:05
(Received via mailing list)
On 19.05.2009 23:35, J Haas wrote:

> I am not a zealot and have little tolerance for zealotry, and I have
> no
> desire to get involved in holy wars.

The length of your statement and the wording seem to indicate
differently:

> hate that
> Ruby doesn't have it.

> My friends, when ONE OUT OF EVERY SIX of your code lines consists of
> just the
> word "end", you have a problem with conciseness.

(So far I can only see that you are having a problem.)

> But let me say that again: ONE OUT OF EVERY SIX LINES, for
> crying out
> loud! This should be intolerable to engineers who value elegance.

> Well, tough. Programmers shouldn't be using freakin' tabs anyway, and

> I don't think
> it's worthwhile to inflate the code base by a staggering 20% to
> accommodate
> people who want to write ugly code,

Kind regards

  robert
Martin DeMello (Guest)
on 2009-05-21 00:11
(Received via mailing list)
On Thu, May 21, 2009 at 12:21 AM, Rick DeNatale
<removed_email_address@domain.invalid> wrote:
>
> Honestly, that's subjective. Some people prefer delimiters some don't.

Scheme strikes a beautiful balance, I think

(class Object
   (def initialize foo bar
      (whatever
        whatever)))

no strings of ends, but no significant whitespace, and vim users can
bounce on the % key and be happy.

martin
Shot (Piotr S.) (Guest)
on 2009-05-21 00:26
(Received via mailing list)
J Haas:

> A lot of engineers who haven't done work in Python think that the idea
> of giving syntactical significance to whitespace is a ridiculous idea.
> I used to be one of them. Now I know better. Don't knock it until
> you've tried it.

I’m one of the idealists who actually loved Python’s idea of
indentation, meaningful whitespace and the least possible clutter
(to the point that I actually preferred tabs to spaces – that’s the
whole point of a tab, to *indent*), and I did write quite a few lines
of Python in my life – and after all that, I’m now strongly in the
‘no significant whitespace’ camp.

I might miss my idealism, but the practical advantages of
non-significant whitespace win for me on all fronts: I can
actually use code snippets without reindenting them, badly-indented
code tells me outright that I shoudn’t even bother reading it, and
I can do all kinds of commenting-out/debug print calls really fast.

> Aside from the fact that this wouldn't solve the problem
> that I'd still have to _write_ the damned things

If you have to write the ‘end’ statements yourself (and it bothers you),
then you either don’t use a sane editor or didn’t configure it properly.

— Shot
J Haas (Guest)
on 2009-05-21 00:30
(Received via mailing list)
On May 20, 12:25 pm, Tony A. <removed_email_address@domain.invalid> wrote:
> I already responded to this.  I guess you didn't see it.

I responded to your response, I guess you didn't see _that_. Tell me
what's wrong with the following alternatives to your examples:

> if foo
>   blah
> elsif bar
>   blah2
> else
>   baz

Just like with your case example before, whoops! You're missing an
end, and the parser will complain when it sees the end-of-file without
a missing end. And just as I said with your case example before, I
sure hope this missing end isn't in the middle of a long file or you
get to spend a lot of time scrolling through your code looking for the
place where it's missing.

But if we amend your example to

if foo
  blah
elsif bar
  blah2
else
  bar
end

...I really don't see what's wrong with this as an alternative:

if foo:
  blah
elsif bar:
  blah
else:
  bar

No end necessary.

>   something_gets_done
Again, you're missing an end. Applying the same pattern I applied in
the if and case examples, I do not see what the problem is. How is it
any less functional than the current Ruby?

> Each of these statements is an expression with multiple clauses.  How do you
> tell when these expressions are complete?  Obviously a naive "dedent = end
> of expression" approach doesn't work in these cases.

Okay, I think I see what you're saying now. But each of those also, in
the clauses after the first one, begins with a keyword that is not
valid except as part of the previous expression. Does it solve the
problem if dedenting ends an expression unless it's immediately
followed by a keyword that makes no sense except as a continuation of
the expression?

> This doesn't work in a language where everything is an
> expression, because all expressions must be treated the same and all
> expressions must have an expression terminator (newline or semicolon)

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. I agree that "put an end wherever you see a
dedent" is naive and wouldn't work... but "put an end wherever you see
a dedent which isn't followed by a keyword which extends the current
expression, such as elsif or rescue or ensure" might.
pat eyler (Guest)
on 2009-05-21 00:31
(Received via mailing list)
On Wed, May 20, 2009 at 12:35 PM, J Haas <removed_email_address@domain.invalid> 
wrote:
> On May 20, 8:51 am, Rick DeNatale <removed_email_address@domain.invalid> wrote:
>> This sort of structuring pieces of code stopped me from trying Python
>> seriously.
>
> And I specifically addressed this in my OP. A lot of engineers who
> haven't done work in Python think that the idea of giving syntactical
> significance to whitespace is a ridiculous idea. I used to be one of
> them. Now I know better. Don't knock it until you've tried it.


And you're on a mailing list full of people who find that the Ruby-way
makes sense to them.  Don't knock it until you've tried it.

>> Wouldnt this be the easiest way to solve your problem?
>
> The easiest way to solve _my_ problem would be for me to use one of
> the preprocessing scripts that impose Python-like indentation syntax
> on Ruby. But that wouldn't solve the larger problem, which is that
> Ruby could be better than it is.
>

Or not.  Beauty is in the eye of the beholder.  Thinking that the new
(to you) language that you're working with today would be better if
it were more like your old language is a big reason that so many
people write [perl|C|fortran] code in so many different languages.


--
thanks,
-pate
-------------------------
 Don't judge those who choose to sin differently than you do

http://on-ruby.blogspot.com
http://eldersjournal.blogspot.com
Juan Z. (Guest)
on 2009-05-21 00:33
(Received via mailing list)
On May 20, 2009, at 3:50 PM, Gregory B. wrote:

>>>>> get a
>> Is it subjective?   Neither method is ambiguous.  So no problem
> -greg
>


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.
Roger P. (Guest)
on 2009-05-21 00:41
>> print 3
>>
>> 3 :-)
>
> Nifty! Thanks.

Appears I went too far--this is enough:

class Object
 def print *args
      super *(args + [" :-)"])
 end
end
>> print 3
3 :-)=> nil

This works because

>> class A; end
>> A.ancestors
=> [A, Object, Kernel]

when it searches for the print it first looks in the current class, then
in Object, then in Kernel.  Object now defines it, then "supers" to
Kernel.

> Aside from the fact that this wouldn't solve the problem that I'd
> still have to _write_ the damned things, this is possibly the
> kludgiest solution imaginable.

Whoa turbo we're all trying to be respectful.


> So this could be:
> arra.collect do |a|:
>   pass
> .reject do |b|:
>   true


gotcha.  That looks nice in terms of return values.  I guess the actual
problem was better described by Tony in his other post, I misled you.

>> The other concern is that "the allure of magic indentation wears thin
>> for large docs" which fact "worked to ensure you kept your methods
>> short."[1]
>
> Well, all I can say is, that's his opinion. Hasn't lost its allure for
> me. And if it did lose its allure, I would think that it wouldn't be
> for large docs, it would be for deeply _nested_ docs. I definitely
> sympathize with his mockery of the notion that this limitation is a
> blessing in disguise because it encourages you to keep your methods
> short... it reminds me of how I felt when I first heard that Java's
> lack of pointers meant you couldn't write any pointer bugs. But my
> employer imposes a strict 80-column limit on source files including
> Python, we have a lot of Python code, and it all works out.

How well does it work out?  Any drawbacks?

>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. I agree that "put an end wherever you see a
>dedent" is naive and wouldn't work... but "put an end wherever you see
>a dedent which isn't followed by a keyword which extends the current
>expression, such as elsif or rescue or ensure" might.

Sounds good--code it up and I'll give it a try (as Joshua said).
Persuade via code! :)

Make sure you write it in Ruby though no cross contamination! <said
tongue in cheek>

It will be interesting to code some ruby that looks like Python.
Anybody else know of projects that allow for this? (pre processors)

Thanks.
-=r
Joel VanderWerf (Guest)
on 2009-05-21 00:44
(Received via mailing list)
Juan Z. wrote:
> I'm willing to admit that Python programs are generally shorter

Are you sure of that? Care for a round of golf?
Gregory B. (Guest)
on 2009-05-21 00:46
(Received via mailing list)
On Wed, May 20, 2009 at 4:32 PM, Juan Z. <removed_email_address@domain.invalid>
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 didn't accidentally illustrate anything.   And everything has a
cost.  Why don't you list for yourself the cost of editing code with
significant white space?
Maybe for you, those costs are irrelevant.   For me, the costs of ends
in Ruby code are irrelevant.

But your point was about *readability* not maintainability.   I don't
think that good project organization is a 'cost' to readability.
Ryo F. (Guest)
on 2009-05-21 00:46
(Received via mailing list)
On May 20, 9:50 am, Gregory B. <removed_email_address@domain.invalid> wrote:
>
> non-issue.
>
> Rick's point remains.  If this is an issue you're facing, get a better editor.

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
Tony A. (Guest)
on 2009-05-21 00:51
(Received via mailing list)
On Wed, May 20, 2009 at 2:30 PM, J Haas <removed_email_address@domain.invalid> 
wrote:

> 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. I agree that "put an end wherever you see a
> dedent" is naive and wouldn't work... but "put an end wherever you see
> a dedent which isn't followed by a keyword which extends the current
> expression, such as elsif or rescue or ensure" might.
>

Okay, you just want an example I guess.  Code speaks louder than words!

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.:

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

I'd be particularly interested in solutions which can be parsed with a
LALR,
LL*, or PEG parser.  The approach you're describing does not sound like
it
could be expressed as a CFG, not that there isn't a CFG solution for
this,
just that the one you're proposing is not.
Gregory B. (Guest)
on 2009-05-21 00:56
(Received via mailing list)
On Wed, May 20, 2009 at 4:40 PM, Ryo F. <removed_email_address@domain.invalid> 
wrote:
> On May 20, 9:50 am, Gregory B. <removed_email_address@domain.invalid> wrote:

>> Rick's point remains.  If this is an issue you're facing, get a better editor.
>
> 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).

I still think this is a straw man.   I'm rarely concerned with the
'readability' of a whole page of code.
I feel like there is something wrong with my design when I have to
think at that level.

For what it's worth, I actually can care less whether whitespace is
significant or not.  Significant whitespace doesn't bother me in Haml.
The lack of significant whitespace doesn't bother me in Ruby.

What does bother me is that people somehow think this issue is so
important and dire, yet they think it's someone else's job to fix it.
If you want Ruby with significant whitespace, build it.   Don't try to
convince folks who don't care about the issue.

-greg
Juan Z. (Guest)
on 2009-05-21 01:24
(Received via mailing list)
On May 20, 2009, at 4:39 PM, Gregory B. wrote:

>> cost.
>
> I didn't accidentally illustrate anything.   And everything has a
> cost.  Why don't you list for yourself the cost of editing code with
> significant white space?
> Maybe for you, those costs are irrelevant.   For me, the costs of ends
> in Ruby code are irrelevant.
>
> But your point was about *readability* not maintainability.   I don't
> think that good project organization is a 'cost' to readability.
>


I'm saying that when all other factors are held  constant more lines is
less readable.  Your arguments ignore that and only place value on
editors and project management when the extra lines exist and
not when they don't.   That's not a level playing field.

Thinking about ways to reduce this overhead in the language is good.
Gregory B. (Guest)
on 2009-05-21 01:42
(Received via mailing list)
On Wed, May 20, 2009 at 5:23 PM, Juan Z. <removed_email_address@domain.invalid>
wrote:


> I'm saying that when all other factors are held  constant more lines is
> less readable.  Your arguments ignore that and only place value on
> editors and project management when the extra lines exist and
> not when they don't.   That's not a level playing field.

You're right.   I should note that better design also mitigates most
of the concerns about the problems of whitespace significance (for
me).
But that doesn't invalidate my feeling that this whole stirrup about
'readability' is a straw man at best, and an indication of a poor
ability to write clean code without extra help at worst.

> Thinking about ways to reduce this overhead in the language is good.

And implementing them is great.  Because it solves your problem for
you, and does not require convincing others that it is a problem.
Those who do find this desirable will use it.  So what's stopping you?

-greg
Gary W. (Guest)
on 2009-05-21 02:07
(Received via mailing list)
The obvious solution is for us to find some red matter, form a black
hole, toss in Matz and Guido, have them confront their younger selves,
and see who wins in the Language Wars 2.0 timeline.

Gary W.
Tony A. (Guest)
on 2009-05-21 02:19
(Received via mailing list)
On Wed, May 20, 2009 at 2:45 PM, Tony A. <removed_email_address@domain.invalid> 
wrote:

> I'd be particularly interested in solutions which can be parsed with a
> LALR,
> LL*, or PEG parser.  The approach you're describing does not sound like it
> could be expressed as a CFG, not that there isn't a CFG solution for this,
> just that the one you're proposing is not.
>

And here's what exacerbates the problem in a CFG: in a grammar like
Ruby,
things like case statements, if statements, and method calls with blocks
are
among what I believe is the lowest precedence set of operations.  In
Python,
statements with indent blocks are among the highest precedence
operations.

So we can do things where expressions with indent blocks need to be
lower
precedence, and that's where the proverbial shit really starts to hit
the
fan.  How would you parse this, for example?

n = 2 * -[1,2,3,4,5].inject(0) do |a, b|
  c = a * 2
  a * c + b
result = 8 * -if n > 0
  -n += 10000
else
  n + 500000
puts result

And just as a matter of personal preference, I find the above with end
statements more readable:

n = 2 * -[1,2,3,4,5].inject(0) do |a, b|
  c = a * 2
  a * c + b
end
result = 8 * -if n > 0
  -n += 10000
else
  n + 500000
end
puts result
Tony A. (Guest)
on 2009-05-21 02:29
(Received via mailing list)
On Wed, May 20, 2009 at 4:18 PM, Tony A. <removed_email_address@domain.invalid> 
wrote:

>  I'd be particularly interested in solutions which can be parsed with a
> LALR,
> LL*, or PEG parser.  The approach you're describing does not sound like it
> could be expressed as a CFG, not that there isn't a CFG solution for this,
> just that the one you're proposing is not.
>

And I guess I just can't shut up about this: your solution would require
a
scanner with some degree of grammatical awareness for every expression
which
contains an indent block.  When you start talking about a solution like
that, I really think you're going down a rabbit hole.

I'll refer to Guido van Rossum on this one:

> can all be solved (there's already a stack of indentation levels that could
> be generalized). But none of that takes away my gut feeling that it is all
> an elaborate Rube G. contraption<http://www.rube-goldberg.com/html/gallery.htm>
> .
>
You are proposing a Rube G. 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?
Juan Z. (Guest)
on 2009-05-21 05:42
(Received via mailing list)
On May 20, 2009, at 5:41 PM, Gregory B. wrote:

> You're right.   I should note that better design also mitigates most
> of the concerns about the problems of whitespace significance (for
> me).
> But that doesn't invalidate my feeling that this whole stirrup about
> 'readability' is a straw man at best, and an indication of a poor
> ability to write clean code without extra help at worst.

So you have better designs compared to those who seek further
conciseness in a language.  If only those folks of poor ability could
design so well as you.
Gregory B. (Guest)
on 2009-05-21 05:53
(Received via mailing list)
On Wed, May 20, 2009 at 9:38 PM, Juan Z. <removed_email_address@domain.invalid>
wrote:
>
> On May 20, 2009, at 5:41 PM, Gregory B. wrote:

>> But that doesn't invalidate my feeling that this whole stirrup about
>> 'readability' is a straw man at best, and an indication of a poor
>> ability to write clean code without extra help at worst.
>
> So you have better designs compared to those who seek further conciseness in
> a language.  If only those folks of poor ability could design so well as
> you.

That's right.   I'm pretty awesome.   Maybe RubyTalk can throw a party
in honor of me!

(But seriously, I'm just saying that design is multi-faceted, and
conciseness isn't a single pointed goal one can optimize for to any
great effect)

-greg
Steven A. (Guest)
on 2009-05-21 08:30
(Received via mailing list)
On May 20, 2009, at 4:31 PM, pat eyler wrote:

> And you're on a mailing list full of people who find that the Ruby-way
> makes sense to them.  Don't knock it until you've tried it.

Just to kick in on this, I am a long-time Ruby programmer and Ruby is
my favorite language.  I'd rather see full-strength macros than
optional removal of 'end' keywords.  Having said that, let me admit I
do not know how complex it would be to implement a solution in Ruby
that optionally omits ends.  Some have argued, with what seem like
plausible reasons, that it might be hard.  Others have attempted to
rebut those reasons.  I agree with the calculus that if it is very
difficult, it is not worth the benefit.  If it is easy, I'd like to be
able to omit the 'end' statements.  They are line noise to me
visually.  They just get in the way.

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.

I guess, however, this is no more serious than the positioning-of-
brackets debate in C or even whether bracketless 'if' statements
should ever be used, e.g.:

     if (foo)
         bar();
         baz();

The 'baz' function will execute regardless of the value of foo; this
code is therefore visually confusing.

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.

steven
Bill K. (Guest)
on 2009-05-21 09:30
(Received via mailing list)
From: "Tony A." <removed_email_address@domain.invalid>
>
> I'll refer to Guido van Rossum on this one:
>
>> The unspoken, right brain http://en.wikipedia.org/wiki/Right_brain
>> constraint here is that the complexity introduced by a solution to a design
>> problem must be somehow proportional to the problem's importance. In my
>> mind, the inability of lambda to contain a print statement or a while-loop
>> etc. is only a minor flaw; after all instead of a lambda you can just use a
>> named function nested in the current scope.

I think this helps illustrate the degree of subjectivity
involved in how varying people regard this issue.

For me, I've written sufficient Python code in years past
to have concluded that significant indentation adds too
much rigidity to the language for it to feel like an
acceptable trade-off for what it accomplishes.
(The mere existence of the 'pass' keyword is slightly
eye-rolling to me.... presumably similar to how others
may feel about a raft of closing 'end' statments.)

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.)

As far as nested 'end' statements, one thing I've been
trying lately is to define the module hierarchy at the top
of the file, then qualify the class name so that nesting
is avoided.  Like,

module CILA end
module CILA::SVC end

class CILA::SVC::Hub

  # ........ methods here as usual ........

end

class CILA::SVC::HubClientConn

  # ........ methods here as usual ........

end

So far I'm pretty happy with this approach.


Regards,

Bill
Tony A. (Guest)
on 2009-05-21 11:03
(Received via mailing list)
On Wed, May 20, 2009 at 11:29 PM, Bill K. <removed_email_address@domain.invalid> 
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.)


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...
Roger P. (Guest)
on 2009-05-21 16:06
> 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
Steven A. (Guest)
on 2009-05-21 21:27
(Received via mailing list)
On May 21, 2009, at 8:06 AM, Roger P. wrote:

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

I was thinking more like Lisp macros.  Check out:

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

steven
Juan Z. (Guest)
on 2009-05-21 21:42
(Received via mailing list)
On May 21, 2009, at 1:26 PM, Steven Arnold wrote:

> steven
>
>

The Ant XML example is a bit ironic.    Ant's creator regrets using
XML.   He believes that he should have used a scripting language
instead.   Take a look at Rake and you'll see a DSL that does what Ant
does and more.
James B. (Guest)
on 2009-05-21 22:13
(Received via mailing list)
Joshua B. wrote:

>
> It's at this point that I started to wonder if you've had a look-see at
> _why's new language, Potion? Specifically:
>
>> * Deeply nested blocks can be closed quickly. I don't like significant
>> whitespace, personally.

This from the guy who championed YAML?

(Side rant: interesting that so many Rubyists go ga-ga over magic
indentation in Yaml and Haml, but find the idea repulsive in Ruby.)

--
James B.

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
James B. (Guest)
on 2009-05-21 22:53
(Received via mailing list)
Tony A. wrote:

>>
> You are proposing a Rube G. 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?


Complexity never goes away (I imagine there is some Conservation of
Complexity defined someplace), so you have to decide where you want it.

If you push it down into the parser, you may gain something at the
code-writing level, but odds are that when a new feature is proposed, or
a bug discovered, adding or fixing things will be much, much harder.

A magic whitespace addition could be a Pyrrhic victory.


--
James B.

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
Ryan D. (Guest)
on 2009-05-22 02:30
(Received via mailing list)
On May 20, 2009, at 15:28 , Tony A. wrote:

> And I guess I just can't shut up about this: your solution would
> require a
> scanner with some degree of grammatical awareness for every
> expression which
> contains an indent block.  When you start talking about a solution
> like
> that, I really think you're going down a rabbit hole.

To be fair, if you looked at ruby's lexer and parser you'd know that
we're already down a rabbit hole. Your statement completely ignores
the complexity already inherent in the language.

Don't chalk me up as a proponent of this idea as I've written more
than my fair share of python and hate the language (and especially the
libraries).
Tony A. (Guest)
on 2009-05-22 03:21
(Received via mailing list)
On Thu, May 21, 2009 at 4:29 PM, Ryan D.
<removed_email_address@domain.invalid>wrote:

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


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!
Yossef M. (Guest)
on 2009-05-22 03:25
(Received via mailing list)
On May 21, 1:12 pm, James B. <removed_email_address@domain.invalid> wrote:
> (Side rant: interesting that so many Rubyists go ga-ga over magic
> indentation in Yaml and Haml, but find the idea repulsive in Ruby.)

YAML and Haml are fundamentally different from Ruby, or do you
consider markup to be programming?
It's true that Haml has the same any-Ruby-is-allowed rules as ERB, but
you naturally restrict yourself because you're working with a template
as opposed to an actual program. (Or at least you should.)

And for the record, I get kind of annoyed with the significant
whitespace in Haml when it comes to Ruby code, but I love how easy and
clean HTML becomes.
Tony A. (Guest)
on 2009-05-22 06:24
(Received via mailing list)
On Thu, May 21, 2009 at 5:20 PM, Tony A. <removed_email_address@domain.invalid> 
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!
>

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.
Steven A. (Guest)
on 2009-05-22 07:57
(Received via mailing list)
On May 21, 2009, at 10:24 PM, Tony A. wrote:

> 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(",")

Me too.  It's interesting how seemingly small changes can generate a
lot of unexpected corner cases and unforeseen consequences.  Of
course, one could argue that using indentation does not preclude using
explicit blocks in the same file.  I doubt, for example, that anyone
wishing to remove the 'end' keyword would wish to disallow something
like:

     array_of_strings_that_are_numbers.sort! {|a,b| a.to_i <=> b.to_i}

...even though the {} brackets are the same as do..end.

If explicit blocks were allowed in the same file where blocks were, by
default, determined by indentation, then you could have your cake and
eat it too in the example above.

Nevertheless, I think your gut feel is correct......this would be a
tricky thing to do right.

steven
J Haas (Guest)
on 2009-05-22 08:35
(Received via mailing list)
On May 20, 1:45 pm, Tony A. <removed_email_address@domain.invalid> wrote:
> when Array
>   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.:

Okay. But just to recap what's gone before: you've said all along that
Pythonic indentation in Ruby was impossible. It's impossible, because
it's incompatible with blocks. It's impossible, because everything's
an expression. It's impossible, because Guido said so. And I've asked
you over and over for an example demonstrating its impossibility.
You've had time to think it over, you were under no constraints, and
this is what you've come up with.

I found the old preprocessor script from awhile ago that I mentioned
earlier in this thread. I've pastebinned it at
http://pastebin.com/m5fee1e92.
It's very short, and pretty simple. I have no doubt that it would need
a lot of work to be robust. (In particular, I think things need to be
added to the enumeration at line 68.)

But Tony, it blasted through your "impossible" example without
skipping a beat, working perfectly on the first try.

jhaas@littlefinger:~/pyruby$ cat pyrbtest.rb
__BEGIN__

# Look, ma! No ends!

foo = [1,2,3]
x = foo.map do |n|:
  n += 1
  n *= 2

result = case x:
  when Array
    x.map! do |n|:
      n *= 3
      n += 4
  when NilClass
    x

result = if result.size > 10:
  result[0..2]
else:
  result

p result
jhaas@littlefinger:~/pyruby$ irb
irb(main):001:0> require 'pyruby'
=> true
irb(main):002:0> require 'pyrbtest'
[16, 22, 28]
=> true

As I've said repeatedly, I don't follow your reasons for claiming that
this is impossible. Can you come up with a better demonstration?
J Haas (Guest)
on 2009-05-22 08:38
(Received via mailing list)
On May 20, 3:18 pm, Tony A. <removed_email_address@domain.invalid> wrote:
> n = 2 * -[1,2,3,4,5].inject(0) do |a, b|
>   c = a * 2
>   a * c + b
> end
> result = 8 * -if n > 0
>   -n += 10000
> else
>   n + 500000
> end
> puts result

__BEGIN__

n = 2 * -[1,2,3,4,5].inject(0) do |a, b|:
  c = a * 2
  a * c + b
result = 8 * -if n > 0:
  -n += 10000
else:
  n + 500000
puts result

Once again, worked perfectly on its first time through the
preprocessor.
J Haas (Guest)
on 2009-05-22 08:45
(Received via mailing list)
On May 21, 9:16 am, J Haas <removed_email_address@domain.invalid> wrote:
> I found the old preprocessor script from awhile ago that I mentioned
> earlier in this thread. I've pastebinned it athttp://pastebin.com/m5fee1e92.

Sorry for the repeated posts, but I forgot to mention: I did not write
this, although I did make minor modifications. I don't recall where I
found it, and Google was no help. I regret that I cannot credit the
author; should he happen to be reading this, speak up!
Tony A. (Guest)
on 2009-05-22 09:34
(Received via mailing list)
On Thu, May 21, 2009 at 10:27 PM, J Haas <removed_email_address@domain.invalid> 
wrote:

> Okay. But just to recap what's gone before: you've said all along that
> Pythonic indentation in Ruby was impossible. It's impossible, because
> it's incompatible with blocks. It's impossible, because everything's
> an expression. It's impossible, because Guido said so. And I've asked
> you over and over for an example demonstrating its impossibility.
> You've had time to think it over, you were under no constraints, and
> this is what you've come up with.
>

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.


> I found the old preprocessor script from awhile ago that I mentioned
> earlier in this thread. I've pastebinned it at
> http://pastebin.com/m5fee1e92.
> It's very short, and pretty simple. I have no doubt that it would need
> a lot of work to be robust. (In particular, I think things need to be
> added to the enumeration at line 68.)
>
> But Tony, it blasted through your "impossible" example without
> skipping a beat, working perfectly on the first try.
>

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.
Tony A. (Guest)
on 2009-05-22 09:43
(Received via mailing list)
On Thu, May 21, 2009 at 10:27 PM, J Haas <removed_email_address@domain.invalid> 
wrote:

> Okay. But just to recap what's gone before: you've said all along that
> Pythonic indentation in Ruby was impossible. It's impossible, because
> it's incompatible with blocks. It's impossible, because everything's
> an expression. It's impossible, because Guido said so. And I've asked
> you over and over for an example demonstrating its impossibility.
> You've had time to think it over, you were under no constraints, and
> this is what you've come up with.


And sorry to be frank about this: I've been cordial and fact oriented in
this discussion, trying to explain my opinion as best as possible.  Not
only
are you strawmanning me here, you're being a right cunt.  Perhaps you
could
try to express your ideas without making it personal?
Joshua B. (Guest)
on 2009-05-22 10:12
(Received via mailing list)
On May 22, 2009, at 12:27 AM, J Haas wrote:

>
> As I've said repeatedly, I don't follow your reasons for claiming that
> this is impossible. Can you come up with a better demonstration?
>

First, let me say thank you for the code. This community thrives on
code, not on bickering. More code is always a good thing. That said...

 > cat tough.rb
# "end" can make things clearer, sometimes...

result = case ARGV[0]
          when /^\d*$/
            "That's an integer!"
          when /^[A-Za-z]*$/
            "That's a word!"
          else
            "That's something that's not an integer or a word..."
          end if ARGV[0]

puts result
Jörg W Mittag (Guest)
on 2009-05-22 17:10
(Received via mailing list)
Juan Z. wrote:
> does and more.
JDD actually not only regrets using XML for Ant, he eclusively uses
Rake now to build his Java projects. At least that's what I read,
anyway.

jwm
Reid T. (Guest)
on 2009-05-22 17:34
(Received via mailing list)
On Fri, 2009-05-22 at 14:33 +0900, Tony A. 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.
Roger P. (Guest)
on 2009-05-22 17:53
> n = 2 * -[1,2,3,4,5].inject(0) do |a, b|:
>   c = a * 2
>   a * c + b
> result = 8 * -if n > 0:
>   -n += 10000
> else:
>   n + 500000
> puts result
>
> Once again, worked perfectly on its first time through the
> preprocessor.

It would appear that "end's" actually help with readability in a few
cases :)

I'm glad to see you have some code.  Now put it on github, make a gem of
it, and advocate it :)

Here are a few other thoughts on it.  (Keeping things friendly and
civil...)

1) maybe it could become more of a generic preprocessor? (i.e. you give
it arbitrary rules, like "see this, change it to this")?

2) maybe it could be even smarter about its extrapolation, i.e. allow

4.times {|n|:
 puts n

[accomodate for braces--one fewer keystroke!]

or even

4.times |n|:
 puts n

[put in its own do's and end's if not there]

or who even needs :'s?

4.times |n|
 puts n

[whenever it sees an ending | without preceding do or {, count it as an
indent based block]

That would be interesting, and much more whitespacey, though slightly
less ruby-y .

To clarify Tony's point from above, you can't really do case statements
using only indentation and :'s.  Other constructs would work though
(except for the ambiguities mentioned earlier might prevent anythin but
a preprocessor being able to, for ruby's case).

-=r
J Haas (Guest)
on 2009-05-22 19:31
(Received via mailing list)
On May 21, 10:33 pm, Tony A. <removed_email_address@domain.invalid> 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:

On May 19, 3:23 pm, Tony A. <removed_email_address@domain.invalid> wrote:
> On Tue, May 19, 2009 at 3:40 PM, J Haas <removed_email_address@domain.invalid> wrote:
> > 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.
J Haas (Guest)
on 2009-05-22 19:36
(Received via mailing list)
On May 22, 6:32 am, Reid T. <removed_email_address@domain.invalid> wrote:
> 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.
Roger P. (Guest)
on 2009-05-22 20:01
> 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 :)
Take care.
-=r
Tony A. (Guest)
on 2009-05-23 00:03
(Received via mailing list)
On Fri, May 22, 2009 at 9:30 AM, J Haas <removed_email_address@domain.invalid> 
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.
>

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.
Michael Bruschkewitz (Guest)
on 2009-05-23 21:41
(Received via mailing list)
"J Haas" <removed_email_address@domain.invalid> schrieb im Newsbeitrag
news:removed_email_address@domain.invalid...
>> This sort of structuring pieces of code stopped me from trying Python
>> seriously.
>And I specifically addressed this in my OP. A lot of engineers who
>haven't done work in Python think that the idea of giving syntactical
>significance to whitespace is a ridiculous idea. I used to be one of
>them. Now I know better. Don't knock it until you've tried it.

I've used many languages in team projects, for example Assembler,
Fortran,
Modula, C, C++, Pascal, Ruby, Batch, bash, TCL.
The only thing common to these projects: Nobody seems to be able to use
formatting consistently on different platforms.

>> Isn't there an Syntax-Highlighting Editor out there which allows
>> assigning
>> 1-Point size to End-Only-Lines?
>Aside from the fact that this wouldn't solve the problem that I'd
>still have to _write_ the damned things, this is possibly the
>kludgiest solution imaginable.
So just use a macro which replaces CTRL-BS by end.

>> Wouldnt this be the easiest way to solve your problem?
>The easiest way to solve _my_ problem would be for me to use one of
>the preprocessing scripts that impose Python-like indentation syntax
>on Ruby.
You will additionally need preprocessing for importing code.

>But that wouldn't solve the larger problem, which is that
>Ruby could be better than it is.
Then it would not be your problem anymore, but the problems of tons of
other
Rubyists. Which, at current time, probably have absolutely no problem
using
end or "}".
(BTW: For at least 10 years, I've never read or heard about this
suggestion
for Ruby.)

Are you really sure you are no FUD-guy paid by MS which tries to
spoil other scripting languages in favor of F#?
James B. (Guest)
on 2009-05-24 02:10
(Received via mailing list)
Reid T. wrote:
> 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.



--
James B.

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
James B. (Guest)
on 2009-05-24 02:16
(Received via mailing list)
J Haas wrote:
> On May 21, 10:33 pm, Tony A. <removed_email_address@domain.invalid> 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.



--
James B.

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
Reid T. (Guest)
on 2009-05-24 23:34
(Received via mailing list)
James B. 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.
James B. (Guest)
on 2009-05-25 00:43
(Received via mailing list)
Reid T. wrote:
> James B. 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.

Sure, if in fact the indentation is fouled.

My concern is that you can mistakenly add 4 spaces instead of two, or
vice versa, and get valid code (i.e. the parser does not see anything
technically wrong) yet not have the code you really wanted.

James
Bill K. (Guest)
on 2009-05-25 02:10
(Received via mailing list)
From: "James B." <removed_email_address@domain.invalid>
>
> My concern is that you can mistakenly add 4 spaces instead of two, or
> vice versa, and get valid code (i.e. the parser does not see anything
> technically wrong) yet not have the code you really wanted.

That happened to us a couple times developing in
Python.  We were using spaces only (no tabs) ...
but somehow some tab characters did occasionally
sneak into a source file.  (Possibly by copy/paste
of code from a different editor--I was never sure
how it happened.)

So the indentation looked fine to us in the editor
(seeing two-column tabs), but was interpreted
differently by Python (eight-column tabs), resulting
in some baffling "it can't possibly be doing that!"
moments while debugging.

These days, I have my editor set to highlight tab
characters visually... :)


Regards,

Bill
Yukihiro M. (Guest)
on 2009-05-25 12:14
(Received via mailing list)
Hi,

|A valid objection that was raised in the earlier thread was regarding
|a quick and easy and common debugging technique: throwing in print
|statements
|
|  def do_something(a, b, c)
|print a, b, c  # for debugging purposes
|    a + b + c
|  end
|
|  def do_something(a, b, c):
|print a, b, c  # error! unexpected indentation level
|    a + b + c
|  end

Despite some might expect, I am not fully against block-by-indentation
a la Python, as long as

  * we keep end and brace blocks as well, of course.
  * prohibit mixing tabs and spaces in indentation mode
  * nice and compatible syntax. for compatibility and other reasons,
    colons do not work for block-by-indentation-marker.

I haven't found any good syntax so far.  Besides that 'end's and
braces often work nice for my eyes.

              matz.
J Haas (Guest)
on 2009-05-25 20:41
(Received via mailing list)
On May 22, 1:02 pm, Tony A. <removed_email_address@domain.invalid> wrote:
> 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?

>   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?)

>     n *= 3
> 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.
David M. (Guest)
on 2009-05-25 22:30
(Received via mailing list)
On Wednesday 20 May 2009 05:28:34 pm Tony A. wrote:

> You are proposing a Rube G. 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 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.
John W Higgins (Guest)
on 2009-05-25 23:02
(Received via mailing list)
On Mon, May 25, 2009 at 9:40 AM, J Haas <removed_email_address@domain.invalid> 
wrote:

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?
>

You accomplished ABSOLUTELY nothing with your magic trick here, and you
darn
well know it. You in no way shape or form made the indent context work
at
all. All you did was figure out that a regular expression could add the
word
"end" to a block of data when told to. No one ever said that wasn't
possible. That would be like saying that python can actually handle
multi
line lambdas if I took your same concept and pre-processed a file to
take
any multi line lambdas and convert them to a function which is called as
a
single line lambda. So are you now saying that anyone that claims the
python
engine doesn't handle multi-line lambdas is talking out of their ass?

If all you want is a preprocessor then it seems like you already have
what
you want and can be on your way to writing what you perceive as
beautiful
code immediately. Congrats and have at it, I'm not sure what more you
would
want at this point.

If you feel that you want to push this further into the core then again
-
have at it - many folks have suggested that forking and getting some
ACTUAL
working code in front of folks is the surest way to get things
accomplished!
I doubt that anyone would truly object if you implemented what you
suggest,
they simply are of the mindset that it won't work - prove them wrong,
and
not with a magic trick either.

Best of luck to you!

John W Higgins
Caleb C. (Guest)
on 2009-05-25 23:52
(Received via mailing list)
On 5/25/09, J Haas <removed_email_address@domain.invalid> wrote:
> 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.

It's certainly not impossible, as the script you posted shows. That
script is a hack, however, since it doesn't lex its input properly and
it will fail in obscure cases. I've written a proper implementation,
based on my RubyLexer library.

Basically, it makes the end keyword optional. If you leave off the
end, the preprocessor inserts an end for you at the next line indented
at or below the level of indentation of the line which started the
scope.

End is optional, so you can still write things like this:
  begin
    do_something
  end until done?
(However, you'd better make damn sure you get the end indented to the
right level!)

This script uses RubyLexer to extract a stream of tokens and modify
it, then turn those tokens back into ruby code. Since RubyLexer is a
complete stand-alone lexer, this should be a very thorough solution,
free of insoluable little problems due to the script's inability to
follow where comments and strings start and stop. (That said, I'm sure
there will be some problems with it, as it's pretty raw code.)

As different programs have a variety of interpretations as to the
width of a tab character, tabs for indentation are absolutely
forbidden by endless.rb.

If you're interested, please see:
http://gist.github.com/117694
David M. (Guest)
on 2009-05-26 01:19
(Received via mailing list)
On Sunday 24 May 2009 03:42:19 pm James B. wrote:
> My concern is that you can mistakenly add 4 spaces instead of two, or
> vice versa, and get valid code (i.e. the parser does not see anything
> technically wrong) yet not have the code you really wanted.

You can get the same problem by misplacing a bracket or a paren. The
only
difference I see is that the indentation is a lot more visibly obvious.
Joshua B. (Guest)
on 2009-05-26 02:44
(Received via mailing list)
On May 25, 2009, at 9:40 AM, J Haas wrote:

> 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.

I was on a questionable connection at the time, so my original message
may not have gotten to the mailing list:

 > cat impossible.rb

# This one can't be done in Pythonic style:

result = case ARGV[0]
   when /^\d*$/
     "That's an integer!"
   when /^[A-Za-z]*$/
     "That looks like a word..."
   else
     "That's not an integer or a word."
   end if ARGV[0]

puts result if result


Cheers,

Josh
James B. (Guest)
on 2009-05-26 03:13
(Received via mailing list)
David M. wrote:
> On Sunday 24 May 2009 03:42:19 pm James B. wrote:
>> My concern is that you can mistakenly add 4 spaces instead of two, or
>> vice versa, and get valid code (i.e. the parser does not see anything
>> technically wrong) yet not have the code you really wanted.
>
> You can get the same problem by misplacing a bracket or a paren. The only
> difference I see is that the indentation is a lot more visibly obvious.

Interesting.  I've had an incorrect number of braces and parens in the
past, and don't think it ever made for well-formed executable ruby.  I
always got a parsing error.

It seems like a much harder mistake to make then taping the space key or
back space key a few too more or less times. (That is, a mistake that
still leaves the code perfectly runnable by the interpreter, but with
different semantics than intended.)

Also, mismatched brackets or do/ends are very easy to spot; I tell vim
to auto-format, and the borked code alignment and incorrect syntax
coloring shows me right away where the error is.

I'm unclear as to whether you can have accurate auto-formatting with
significant indentation (e.g., ggVG=).

--
James B.

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
Caleb C. (Guest)
on 2009-05-26 06:09
(Received via mailing list)
On 5/25/09, Joshua B. <removed_email_address@domain.invalid> wrote:
>    when /^[A-Za-z]*$/
>      "That looks like a word..."
>    else
>      "That's not an integer or a word."
>    end if ARGV[0]
>
> puts result if result

Yes, and it's this very sort of case that led me to make end optional
rather than forbidden in endless.rb. Clearly, some things can't be
expressed just in pythonish syntax, so you have to be able to drop
back to ruby mode. The need for more tokens on the same line after the
end is sufficiently rare that I don't think it detracts from the
overall effect; almost all ends can still be eliminated.

Actually, I think pyrb.rb also will tolerate this example as well; you
just leave off the colon and it doesn't expect to create an end for
you for that statement. Looks like it's missing the 'when' special
case, but for this example, that doesn't matter, since you have the
whens more indented anyway.
Michael Bruschkewitz (Guest)
on 2009-05-27 12:25
(Received via mailing list)
"David M." <removed_email_address@domain.invalid> schrieb im Newsbeitrag
news:removed_email_address@domain.invalid...
> On Wednesday 20 May 2009 05:28:34 pm Tony A. wrote:
>
> 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.
Roger P. (Guest)
on 2009-05-27 15:37
> This script uses RubyLexer to extract a stream of tokens and modify
> it, then turn those tokens back into ruby code. Since RubyLexer is a
> complete stand-alone lexer, this should be a very thorough solution,
> free of insoluable little problems due to the script's inability to
> follow where comments and strings start and stop. (That said, I'm sure
> there will be some problems with it, as it's pretty raw code.)
>
> As different programs have a variety of interpretations as to the
> width of a tab character, tabs for indentation are absolutely
> forbidden by endless.rb.
>
> If you're interested, please see:
> http://gist.github.com/117694

Could you post us a few examples of what code formatted this way looks
like (or must look like)? I assume it handles here documents well?

The italics part of that gist is somewhat hard to read :)

@Michael:
I don't think having "either or" syntax would be such a terrible thing
in terms of team re-use or resources--you should be able to convert the
code back and forth at will (a la ruby2ruby, parsetree [rubylexer has a
parsetree compatibility mode] etc.)
Cheers!
-=r
J Haas (Guest)
on 2009-05-27 20:36
(Received via mailing list)
On May 22, 9:01 am, Roger P. <removed_email_address@domain.invalid> wrote:
> Tony's point was that certain constructs, like case statements, won't be
> transformable into indentation only blocks.  Does that make sense?

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):

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

# 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
Alex (Guest)
on 2009-05-27 20:46
(Received via mailing list)
I'm just going to stick my head out for a second and say that I think
the
first code was more readable, with the end blocks. I LIKE being able to
clearly see the end of a logical block. Yes, I can see the indentation
change, but having a keyword end sections of code does a few things:
1. It's easier for me to read, especially if I'm just skimming through
2. It's easier to parse, and makes for cleaner parser code (to me, at
least)


Come on guys, it's only 3 characters. Pythonic indentation is a big
debate
among programming languages, so can't we just accept it how it is and
move
on? Or, if someone really wants to change it, fork ruby and make the
change
yourself. Put up or shut up, is my (probably unwanted) opinion on the
subject.



Alex
Roger P. (Guest)
on 2009-05-28 02:42
> 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.)

True I suppose case statements could be done using blocks.
Note also that you don't "need" the ending : per line, either.

-=r
Caleb C. (Guest)
on 2009-05-28 03:32
(Received via mailing list)
On 5/27/09, Roger P. <removed_email_address@domain.invalid> wrote:
>> If you're interested, please see:
>> http://gist.github.com/117694
>
> Could you post us a few examples of what code formatted this way looks

Oops, I should have done that when I posted before. Thanks for the
reminder.

#so you can leave off the end of a method
def a
  c
  d

#or anything else that requires an end
for i in 1..10
  p i
  pp i

#else and other keywords which start a subclause
#of a statement don't cause an end if outdented at the same level
#as the if which controls them.
if a
  b
else
  c

#if you actually need an end, that's allowed too
#(if not further outdented than the line that started the statement)
result = case ARGV[0]
        when /^\d*$/
          p "That's an integer!"
        when /^[A-Za-z]*$/
          p "That's a word!"
        else
          p "That's something that's not an integer or a word..."
end if ARGV[0]

#you can explicitly end just the last scope of something deeply nested.
class A
  class B
    class C
      module D
        foo
end #actually 4 ends

> like (or must look like)? I assume it handles here documents well?

It _should_, since rubylexer does. I didn't test them explicitly. Here
documents
appear like one giant string; the indentation levels of all lines
inside strings are ignored. (There might be some very obscure
here-document related bugs left in rubylexer which would bite you in
endless.rb as well, tho I can't think of any right now. Most cases
should work. Here documents are weird.)

> The italics part of that gist is somewhat hard to read :)

I do apologize. It seems ok to me... What's hard about it? (You can
always just hit the link for the raw view.)
Roger P. (Guest)
on 2009-05-28 08:11
> #if you actually need an end, that's allowed too
> #(if not further outdented than the line that started the statement)
> result = case ARGV[0]
>         when /^\d*$/
>           p "That's an integer!"
>         when /^[A-Za-z]*$/
>           p "That's a word!"
>         else
>           p "That's something that's not an integer or a word..."
> end if ARGV[0]
>
> #you can explicitly end just the last scope of something deeply nested.
> class A
>   class B
>     class C
>       module D
>         foo
> end #actually 4 ends


I assume that that end is optional, too?
end also doubles as the equivalent for Python's "pass", as well?
So you can have ends if you want them but they're optional?  Does it
work with {}'s too?
So the basic rule it uses is that if something returns to the original
indentation level without being an end, it assumes it should have been
an end, is that right? (i.e. it *requires* blocks to be at a greater
indentation level).
Thanks just wondering.
-=r
J Haas (Guest)
on 2009-05-28 08:16
(Received via mailing list)
On May 27, 4:32 pm, Caleb C. <removed_email_address@domain.invalid> wrote:
> On 5/27/09, Roger P. <removed_email_address@domain.invalid> wrote:
> >> If you're interested, please see:
> >>http://gist.github.com/117694
>
> > Could you post us a few examples of what code formatted this way looks
>
> Oops, I should have done that when I posted before. Thanks for the reminder.

Fairly awesome. But I think we should consider keeping the colon, and
here's why: blocks that are not delimited by a colon at the start
behave exactly as normal Ruby blocks do, requiring an "end" to close
them, and more importantly ignoring indentation. That way, existing
code can be run through the preprocessor when it's "on", and will
continue to work. And it leaves people to pursue ASCII art with their
indentation, if they are so inclined.

Matz says the colon won't work as a delimiter, though. I'm curious to
know why, but even so, surely something would work.
Joshua B. (Guest)
on 2009-05-28 09:41
(Received via mailing list)
On May 27, 2009, at 9:35 AM, J Haas wrote:

> worked fine.)
Ok, but now you're beginning to see the edge cases that make this sort
of transformation difficult on a global level. Specifically, how would
you differentiate between these two cases using Pythonic indentation:

 > cat conditional_case.rb
result = case ARGV[0]
   when /^\d*$/
     "That's an integer"
   when /^[A-Za-z]*$/
     "That looks like a word..."
   else
     "That's not an integer or a word"
   end if ARGV[0]

puts result

 > cat case_and_conditional.rb
result = case ARGV[0]
   when /^\d*$/
     "That's an integer"
   when /^[A-Za-z]*$/
     "That looks like a word..."
   else
     "That's not an integer or a word"
   end
if ARGV[0]
   puts result
end


Attaching a conditional to the end of a case statement (or any block,
for that matter) is possible in Ruby because the block is just an
expression, and the statement doesn't end until the newline. With your
preprocessor, adding "end " when the indentation level decreases would
yield the first form, but then how do I get the second form? I suppose
I could both decrease the indentation level and leave a blank space,
but then it seems like we're adding an awful lot of formatting rules
just to have the code look nice and still function. On top of that, I
think this makes things much less clear! Consider that in "Pythonic
form" the above cases would become:

 > cat pythonic_conditional_case.rb
result = case ARGV[0]:
   when /^\d*$/
     "That's an integer"
   when /^[A-Za-z]*$/
     "That looks like a word..."
   else
     "That's not an integer or a word"
if ARGV[0]
puts result

 > cat pythonic_case_and_conditional.rb
result = case ARGV[0]:
   when /^\d*$/
     "That's an integer"
   when /^[A-Za-z]*$/
     "That looks like a word..."
   else
     "That's not an integer or a word"

if ARGV[0]:
   puts result


Looking at those two pieces of code, is it clear that they do two
different things? At the very least, I think that this sort of change
to the syntax would have to be optional. This would, of course, mean
that you're not getting rid of all of the "end"s in code, so then
what's the point (other than to confuse matters of syntax even more)?

Let me also provide a counter-point. I'm currently using MacVim with
the ruby-vim files and a coloring scheme which colors "def...end"
pairs in yellow and other "case/if/do/etc...end" pairs in purple. This
gives me a good way to quickly look at some code, and if I see that
the "end" immediately preceding a "def" is purple, then I know I've
forgotten and "end" somewhere in that function definition.

Finally, let me suggest a bit of a "wisdom of crowds" argument: if the
advantages to significant whitespace were so unambiguously clear as
you'd have us believe, then why do most languages not use it (even
those developed before many of the advantages of advanced text editors/
IDEs existed)?

- Josh
Jan F. (Guest)
on 2009-05-28 13:46
(Received via mailing list)
J Haas <removed_email_address@domain.invalid> wrote:
> few areas where I think Python beats Ruby, and that's syntatically-
> significant
> indentation.
You think so, I'm not. ;)

> like this:
>
>             end
>           end
>         end
>       end
>     end
>   end
> end
>
> This is *not* DRY.
Objection! It is DRY: You have already mentioned that in Ruby indention
is not significant. The "ends" in your example are the *only* (not
repeated!) representation of the end of a block.

Regards,
Jan
Eleanor McHugh (Guest)
on 2009-05-28 14:13
(Received via mailing list)
On 27 May 2009, at 17:41, Reid T. wrote:
> I find this code less readable than the above original code with the
> 'end's included

+1 - the significant white space is one of several reasons I've never
managed to get comfy with python.

Personally I like 'end' because it makes it explicitly clear that the
programmer's intent was to end a block at that point, and I've wasted
enough of my life tracking down nesting errors not to want to give up
that extra bit of insight. If other people feel differently, well it's
there code and they're free to do as they please with it so long as
I'm not expected to maintain it.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
Tony A. (Guest)
on 2009-05-28 14:41
(Received via mailing list)
On Wed, May 27, 2009 at 10:41 AM, Reid T.
<removed_email_address@domain.invalid>wrote:

> I find this code less readable than the above original code with the
> 'end's included
>

I like the symmetry that end statements give to the code.  It feels
more...
balanced or something.
Reid T. (Guest)
on 2009-05-28 15:57
(Received via mailing list)
On Thu, 2009-05-28 at 14:40 +0900, Joshua B. wrote:
> the ruby-vim files

could you provide an url for these?

Thanks,
reid
Juan Z. (Guest)
on 2009-05-28 18:07
(Received via mailing list)
On May 27, 2009, at 12:35 PM, J Haas wrote:

> worked fine.)
> controllers.
>>> transformable into indentation only blocks.  Does that make sense?
>> github.com/binarylogic/authlogic_example/tree):
>> helper_method :current_user_session, :current_user
>>      @current_user = current_user_session &&
>>    end
>>    def store_location
>>
>> # Likewise, all the methods added will be available for all
>>      @current_user_session = UserSession.find
>>        redirect_to new_user_session_url
>>      session[:return_to] = request.request_uri
> hard to do.  But the impossible examples seem to be defeated fairly
>
> filter_parameter_logging :password, :password_confirmation
> current_user_session.record
>
>      session[:return_to] = request.request_uri
> Nothing particularly special about this code, right? Pretty standard
>
>    def current_user:
>
>    def redirect_back_or_default(default):
>      redirect_to(session[:return_to] || default)
>      session[:return_to] = nil
>
>
As I've watched this debate unfold I've watched the stronger
criticisms fall
apart.  The strongest type of criticism would be that it can't be
done, or that
it's too hard to be done.  But the impossible examples seem to be
defeated
fairly easily.   Moreover, the solutions are backward compatible to
existing
Ruby.

Now when I look at this latest example I see some ordinary code that's
44 lines
long.  With the pythonic scheme it looks like it's only 35 lines
long.  I find
it difficult to convince myself that it's a good idea to make code 25%
larger
just to preserve some ends of dubious value.

I suppose I could try to come up with some nonsense argument that
'end' makes
everything more readable.  But that would just be prejudice.  The
pythonic
example is trivially easy to read.  It can't just be me.  There seems
to be no
shortage of Python folk who have no problem.   Objectively, the ends
just take
up a whole lot of space.
Caleb C. (Guest)
on 2009-05-28 18:20
(Received via mailing list)
On 5/27/09, Roger P. <removed_email_address@domain.invalid> wrote:
>> #you can explicitly end just the last scope of something deeply nested.
>> class A
>>   class B
>>     class C
>>       module D
>>         foo
>> end #actually 4 ends
>
>
> I assume that that end is optional, too?

Yes.

> end also doubles as the equivalent for Python's "pass", as well?

Mostly. As I understand it, pass in python is a no-op. End 'stand in',
if you will, for the value of the entire statement it's ending.

(In endless.rb, if you really want a no-op to end your statement, you
should use an (appropriately indented) semicolon.)

> So you can have ends if you want them but they're optional?

You got it. Your end now HAS to be intented right, tho.

> Does it work with {}'s too?

No... seemed a little weird to me to have { without the matching }.
But there's no technical reason why { couldn't be autoended too.

> So the basic rule it uses is that if something returns to the original
> indentation level without being an end, it assumes it should have been
> an end, is that right? (i.e. it *requires* blocks to be at a greater
> indentation level).

Yep.

J Hass wrote:
> Fairly awesome. But I think we should consider keeping the colon, and
> here's why: blocks that are not delimited by a colon at the start
> behave exactly as normal Ruby blocks do, requiring an "end" to close
> them, and more importantly ignoring indentation. That way, existing
> code can be run through the preprocessor when it's "on", and will
> continue to work. And it leaves people to pursue ASCII art with their
> indentation, if they are so inclined.

In my preprocessor, end is still allowed, it's just optional now. So
you can copy and paste from a normal ruby file and not worry. (As log
as the snippet you paste is properly indented.)
Eleanor McHugh (Guest)
on 2009-05-28 18:46
(Received via mailing list)
On 28 May 2009, at 15:06, Juan Z. wrote:
> As I've watched this debate unfold I've watched the stronger
> criticisms fall
> apart.  The strongest type of criticism would be that it can't be
> done, or that
> it's too hard to be done.  But the impossible examples seem to be
> defeated
> fairly easily.   Moreover, the solutions are backward compatible to
> existing
> Ruby.

Some cases have been presented elsewhere in this thread where the
pythonic indentation would fall flat: specifically for expressions of
the form

a = case x
   when...
   when...
   when...
end if y

It's not a common formulation in this form, but it highlights the
problem of using significant whitespace as an expression delimiter in
expression-based languages. Were there a way to solve this ambiguity
elegantly then there would be a case in favour of introducing pythonic
indentation, but until then this would either introduce an unnecessary
limitation on the things that can be expressed in ruby or lead to a
considerably more complicated lexer that might have other implications.

> everything more readable.  But that would just be prejudice.  The
> pythonic
> example is trivially easy to read.  It can't just be me.  There
> seems to be no
> shortage of Python folk who have no problem.   Objectively, the ends
> just take
> up a whole lot of space.

Begin..end indicates explicitly that a series of expressions is
contained between these statements and that their return value is
available to use as part of a more complex expression which may have
modifiers, something of great value to some of us. Your experience
might well be very different and this might not be a use case you
commonly encounter, but please don't make the mistake of believing
that your use case invalidates the utility of this language feature.
Most of the code I work on takes this form and has perhaps a 10%
density of 'end' statements, if that.

Admittedly when I've worked on Rails apps I've seen the 25%
demonstrated in your quoted example frequently: to my mind that's a
code smell suggesting that much of that code is boilerplate ripe for
abstraction and meta-programming. Such an approach would bring the
'end' density back down to an acceptable and useful level.

The real answer to this issue is to have a pythonic indentation pre-
processor for those who find that of use, and to leave the core
language syntax alone.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
Pascal J. Bourguignon (Guest)
on 2009-05-28 19:05
(Received via mailing list)
Eleanor McHugh <removed_email_address@domain.invalid> writes:

>
> It's not a common formulation in this form, but it highlights the
> problem of using significant whitespace as an expression delimiter in
> expression-based languages. Were there a way to solve this ambiguity
> elegantly then there would be a case in favour of introducing pythonic
> indentation, but until then this would either introduce an unnecessary
> limitation on the things that can be expressed in ruby or lead to a
> considerably more complicated lexer that might have other implications.

There's a simply way to solve it.  Since everything is an expression,
we can easily wrap expressions and subexpressions in parentheses, and
by the way resolve any ambiguity:

(a = ((case x
       when ...
       when ...
       when ...
       end) if y))

((a = (case x
       when ...
       when ...
       when ...
       end))
 if y)



> Begin..end indicates explicitly that a series of expressions is
> contained between these statements and that their return value is
> available to use as part of a more complex expression which may have
> modifiers, something of great value to some of us. Your experience
> might well be very different and this might not be a use case you
> commonly encounter, but please don't make the mistake of believing
> that your use case invalidates the utility of this language feature.
> Most of the code I work on takes this form and has perhaps a 10%
> density of 'end' statements, if that.

It could be reduced to 0%, if you notice that the close parenthesis is
all that is needed to end the subexpressions.

(a = ((case x
       when ...
       when ...
       when ...) if y))

((a = (case x
       when ...
       when ...
       when ...))
 if y)


Also we could decide to always put the operator first, to simplify a
little:


(a = (if y
         (case x
           when ...
           when ...
           when ...)))

(if y
    (a = (case x
           when ...
           when ...
           when ...)))

so it would be clearer what is IF'ed.


> The real answer to this issue is to have a pythonic indentation pre-
> processor for those who find that of use, and to leave the core
> language syntax alone.

Exactly.  The concrete syntax should be purely a question of
presentation and user interface, that should be dealt with by the
editor.  Source files could be kept in s-exp form, like it was
intended originally (50 years ago).
J Haas (Guest)
on 2009-05-28 20:16
(Received via mailing list)
On May 28, 7:19 am, Caleb C. <removed_email_address@domain.invalid> wrote:
> In my preprocessor, end is still allowed, it's just optional now. So
> you can copy and paste from a normal ruby file and not worry. (As log
> as the snippet you paste is properly indented.)

This was my point. It would be good to still have the option of
freeform indentation. Much Ruby code _isn't_ presently canonically
formatted, and it'd break if put through your preprocessor. One
solution to this would be to only activate the preprocessor on a per-
file basis, but I think a better solution would be for the
preprocessor not to damage existing code. The ultimate goal in the
long term should be to make this style part of core Ruby syntax rather
than the result of a preprocessor, and the best way to do that would
be for the parser to be able to distinguish between indentation-aware
blocks and "old-style" blocks.
Caleb C. (Guest)
on 2009-05-28 20:44
(Received via mailing list)
On 5/28/09, Eleanor McHugh <removed_email_address@domain.invalid> wrote:
> Some cases have been presented elsewhere in this thread where the
> pythonic indentation would fall flat: specifically for expressions of
> the form
>
> a = case x
>    when...
>    when...
>    when...
> end if y

I feel that I did address this point adequately already, so it's
annoying to see both you and Joshua B. bring it up again,
without even acknowledging that I had done so. Perhaps you don't agree
with my points, but as you haven't tried to rebut them, I think it
more likely that you did not read what I had to say at all.

To reiterate: Yes, you can't really write that expression without an
end. Cases like this are why I decided, in my preprocessor, to allow
users to put in an end if they really want to. It's sufficiently rare
to need more tokens on the same line after an end that it's not
unreasonable to ask the user to type an extra (normally unnecessary)
end in those cases. 99% of ends can still be eliminated. If that
proportion were lower -- 50% or 75% or even 90%, I would say that the
convenience of not having to type end is outweighed by the additional
burden of remembering that at least a tenth of the time you do anyway.
But when you get it down to the less than once a week level, a small
exception like this is ok. Very occasionally, you have to type end in
endless ruby. Very occasionally, you have to type pass in python. BFD.

> It's not a common formulation in this form, but it highlights the
> problem of using significant whitespace as an expression delimiter in
> expression-based languages. Were there a way to solve this ambiguity
> elegantly then there would be a case in favour of introducing pythonic
> indentation, but until then this would either introduce an unnecessary
> limitation on the things that can be expressed in ruby or lead to a
> considerably more complicated lexer that might have other implications.

I disagree that indentation sensitivity 'considerably' complicates the
lexer. endless.rb has about 180 lines of code, of which at least 25%
are concerned with the mechanics of pre-processing and wouldn't be
necessary if it were fully integrated into the lexer. It was
moderately difficult, but not bad. Quite a few other ruby features
(here documents, utf-8 in identifiers, the ambiguity of some
operators) were what I would call complicated; by comparison
indentation was pretty easy.

> The real answer to this issue is to have a pythonic indentation
> pre-processor for those who find that of use, and to leave the
> core language syntax alone.

I did, already.
Caleb C. (Guest)
on 2009-05-28 21:00
(Received via mailing list)
On 5/28/09, J Haas <removed_email_address@domain.invalid> wrote:
> On May 28, 7:19 am, Caleb C. <removed_email_address@domain.invalid> wrote:
>> In my preprocessor, end is still allowed, it's just optional now. So
>> you can copy and paste from a normal ruby file and not worry. (As log
>> as the snippet you paste is properly indented.)
>
> This was my point. It would be good to still have the option of
> freeform indentation. Much Ruby code _isn't_ presently canonically
> formatted, and it'd break if put through your preprocessor. One

If the end is misaligned, it will cause a warning on ruby 1.9. I think
the language is already moving in the direction of encouraging you to
properly indent everything anyway.
We've had changes to ruby before which break old code before, and I
think it's ok for this to be one too. (If this is going to be
integrated into the core language at all.) Always maintaining
backwards compatibility is one of the things that makes systems with a
long history kludgy, and I'm glad ruby doesn't have that hangup.

> solution to this would be to only activate the preprocessor on a per-
> file basis, but I think a better solution would be for the
> preprocessor not to damage existing code. The ultimate goal in the
> long term should be to make this style part of core Ruby syntax rather
> than the result of a preprocessor, and the best way to do that would
> be for the parser to be able to distinguish between indentation-aware
> blocks and "old-style" blocks.

Let's look at an example:

  if foo:  #new-style indentation block
   while bar #old-style ended block
baz
   end

Maybe you have something else in mind, idunno. To me, this just looks
totally weird, and I wouldn't expect it to work at all. Parsing this
(in a program) probably wouldn't be too much harder, but it's
significantly jarring to human readers. (At least, to this one.)
Gary W. (Guest)
on 2009-05-28 21:38
(Received via mailing list)
On May 28, 2009, at 12:39 PM, Caleb C. wrote:
> On 5/28/09, Eleanor McHugh <removed_email_address@domain.invalid> wrote:
>>
>> The real answer to this issue is to have a pythonic indentation
>> pre-processor for those who find that of use, and to leave the
>> core language syntax alone.
>
> I did, already.

I'm not convinced of the general utility of a pre-processor like
this.  Obviously it can be used 'privately', but code that is
written with the expectation of being pre-processed is not
portable unless the wider Ruby community (or even other developers
in your organization) are prepared to run it through a preprocessor.

For that to work there has to be a 'standard' of some sort or
you'll have to distribute the pre-processor along with your code.
And that argues for it to be part of the language and *not* a
pre-processor.

Yes, it is technically possible for this to 'work' but I just don't
see the value in expending all that community energy to make it work.
I'd rather see better documentation, better implementations of the
existing syntax, gem compatibility with 1.9, frameworks that improve
my productivity, and so on.

Even if there was some way to prove that pythonic-indentation for
Ruby was 'better' than the current syntax rules any benefit has
to offset the costs of transition also (tools, developer workflow,
IDE re-writes, books, tutorials, bugs introduced in a mixed code
base, new idioms, etc.)

It just doesn't seem worth it to me.

Gary W.
J Haas (Guest)
on 2009-05-28 21:41
(Received via mailing list)
On May 28, 9:59 am, Caleb C. <removed_email_address@domain.invalid> wrote:
> If the end is misaligned, it will cause a warning on ruby 1.9.

Does it? That's pretty cool.

> I think
> the language is already moving in the direction of encouraging you to
> properly indent everything anyway.
> We've had changes to ruby before which break old code before, and I
> think it's ok for this to be one too.

Well... keep in mind that this would break a _lot_ of code. One of the
things I had my script do (the one which computed ~16% non-blank lines
were nothing but 'end') was try to figure out how many instances there
were of 'end' not being aligned with the block it began. The answer
was: relatively few, in the single-digit percentages, but that still
worked out to several hundred instances.

> Always maintaining
> backwards compatibility is one of the things that makes systems with a
> long history kludgy, and I'm glad ruby doesn't have that hangup.

I completely agree with you in principle, and I'm generally in favor
of breaking with the past when such a break is warranted. But
listening to the objections people have raised in this thread, for a
lot of people it boils down to "I don't like it." Well, there's no
accounting for taste, and while I happen to feel that many of these
people would change their tune once they've had a little experience
with syntactic indentation, I think the best way to assuage their
doubts would be for any change to have absolutely no impact on
existing code, with a clear distinction between old-style syntax and
new-style indentation-aware syntax.

Besides, I kind of like the look of the colon as a block-start
delimiter. It emphasizes the separation between the loop or
conditional or method call and the block it controls.

> Let's look at an example:
>
>   if foo:  #new-style indentation block
>    while bar #old-style ended block
> baz
>    end
>
> Maybe you have something else in mind, idunno. To me, this just looks
> totally weird, and I wouldn't expect it to work at all.

Yep, looks totally weird to me too. Okay, so: no end-delimited blocks
nested inside indentation-delimited blocks. Once you're inside a scope
where the parser is paying attention to your indentation, it will
continue paying attention to your indendation until you leave that
scope.
Eleanor McHugh (Guest)
on 2009-05-28 22:05
(Received via mailing list)
On 28 May 2009, at 17:39, Caleb C. wrote:
>
> I feel that I did address this point adequately already, so it's
> annoying to see both you and Joshua B. bring it up again,
> without even acknowledging that I had done so. Perhaps you don't agree
> with my points, but as you haven't tried to rebut them, I think it
> more likely that you did not read what I had to say at all.

Possibly not. This has been a long thread and I'm sure I've either
missed posts or misunderstood their intent.

> exception like this is ok. Very occasionally, you have to type end in
> endless ruby. Very occasionally, you have to type pass in python. BFD.

And as I've said elsewhere, how you handle things in a preprocessor is
entirely up to you. I'm not your target audience as I don't like
pythonic indentation - it's one of the reasons I didn't take to the
language despite several attempts to get into it - but I'm sure those
who are won't mind writing the occasional end statement.

>
> I disagree that indentation sensitivity 'considerably' complicates the
> lexer. endless.rb has about 180 lines of code, of which at least 25%
> are concerned with the mechanics of pre-processing and wouldn't be
> necessary if it were fully integrated into the lexer. It was
> moderately difficult, but not bad. Quite a few other ruby features
> (here documents, utf-8 in identifiers, the ambiguity of some
> operators) were what I would call complicated; by comparison
> indentation was pretty easy.

Until I have time to study your code I'll take your word for that.
Have you tried framing endless.rb as a patch for MRI's lexer? and if
so how significant are the changes?

>> The real answer to this issue is to have a pythonic indentation
>> pre-processor for those who find that of use, and to leave the
>> core language syntax alone.
>
> I did, already.

Then put out an [ANN] and if the community finds pythonic indentation
valuable, it'll catch on.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
Juan Z. (Guest)
on 2009-05-28 22:10
(Received via mailing list)
On May 28, 2009, at 12:39 PM, Caleb C. wrote:

>
> unreasonable to ask the user to type an extra (normally unnecessary)
> end in those cases. 99% of ends can still be eliminated. If that
> proportion were lower -- 50% or 75% or even 90%, I would say that the
> convenience of not having to type end is outweighed by the additional
> burden of remembering that at least a tenth of the time you do anyway.
> But when you get it down to the less than once a week level, a small
> exception like this is ok. Very occasionally, you have to type end in
> endless ruby. Very occasionally, you have to type pass in python. BFD.

Exactly,  this is a bit of a straw man issue.  Nobody is saying get
rid of all
ends.  Use end where it makes sense,  but if it's just wasting space
there is
no need.

>> considerably more complicated lexer that might have other
>> implications.
>
> I disagree that indentation sensitivity 'considerably' complicates the
> lexer. endless.rb has about 180 lines of code, of which at least 25%
> are concerned with the mechanics of pre-processing and wouldn't be
> necessary if it were fully integrated into the lexer. It was
> moderately difficult, but not bad. Quite a few other ruby features
> (here documents, utf-8 in identifiers, the ambiguity of some
> operators) were what I would call complicated; by comparison
> indentation was pretty easy.

That code was pretty standard looking.   It had some functions in a
class.  The
nesting wasn't particularly deep.  Are classes with functions now
considered
code smell?  Also, if I recall correctly the Ruby core libraries are
about 16%
end.   That ought to be, relatively speaking, pretty good Ruby.   So
ironically, if Ruby added this capability it's own code base would
shrink.

>
>
>> The real answer to this issue is to have a pythonic indentation
>> pre-processor for those who find that of use, and to leave the
>> core language syntax alone.
>
> I did, already.
>

I think I'll use it.  That said, the case for giving core Ruby this
capability
seems to be getting stronger.
Eleanor McHugh (Guest)
on 2009-05-28 22:18
(Received via mailing list)
On 28 May 2009, at 16:05, Pascal J. Bourguignon wrote:
>> The real answer to this issue is to have a pythonic indentation pre-
>> processor for those who find that of use, and to leave the core
>> language syntax alone.
>
> Exactly.  The concrete syntax should be purely a question of
> presentation and user interface, that should be dealt with by the
> editor.  Source files could be kept in s-exp form, like it was
> intended originally (50 years ago).

I got pulled from a project a couple of years ago for saying the same
thing about DNS records. Some people really do lack a sense of humour ;)


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
Juan Z. (Guest)
on 2009-05-28 22:25
(Received via mailing list)
It's interesting that Ruby doesn't force you to use semicolons all
over the
place like C or Java.  You only use them were they are actually
necessary
disambiguate something.  Ruby also doesn't force you to use
parentheses for
function definitions or function calls.  Again, you only need them when
something is ambiguous.  Ruby accomplishes these tricks by using
significant
whitespace.  Optional 'end' seems very consistent with this philosophy.
Caleb C. (Guest)
on 2009-05-28 23:14
(Received via mailing list)
On 5/28/09, Eleanor McHugh <removed_email_address@domain.invalid> wrote:
> Until I have time to study your code I'll take your word for that.
> Have you tried framing endless.rb as a patch for MRI's lexer? and if
> so how significant are the changes?

urk. I'm not familiar with the mri lexer code. In case I wasn't clear
before, when I said that it was relatively easy to add to the lexer, I
meant my lexer. Of course everything is much less fun in c than it is
in ruby; 150 lines of rubylexer hacks might be equivalent to 600 lines
or more of c. On the other hand, since 1.9 is already warning about
misaligned ends, half of the code needed may be done already.

> Then put out an [ANN] and if the community finds pythonic indentation
> valuable, it'll catch on.

Perhaps I should, but I did it more as a lark and to prove that it
could be done.
Caleb C. (Guest)
on 2009-05-28 23:34
(Received via mailing list)
On 5/28/09, J Haas <removed_email_address@domain.invalid> wrote:
> I completely agree with you in principle, and I'm generally in favor
> of breaking with the past when such a break is warranted. But
> listening to the objections people have raised in this thread, for a
> lot of people it boils down to "I don't like it." Well, there's no
> accounting for taste, and while I happen to feel that many of these
> people would change their tune once they've had a little experience
> with syntactic indentation, I think the best way to assuage their
> doubts would be for any change to have absolutely no impact on
> existing code, with a clear distinction between old-style syntax and
> new-style indentation-aware syntax.

You're making an argument based on other people's opinions, for which
you have no evidence. I rather doubt that the naysayers on this thread
will be much convinced by such a fine point.

> Besides, I kind of like the look of the colon as a block-start
> delimiter. It emphasizes the separation between the loop or
> conditional or method call and the block it controls.

Ah, now we get down to it. It's really all just a matter of taste.

Would a semicolon make you just as happy? ;) It looks almost the same
and can be used where you want a colon already:

  while foo;
     bar

> Yep, looks totally weird to me too. Okay, so: no end-delimited blocks
> nested inside indentation-delimited blocks. Once you're inside a scope
> where the parser is paying attention to your indentation, it will
> continue paying attention to your indendation until you leave that
> scope.

Can you give an example of when you would want indentation to be
ignored that's not overly weird looking to you?
J Haas (Guest)
on 2009-05-29 00:06
(Received via mailing list)
On May 28, 12:33 pm, Caleb C. <removed_email_address@domain.invalid> wrote:
> > I think the best way to assuage their
> > doubts would be for any change to have absolutely no impact on
> > existing code, with a clear distinction between old-style syntax and
> > new-style indentation-aware syntax.
>
> You're making an argument based on other people's opinions, for which
> you have no evidence. I rather doubt that the naysayers on this thread
> will be much convinced by such a fine point.

Okay then, remove "assuage their doubts" and replace it with "pull the
teeth of their arguments." It's hard to argue against something that's
completely optional. You can say that syntactic indentation is worse
than 'end' until you're blue in the face, but how do you say that
having choices is worse than not having them?

> > Besides, I kind of like the look of the colon as a block-start
> > delimiter. It emphasizes the separation between the loop or
> > conditional or method call and the block it controls.
>
> Ah, now we get down to it. It's really all just a matter of taste.

No, seriously, this was an aside. I do prefer the look of having the
colon, but far more important than aesthetics is the fact that using a
colon (or other delimiter) would preserve compatibility with blocks
that have random indentation.

> Would a semicolon make you just as happy? ;) It looks almost the same
> and can be used where you want a colon already:
>
>   while foo;
>      bar

I wouldn't say it'd make me "just as happy"... I suppose I'd prefer it
to having no delimiter at all (and therefore not supporting blocks
that do not have canonical indentation) but the colon makes more sense
to me. Usually punctuation marks in programming languages at least try
to have some relation to their plain human-language meaning (foo?
foo!) and the colon means 'here comes a bunch of stuff related to the
thing before the colon'.

> Can you give an example of when you would want indentation to be
> ignored that's not overly weird looking to you?

I suppose I could but it seems tangential. Grep the Ruby standard
library and you'll find hundreds of places which would break if
indentation were enforced, there are your examples. And besides, I'm
all in favor of choice. Even if freeform indentation is "overly weird
looking" to me, it may not be for someone else, who should have the
option of using it should he wish.
Rimantas L. (Guest)
on 2009-05-29 00:11
(Received via mailing list)
> Okay then, remove "assuage their doubts" and replace it with "pull the
> teeth of their arguments." It's hard to argue against something that's
> completely optional. You can say that syntactic indentation is worse
> than 'end' until you're blue in the face, but how do you say that
> having choices is worse than not having them?

Because it confuses. And having confusion about significance of
the whitespace in a programming language is a VERY bad thing
to have.

Regards,
Rimantas
Juan Z. (Guest)
on 2009-05-29 00:23
(Received via mailing list)
On May 28, 2009, at 4:09 PM, Rimantas L. wrote:

> to have.
Would you be in favor of forcing the use of parentheses for functions
and semicolons at the end of lines instead of significant white space?
Rimantas L. (Guest)
on 2009-05-29 00:34
(Received via mailing list)
>> Would you be in favor of forcing the use of parentheses for functions and
> semicolons at the end of lines instead of significant white space?

No. And I am even less in favour of having to count spaces at the
beginning of
the line.
Maybe I chose the wrong word. Well I want optional significant spaces
even less.

Regards,
Rimantas
Eleanor McHugh (Guest)
on 2009-05-29 01:28
(Received via mailing list)
On 28 May 2009, at 20:13, Caleb C. wrote:
> misaligned ends, half of the code needed may be done already.
I'd say 150 lines of ruby more often ends up 1500 lines of C lol

>> Then put out an [ANN] and if the community finds pythonic indentation
>> valuable, it'll catch on.
>
> Perhaps I should, but I did it more as a lark and to prove that it
> could be done.

Well the real proof of the pudding is in figuring out how to patch it
into the MRI and JRuby lexers as those are the majority of installed
ruby runtimes. If it proves easy to do and doesn't muck up existing
functionality it would then be worth discussing over on [ruby-core]
and seeing what opposition it receives there.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
Tony A. (Guest)
on 2009-05-29 01:31
(Received via mailing list)
On Thu, May 28, 2009 at 1:33 PM, Caleb C. <removed_email_address@domain.invalid>
wrote:

> You're making an argument based on other people's opinions, for which
> you have no evidence. I rather doubt that the naysayers on this thread
> will be much convinced by such a fine point.
>

For what it's worth, when I got rid of indentation sensitivity in Reia
(by
adding "end" keywords) I got a lot of positive feedback from
indentation-haters, and no unsolicited cries to preserve it.  I had to
encourage people to give feedback in defense of indentation sensitivity.
Juan Z. (Guest)
on 2009-05-29 01:55
(Received via mailing list)
On May 28, 2009, at 4:32 PM, Rimantas L. wrote:

> Regards,
> Rimantas
> --
> http://rimantas.com/
>

You'll have to start shopping for a new language.   White space is
already significant in Ruby.
James B. (Guest)
on 2009-05-29 02:25
(Received via mailing list)
Reid T. wrote:

> I find this code less readable than the above original code with the
> 'end's included

Same here.


Maybe, after enough exposure, I would get used to it, but I don't see
anything intrinsic to that format that would make it more readable, and
currently (for whatever reasons) the endian version is more readable for
me.

FWIW, daring people to dispute what is ultimately a matter of opinion is
not terribly productive.  I've had enough discussions with Haml lovers
to know that rounds of "But look how beautiful it is" vs "I find it
grating" go nowhere.

Maybe some verifiable proof that compulsory indentation makes for faster
apps or less buggy code or simpler IDE tool development or whatever
would make for a better case.

"I like it" lacks an element of persuasion.



--
James B.

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
Charles J. (Guest)
on 2009-05-29 04:11
(Received via mailing list)
On May 28, 2009, at 12:21 AM, James B. wrote:

> FWIW, daring people to dispute what is ultimately a matter of
> opinion is not terribly productive.  I've had enough discussions
> with Haml lovers to know that rounds of "But look how beautiful it
> is" vs "I find it grating" go nowhere.


Exactly. I prefer chocolate ice cream to python, and thai cuisine to
both.

Cheers--

Charles
---
Charles J.
Advanced Computing Center for Research and Education
Vanderbilt University
James B. (Guest)
on 2009-05-29 04:53
(Received via mailing list)
Tony A. wrote:

>
> For what it's worth, when I got rid of indentation sensitivity in Reia (by
> adding "end" keywords) I got a lot of positive feedback from
> indentation-haters, and no unsolicited cries to preserve it.  I had to
> encourage people to give feedback in defense of indentation sensitivity.

What was the reason for remove indentation sensitivity?



James
J Haas (Guest)
on 2009-05-29 05:00
(Received via mailing list)
On May 27, 10:21 pm, James B. <removed_email_address@domain.invalid> wrote:
> FWIW, daring people to dispute what is ultimately a matter of opinion is
> not terribly productive.  

Yeah, I realized that as soon as I posted. Sorry 'bout that. But look
at it this way.

In the example from AuthLogic I posted, which is real-world code and
not at all atypical, just under one-fourth of the non-blank, non-
comment lines consist of the bare word 'end'. The 'end' keyword
doesn't _do_ anything. It's just a signal to the parser that here is
the end of the block... and with canonical indentation, this is
something the parser is quite capable of inferring on its own. 'end'
is redundant.

Code speaks louder, right? The whole point of writing code is to tell
the interpreter what you want it to do, and the whole concept of
'expressiveness' is based on being able to tell the interpreter what
you want it to do with a minimum of overhead. Let's tell the
interpreter to do something:

   1.upto 10 do |x|
      p x

Stop! Don't write another word. At this point, you've told the
interpreter _exactly_ what you want. Using the bare minimum of code,
you've expressed with perfect clarity your intent. Anything you write
beyond that is superfluous. And if the language _requires_ you to
write this extraneous code, it's not as expressive as it could be.

I know it looks funny to a lot of people. It looked funny to me the
first time, too. As I said, my reaction when I first learned of
significant indentation was the same reaction I've seen from lots of
developers I've told about it: "what, are you kidding?" But it makes
sense. After a day or two of playing around with it, you'll find that
it becomes second nature.
Tony A. (Guest)
on 2009-05-29 05:08
(Received via mailing list)
On Thu, May 28, 2009 at 6:52 PM, James B. <removed_email_address@domain.invalid>
wrote:

> What was the reason for remove indentation sensitivity?


I was using a Python-style lexer in conjunction with a Ruby-like
(almost)
pure expression grammar, and running into the issues I've outlined in
this
thread regarding indent blocks in expressions.

I detailed many of the problems in this blog post:

http://unlimitednovelty.com/2009/03/indentation-se...

I'm surprised by how well the solutions others are coming up for this
are
working.  The script J Haas found just throws regexes at the problem
(and
removes any degree of formal decidability), however the RubyLexer
approach
sounds interesting.

That said, I have no regrets with ditching indentation sensitivity.  If
anything it seemed to alienate people who would otherwise be interested,
and
now Reia has the advantage of looking nearly identical to Ruby.  Porting
Ruby programs to Reia programs is now substantially easier.
James B. (Guest)
on 2009-05-29 05:36
(Received via mailing list)
Tony A. wrote:
>
> http://unlimitednovelty.com/2009/03/indentation-se...
>
> I'm surprised by how well the solutions others are coming up for this are
> working.  The script J Haas found just throws regexes at the problem (and
> removes any degree of formal decidability), however the RubyLexer approach
> sounds interesting.


It seems that without formal decidability you'll end up coding yourself
into a corner, where you can't change or add anything because of the
side-effects.

> That said, I have no regrets with ditching indentation sensitivity.  If
> anything it seemed to alienate people who would otherwise be interested, and
> now Reia has the advantage of looking nearly identical to Ruby.  Porting
> Ruby programs to Reia programs is now substantially easier.
>


Very cool!

--
James B.

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
Michael Bruschkewitz (Guest)
on 2009-05-29 05:57
(Received via mailing list)
"Roger P." <removed_email_address@domain.invalid> schrieb im Newsbeitrag
news:removed_email_address@domain.invalid...
> @Michael:
> I don't think having "either or" syntax would be such a terrible thing
> in terms of team re-use or resources--you should be able to convert the
> code back and forth at will (a la ruby2ruby, parsetree [rubylexer has a
> parsetree compatibility mode] etc.)

Uuups, that's me.
(BTW: What a discussion, about 2 vs. 20 ... that's really asymmetric
warfare...)

Yes, for sure it would be possible to convert sources back and forth and
up
and down.
Maybe someone would create the perfect converter.
Given there are people prefer PyI or not, maybe others loving brackets
the C
way or the Lisp way, or hating them, some would prefer do..end some
would
like curly brackets...
Going to the end: Convert Ruby code to P-Code which could be converted
to
F77... ;)
(If some scripts are not located on read-only media...)

But, put joking aside, for much more sure, it would definitely increase
(IMHO) the probability of errors much more effective than other
variations
which are already possible.

My work since some year is to decrease probability of errors - I'm
creating
testing tools, environments and scripts, performing integrations tests
and
so on.

People tend to make mistakes. So, extending possibilities for doing so
is
baaaad.
Scripts are always changed, and nearly nobody really cares about
indendation
or formatting when scripts look like:

    # Increase train speed to v_mode1
     @train.increaseSpeed 30

     # Pass signal 'sig1'
    @train.expectPosition 'sig1',5
...
    Did you really notice the different spaces? Try a proportional font.
...
or are created by some foreign language test case generation tools.

I don't like unnecessary syntax elements for scripting languages,
because
they spoil the view for the real problems. So I like Ruby's ability to
avoid
brackets, semicolons and so on.
Some people like brackets.
I like using "unless" instead of "if !" because it's more readable, you
don't need shift-key.
These possibility of variations did never brought problems into work.
It allows concentrate the attention of people to the real scenarios and
problems.

But, "end" brings much more safety, it is also a "social" thing - its
like
finally writing "done."
I think, avoid scrolling is a very minor argument. Who needs to scroll
so
much?
Would "J" encourage people to avoid comments and empty lines to avoid
50% of
scrolling?
(Would "Monk" like "end"?)

I would not like to waste resources of highly specialized people by
teaching
them the last corners of Ruby - it's a scripting language at last. And
it's
wonderful as such.
So I would never try to force them to distinguish between spaces, tabs
and
other whitespaces.
(They would try - these are tolerant people too...)

(Ohh .. sorry ... I wasted _my_ resources. Only 3 hours to sleep. Going
to
sleep now...)

Hope you got my point...

Regards,
Michael B.
Michael Bruschkewitz (Guest)
on 2009-05-29 06:01
(Received via mailing list)
"J Haas" <removed_email_address@domain.invalid> schrieb im Newsbeitrag
news:removed_email_address@domain.invalid...

>This was my point. It would be good to still have the option of
>freeform indentation. Much Ruby code _isn't_ presently canonically
>formatted, and it'd break if put through your preprocessor. One
>solution to this would be to only activate the preprocessor on a per-
>file basis, but I think a better solution would be for the
>preprocessor not to damage existing code. The ultimate goal in the
>long term should be to make this style part of core Ruby syntax rather
>than the result of a preprocessor, and the best way to do that would
>be for the parser to be able to distinguish between indentation-aware
>blocks and "old-style" blocks.

If it would be strictly optional it would be fine.
Should be need to be explicitely allowed for not breaking existent code.
Maybe as gem possible.


However, Ruby is about 10 years old now, Python and its insertion is
even
older.
If it would be so superior, didn't you think it would have been widely
accepted in the mean time?
And would have been spread over to other scripting languages already?
Michael Bruschkewitz (Guest)
on 2009-05-29 06:02
(Received via mailing list)
"Juan Z." <removed_email_address@domain.invalid> schrieb im Newsbeitrag
news:removed_email_address@domain.invalid...
>> Maybe I chose the wrong word. Well I want optional significant
>
>

Did somebody tried Brainf*ck language?
Juan Z. (Guest)
on 2009-05-29 06:26
(Received via mailing list)
On May 28, 2009, at 10:00 PM, Michael Bruschkewitz wrote:

>>> No. And I am even less in favour of having to count spaces at the
>>
>> You'll have to start shopping for a new language.   White space is
>> already significant in Ruby.
>>
>>
>
> Did somebody tried Brainf*ck language?
Now there's a readable language!
Juan Z. (Guest)
on 2009-05-29 06:33
(Received via mailing list)
> However, Ruby is about 10 years old now, Python and its insertion is
> even older.
> If it would be so superior, didn't you think it would have been
> widely accepted in the mean time?
> And would have been spread over to other scripting languages already?

You might.  And you'd be right.  Python is widely accepted.  Python,
by every indication I'm aware of, is more popular than Ruby.  TIOBE
lists Python is slightly more than twice as popular as Ruby
(http://www.tiobe.com/index.php/content/paperinfo/t...
).   And arguably, excluding any discussion of indentation, Ruby is a
better language.  I'm told that at Google they won't even  let you
code in Ruby.   They only allow a limited number of popular languages,
which includes Python but not Ruby.
Eleanor McHugh (Guest)
on 2009-05-29 06:48
(Received via mailing list)
On 28 May 2009, at 17:30, J Haas wrote:
> I know it looks funny to a lot of people. It looked funny to me the
> first time, too. As I said, my reaction when I first learned of
> significant indentation was the same reaction I've seen from lots of
> developers I've told about it: "what, are you kidding?" But it makes
> sense. After a day or two of playing around with it, you'll find that
> it becomes second nature.

You might just as well tell the Lisp community that all those brackets
they use are redundant. You might well find some converts, but I
suspect most people would look at you with a mix of incomprehension
and revulsion. In a certain sense Lisp *is* the brackets.

So contrary to how you feel about this, one size doesn't fit all -
especially not in matters of aesthetics. Indeed I suspect that much of
the resistance that you've experienced in this thread is a reflection
of the fact that your original post and this one both show an equal
lack of awareness of that fact.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
Juan Z. (Guest)
on 2009-05-29 07:04
(Received via mailing list)
On May 28, 2009, at 2:15 PM, Eleanor McHugh wrote:

> but I suspect most people would look at you with a mix of
> incomprehension and revulsion. In a certain sense Lisp *is* the
> brackets.
>
> So contrary to how you feel about this, one size doesn't fit all -
> especially not in matters of aesthetics. Indeed I suspect that much
> of the resistance that you've experienced in this thread is a
> reflection of the fact that your original post and this one both
> show an equal lack of awareness of that fact.

When was there ever great innovation in art that didn't cause anger
and revulsion?   Currently the one size fits all is that you must use
end.  It isn't a choice.   Yes, you can be a second class citizen and
use a preprocessor.  But how would you feel if the tables were
switched and new ruby forced you to not use end and your only
alternative was to use a preprocessor?
James B. (Guest)
on 2009-05-29 07:07
(Received via mailing list)
J Haas wrote:
> doesn't _do_ anything. It's just a signal to the parser that here is
> the end of the block... and with canonical indentation, this is
> something the parser is quite capable of inferring on its own. 'end'
> is redundant.

No, it's a signal to the human reading the code as well.

>
> Code speaks louder, right? The whole point of writing code is to tell
> the interpreter what you want it to do,

I'm with Harold Abelson and Gerald Jay Sussman on this point:


"Programs must be written for people to read, and only incidentally for
machines to execute."


> you've expressed with perfect clarity your intent. Anything you write
> beyond that is superfluous. And if the language _requires_ you to
> write this extraneous code, it's not as expressive as it could be.

But we're back in the realm of subjectivity regarding what is "bare
minimum of code" and "superfluous".  Ruby could be made quite terse, but
that's not a proper goal.

There is value in redundancy, and the trick is to find the right
balance, not to eliminate it completely.

Also, having more or less free reign on white space means I can express
non-computational information more easily by using unusual white space
to offset chunks of code or parameters to tell the reader, "Look, this
is important" at a glance.

Programming is a form of technical writing; judicious use of white space
is a critical means of communicating with the reader.


      Some times I really do
      want to do this.

      This is a powerful option.


>
> I know it looks funny to a lot of people. It looked funny to me the
> first time, too. As I said, my reaction when I first learned of
> significant indentation was the same reaction I've seen from lots of
> developers I've told about it: "what, are you kidding?" But it makes
> sense. After a day or two of playing around with it, you'll find that
> it becomes second nature.

That's the same argument I hear from Ham'l Qaeda; "Just give it more
time and you'll be enlightened in your ways".   :)


My experience says otherwise



--
James B.

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
James B. (Guest)
on 2009-05-29 07:18
(Received via mailing list)
Juan Z. wrote:

>
> When was there ever great innovation in art that didn't cause anger and
> revulsion?

My Over-the-top-O-meter just went over the top.


> Currently the one size fits all is that you must use end.
> It isn't a choice.   Yes, you can be a second class citizen and use a
> preprocessor.  But how would you feel if the tables were switched and
> new ruby forced you to not use end and your only alternative was to use
> a preprocessor?


Drop Ruby and finally move to Haskell?


:)

--
James B.

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
Reid T. (Guest)
on 2009-05-29 07:25
(Received via mailing list)
Michael Bruschkewitz wrote:
>

> If it would be strictly optional it would be fine.
> Should be need to be explicitely allowed for not breaking existent code.
> Maybe as gem possible.

There's no way it could be *strictly* optional.  Unless you provide some
way for
persons that want code block ends to automatically convert code without
ends to
code with ends.
Juan Z. (Guest)
on 2009-05-29 07:32
(Received via mailing list)
On May 28, 2009, at 2:33 PM, James B. wrote:

>> doesn't _do_ anything. It's just a signal to the parser that here is
>
>>      p x
>> Stop! Don't write another word. At this point, you've told the
>> interpreter _exactly_ what you want. Using the bare minimum of code,
>> you've expressed with perfect clarity your intent. Anything you write
>> beyond that is superfluous. And if the language _requires_ you to
>> write this extraneous code, it's not as expressive as it could be.
>
> But we're back in the realm of subjectivity regarding what is "bare
> minimum of code" and "superfluous".  Ruby could be made quite terse,
> but that's not a proper goal.
Terseness is a perfectly reasonable goal.  It's a corollary to Occam's
Razer.
No?   If you're going to sacrifice conciseness you should have a good
reason
for doing so.

>
> There is value in redundancy, and the trick is to find the right
> balance, not to eliminate it completely.

Exactly.  So there should be a choice.  Right?
>     Some times I really do
>     want to do this.
>
>     This is a powerful option.
>
It's possible to do this too.  Is it not?
Juan Z. (Guest)
on 2009-05-29 07:36
(Received via mailing list)
On May 28, 2009, at 2:46 PM, James B. wrote:

> Juan Z. wrote:
>
>> When was there ever great innovation in art that didn't cause anger
>> and revulsion?
>
> My Over-the-top-O-meter just went over the top.

Ah.  So you agree.  :)

Are we just left with aesthetic arguments disguised as readability
arguments?
Are some upset enough by the thought that somebody else might write
their code
differently that they're against even giving them a choice?
Eleanor McHugh (Guest)
on 2009-05-29 07:37
(Received via mailing list)
On 28 May 2009, at 19:31, Juan Z. wrote:
>>
>> show an equal lack of awareness of that fact.
>
> When was there ever great innovation in art that didn't cause anger
> and revulsion?

Anger and revulsion alone are not the proof of great innovation. Nor
for that matter does aesthetic innovation invalidate the tastes of
those who choose not to follow it.

>   Currently the one size fits all is that you must use end.  It
> isn't a choice.   Yes, you can be a second class citizen and use a
> preprocessor.  But how would you feel if the tables were switched
> and new ruby forced you to not use end and your only alternative was
> to use a preprocessor?

I probably wouldn't have taken to the language, just as I didn't take
to Python.

And would the fact that Python works the way it does justify my
arguing for inclusion of 'end'? It's hard to see how the language
could retain its character that way and it would be rather rude of me
to push the point with people who are clearly comfortable with its
current form. The same applies with Lisp, a beautiful language which I
choose not to use because I dislike the extensive use of parentheses.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
J Haas (Guest)
on 2009-05-29 07:51
(Received via mailing list)
On May 28, 11:15 am, Eleanor McHugh <removed_email_address@domain.invalid>
wrote:
> You might just as well tell the Lisp community that all those brackets  
> they use are redundant.

Sheesh, talk about strawmen. In Lisp, the parens are anything _but_
redundant. Lisp without brackets is riddled with ambiguity.
Conventionally-indented Ruby is not.

> So contrary to how you feel about this, one size doesn't fit all -  
> especially not in matters of aesthetics. Indeed I suspect that much of  
> the resistance that you've experienced in this thread is a reflection  
> of the fact that your original post and this one both show an equal  
> lack of awareness of that fact.

Yes, I was so unaware of this in my original post that I very
specifically made a proposal that would leave existing syntax
unchanged, which would allow people who wanted to use 'end' to
continue to use 'end', and which would break no existing code. My
proposal involved purely optional syntax, reflecting the fact that
many Rubyists are not convinced that syntactic indentation is the way
to go.

While one size certainly doesn't fit all, and while there's no
accounting for taste, some sizes seem to fit most people better than
others. Charles said that he preferred chocolate ice cream to Python.
Well, I don't know about that, but I'm betting he also prefers
chocolate ice cream to, say, mud... at least for eating. And I daresay
most people would prefer chocolate ice cream to mud for mud. But one
size doesn't fit all, and in a world of seven billion you can probably
find a handful of people whose preferences go the other way. So while
it may not be strictly accurate to say that chocolate ice cream is
"better" for eating than mud, it's close enough for most purposes. And
there's nothing wrong with approaching people who are chowing down on
mud because they've never _tried_ chocolate ice cream, handing them a
big ol' bowl of the good stuff, and saying, "Here, try this, you'll
probably like it better." Nor is there anything wrong with thinking
there's something a bit odd about those who, having tried both, prefer
the mud. Nor is there anything wrong with rolling your eyes at people
who say, "I tried half a teaspoon of your 'iced cream', and I like the
mud better."

I think I've just about stretched this analogy to the breaking point,
but I predict that if my proposal is implemented, and people are given
the choice to use syntactic indentation, within a couple of years
it'll be the norm, and most Ruby programmers will think it a bit weird
that anyone fought against it.
Caleb C. (Guest)
on 2009-05-29 08:06
(Received via mailing list)
On 5/28/09, James B. <removed_email_address@domain.invalid> wrote:
> Also, having more or less free reign on white space means I can express
> non-computational information more easily by using unusual white space
> to offset chunks of code or parameters to tell the reader, "Look, this
> is important" at a glance.

Can you give an example?
Rimantas L. (Guest)
on 2009-05-29 08:08
(Received via mailing list)
> I think I've just about stretched this analogy to the breaking point,
> but I predict that if my proposal is implemented, and people are given
> the choice to use syntactic indentation, within a couple of years
> it'll be the norm, and most Ruby programmers will think it a bit weird
> that anyone fought against it.

I just hope that people who would like to have syntactic indentation
will move on to Python.
Having both options in one languages is just asking for a huge mess.
If there is any voting on this my vote is a thousand times "no". :)


Regards,
Rimantas
Gary W. (Guest)
on 2009-05-29 08:11
(Received via mailing list)
On May 28, 2009, at 2:33 PM, James B. wrote:
> But we're back in the realm of subjectivity regarding what is "bare
> minimum of code" and "superfluous".  Ruby could be made quite terse,
> but that's not a proper goal.
>
> There is value in redundancy, and the trick is to find the right
> balance, not to eliminate it completely.


+1
Gregory B. (Guest)
on 2009-05-29 08:13
(Received via mailing list)
On Thu, May 28, 2009 at 3:34 PM, Caleb C. <removed_email_address@domain.invalid>
wrote:
> On 5/28/09, James B. <removed_email_address@domain.invalid> wrote:
>> Also, having more or less free reign on white space means I can express
>> non-computational information more easily by using unusual white space
>> to offset chunks of code or parameters to tell the reader, "Look, this
>> is important" at a glance.
>
> Can you give an example?

Maybe multi-line structures and expressions?

def foo("bar", :a => 1, :b => 2,
                      :c => 3, :d => 4)


end
James B. (Guest)
on 2009-05-29 08:21
(Received via mailing list)
Juan Z. wrote:
> On May 28, 2009, at 2:33 PM, James B. wrote:

>> But we're back in the realm of subjectivity regarding what is "bare
>> minimum of code" and "superfluous".  Ruby could be made quite terse,
>> but that's not a proper goal.
> Terseness is a perfectly reasonable goal.  It's a corollary to Occam's
> Razer.

Hardly.

> No?   If you're going to sacrifice conciseness you should have a good
> reason
> for doing so.

Readability for humans.

terse != concise.

I'm for concise speech, but not so fond of terseness.


>
>>
>> There is value in redundancy, and the trick is to find the right
>> balance, not to eliminate it completely.
>
> Exactly.  So there should be a choice.  Right?

In what? In how a language is designed?  You're free to design whatever
you like.

BTW, one thing about these sort of threads that puzzles me is why, given
the amazing choice of programming languages, do people push, for
example, to have Ruby be like Python,  when Python exists?  And do these
same people also go on Python lists and argue to make Python more like
Ruby?

If you want terseness, use Perl or APL.


> It's possible to do this too.  Is it not?
In a language such as Python?

If Ruby had magic indentation, could I do this?


def foo x,
         y,
         z

    some code

        Some Important Code I want to emphasize

        More Important Code I want to emphasize

    more code




James
James B. (Guest)
on 2009-05-29 08:29
(Received via mailing list)
Caleb C. wrote:
> On 5/28/09, James B. <removed_email_address@domain.invalid> wrote:
>> Also, having more or less free reign on white space means I can express
>> non-computational information more easily by using unusual white space
>> to offset chunks of code or parameters to tell the reader, "Look, this
>> is important" at a glance.
>
> Can you give an example?

def foo big,
         list,
         of,
         args

   some.stuff
   some.stuff
   some.stuff


          something.more.important!
          look.at.me!


   more.stuff = boring


end




For example.


James
Rimantas L. (Guest)
on 2009-05-29 08:33
(Received via mailing list)
> BTW, one thing about these sort of threads that puzzles me is why, given the
> amazing choice of programming languages, do people push, for example, to
> have Ruby be like Python,  when Python exists?  And do these same people
> also go on Python lists and argue to make Python more like Ruby?

Hear, hear! I have seen someone writing Ruby as if it was Lisp, attempts
to turn Ruby into Java (I am not talking about JRuby here), into Python
and a request for RHP. Is that "I like X, but Ruby is cool at the
moment,
let's make Ruby into X so it is the same thing I like and also cool"
way of thinking?

Regards,
Rimantas
Juan Z. (Guest)
on 2009-05-29 08:45
(Received via mailing list)
On May 28, 2009, at 3:51 PM, James B. wrote:

>
>> No?   If you're going to sacrifice conciseness you should have a
>> good reason
>> for doing so.
>
> Readability for humans.
>
> terse != concise.
You're splitting some fine hairs.  Apparently you have your own
dictionary.  http://www.thefreedictionary.com/terse

> In what? In how a language is designed?  You're free to design
> whatever you like.
Thank you for granting your permission.   I am humbled:)
>
>
> BTW, one thing about these sort of threads that puzzles me is why,
> given the amazing choice of programming languages, do people push,
> for example, to have Ruby be like Python,  when Python exists?  And
> do these same people also go on Python lists and argue to make
> Python more like Ruby?
>
> If you want terseness, use Perl or APL.


A weak argument.  Python is not Ruby with optional ends.    Neither is
Perl or APL.   So can I respond with an equally weak one?  Why not use
a statically typed language where there is far more redundancy, which
is apparently so necessary for human readability?

Yes, why indeed on a list about the Ruby language do people insist on
talking about the Ruby language.
J Haas (Guest)
on 2009-05-29 08:51
(Received via mailing list)
On May 28, 12:51 pm, James B. <removed_email_address@domain.invalid> wrote:
> BTW, one thing about these sort of threads that puzzles me is why, given
> the amazing choice of programming languages, do people push, for
> example, to have Ruby be like Python,  when Python exists?  And do these
> same people also go on Python lists and argue to make Python more like Ruby?

This puzzles you? This really, really puzzles you? Truly?

Then I'll try to explain.

Python is not merely Ruby with syntactic indentation. If it were,
you'd be absolutely correct and my complaint would be redundant, and
"switch to Python" would be good advice. But it's not. There are some
parts of Ruby that are better than Python, and if I switched to
Python, I'd have to give those up. There are also some parts of Python
that are better than Ruby, and switching to Ruby means giving them up.

Ruby is imperfect and could be improved, and before you recoil in
horror, it's no sacrilege to say so. As an engineer all I care about
is having the best tools for the job, and as such I'd rather work to
_improve_ an imperfect tool than abandon it for another tool which is
just as imperfect (or moreso) but in a different way.
J Haas (Guest)
on 2009-05-29 08:55
(Received via mailing list)
On May 28, 11:33 am, James B. <removed_email_address@domain.invalid> wrote:
>
> No, it's a signal to the human reading the code as well.
>
> > Code speaks louder, right? The whole point of writing code is to tell
> > the interpreter what you want it to do,
>
> I'm with Harold Abelson and Gerald Jay Sussman on this point:
>
> "Programs must be written for people to read, and only incidentally for
> machines to execute."

Have you noticed that your post is broken into paragraphs, and those
paragraphs are delimited solely by whitespace, and this does not
impair readability?

Have you noticed that this post contains quotes from you, and the
quotes from you contain quotes from me, and these quotes are delimited
from each other solely by indentation, and this does not impair
readability?

> But we're back in the realm of subjectivity regarding what is "bare
> minimum of code" and "superfluous".  Ruby could be made quite terse, but
> that's not a proper goal.
>
> There is value in redundancy, and the trick is to find the right
> balance, not to eliminate it completely.

Since we're in the realm of the subjective, I don't understand why you
and others are fighting so hard against having the _option_ of
syntactic indentation. Why are you so gung-ho on forcing your own
subjective interpretation of the "right balance" of useless redundancy
on everyone else?

> Programming is a form of technical writing; judicious use of white space
> is a critical means of communicating with the reader.
>
>       Some times I really do
>       want to do this.
>
>       This is a powerful option.

Can you cite some real world code, preferably in a widely-used
library, that does this?
Rimantas L. (Guest)
on 2009-05-29 08:57
(Received via mailing list)
> Python is not merely Ruby with syntactic indentation. If it were,
> you'd be absolutely correct and my complaint would be redundant, and
> "switch to Python" would be good advice. But it's not. There are some
> parts of Ruby that are better than Python, and if I switched to
> Python, I'd have to give those up. There are also some parts of Python
> that are better than Ruby, and switching to Ruby means giving them up.

Well, you can go to Python list and make a request to implement those
parts that you like in Ruby.

> Ruby is imperfect and could be improved, and before you recoil in
> horror, it's no sacrilege to say so. As an engineer all I care about
> is having the best tools for the job, and as such I'd rather work to
> _improve_ an imperfect tool than abandon it for another tool which is
> just as imperfect (or moreso) but in a different way.

Imperfection is in the eye of the beholder.

Regards,
Rimantas
Joshua B. (Guest)
on 2009-05-29 08:59
(Received via mailing list)
On May 28, 2009, at 9:39 AM, Caleb C. wrote:

> I feel that I did address this point adequately already, so it's
> annoying to see both you and Joshua B. bring it up again,
> without even acknowledging that I had done so. Perhaps you don't agree
> with my points, but as you haven't tried to rebut them, I think it
> more likely that you did not read what I had to say at all.

I did not intend to offend by not explicitly calling you out. I did
read that you had worked around this issue by allowing "end"s to be
optional, and I had assumed that most others following this (now
admittedly very long) thread would have as well. Again, I did not
imply that tackling this issue was impossible (despite my poor choice
of example script name). Indeed, I think I even showed how it would
still be possible to do this even without "end".

I fear I did not make my point clearly enough: I prefer do...end to
significant-whitespace. I think this is a commonly held preference,
but by no means globally held. However, mixing and matching seems, to
me, like a BAD idea. Why?

Well, if you're not going to enforce proper indenting when using
do...end, what happens when someone takes working, but poorly
formated, code from a do...end block and copy-pastes it into a block
using indentation instead? You now have code that works in one place
but not in the other. That is, with optional do...end/significant-
whitespace, code that works in one part of a source file might NOT
work in a different part, and the reason for this will be non-obvious.

How about this compromise: Fork Ruby, enforce significant-whitespace,
and instead of writing a preprocessor that converts significant-
whitespace into do...end form, write it to go the other way 'round.
All (or most) of the gems/libraries out there would still be
available, but now you could have a countable number of "Swuby" users
to show the superiority of significant-whitespace.

- Josh
Rimantas L. (Guest)
on 2009-05-29 09:07
(Received via mailing list)
> Have you noticed that your post is broken into paragraphs, and those
> paragraphs are delimited solely by whitespace, and this does not
> impair readability?

Do you know many other ways to break the text into paragraph?
Does the indentation of the first line changes the meaning of the
paragraph?

> Have you noticed that this post contains quotes from you, and the
> quotes from you contain quotes from me, and these quotes are delimited
> from each other solely by indentation, and this does not impair
> readability?

Quotes what I see are marked with ">".

> Since we're in the realm of the subjective, I don't understand why you
> and others are fighting so hard against having the _option_ of
> syntactic indentation. Why are you so gung-ho on forcing your own
> subjective interpretation of the "right balance" of useless redundancy
> on everyone else?

Because seemingly the same code in different modes can mean
completely different things.


Regards,
Rimantas
Joel VanderWerf (Guest)
on 2009-05-29 09:08
(Received via mailing list)
Juan Z. wrote:
>
> On May 28, 2009, at 3:51 PM, James B. wrote:
...
>> terse != concise.
> You're splitting some fine hairs.  Apparently you have your own
> dictionary.  http://www.thefreedictionary.com/terse

That link undermines your point:

   terse
   Adjective
   1. neatly brief and concise
   2. curt or abrupt [Latin tersus precise]

No one would say "I apologize for being concise with you"!
Reid T. (Guest)
on 2009-05-29 09:08
(Received via mailing list)
J Haas wrote:
> Have you noticed that your post is broken into paragraphs, and those
> paragraphs are delimited solely by whitespace, and this does not
> impair readability?
>
> Have you noticed that this post contains quotes from you, and the
> quotes from you contain quotes from me, and these quotes are delimited
> from each other solely by indentation, and this does not impair
> readability?
>

Not so.  I have varying levels of '>' characters.  Having only
whitespace in a
back and forth message chain does impair readability as far as I'm
concerned.
I ceased long ago using email clients that don't utilize some form of
leading
indicator.
J Haas (Guest)
on 2009-05-29 09:11
(Received via mailing list)
On May 28, 1:25 pm, Rimantas L. <removed_email_address@domain.invalid> wrote:
> Well, you can go to Python list and make a request to implement those
> parts that you like in Ruby.

I could. But frankly, there are more good features of Ruby missing
from Python than there are good features of Python missing from Ruby.
And implementing the biggest feature missing from Ruby would not be
terribly difficult, and would be fully optional and backward
compatible. I'm not sure that any of these things are true about
Python's deficiencies with respect to Ruby.

> Imperfection is in the eye of the beholder.

Do you disagree that Ruby is imperfect? If so, which version is
perfect, 1.8 or 1.9?
Gregory B. (Guest)
on 2009-05-29 09:11
(Received via mailing list)
On Fri, May 29, 2009 at 12:54 AM, Joshua B. 
<removed_email_address@domain.invalid>
wrote:

> How about this compromise: Fork Ruby, enforce significant-whitespace, and
> instead of writing a preprocessor that converts significant-whitespace into
> do...end form, write it to go the other way 'round. All (or most) of the
> gems/libraries out there would still be available, but now you could have a
> countable number of "Swuby" users to show the superiority of
> significant-whitespace.

This actually is about the most sensible thing I've seen in this
thread, hands down.   Whether or not it showed superiority, it could
show utility.

-greg
J Haas (Guest)
on 2009-05-29 09:12
(Received via mailing list)
On May 28, 1:36 pm, Rimantas L. <removed_email_address@domain.invalid> wrote:
> > Have you noticed that your post is broken into paragraphs, and those
> > paragraphs are delimited solely by whitespace, and this does not
> > impair readability?
>
> Do you know many other ways to break the text into paragraph?

Yes. You could be required to type 'end' at the end of every
paragraph. But that'd just be silly and redundant, considering that
whitespace does a perfectly good job as a delimiter.
Juan Z. (Guest)
on 2009-05-29 09:24
(Received via mailing list)
On May 28, 2009, at 4:37 PM, Joel VanderWerf wrote:

>  Adjective
>  1. neatly brief and concise
>  2. curt or abrupt [Latin tersus precise]
>
> No one would say "I apologize for being concise with you"!
>
> --
>      vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
>


It undermines nothing.  Concise is used as the definition as you've
just shown.   Also you seem to have omitted the part about "easy to
understand".  Why would you do that?  Or is your concern that the
computer will be offended?

 From that same page:

Adj. 1. terse - brief and to the point; effectively cut short; "a
crisp retort"; "a response so curt as to be almost rude"; "the laconic
reply; `yes'"; "short and terse and easy to understand
Caleb C. (Guest)
on 2009-05-29 09:34
(Received via mailing list)
On 5/28/09, James B. <removed_email_address@domain.invalid> wrote:
>    some.stuff
>
>
>           something.more.important!
>           look.at.me!
>
>
>    more.stuff = boring
>
>
> end

This (and your other, similar example) actually works in endless.rb
right now. Leave off the end and it inserts one for you, just where
you'd expect. You can always indent things more than necessary, and
that's fine. If you'd wanted to indent less than the surrounding code,
then I'd be in trouble. This won't work:

def foo big,
         list,
         of,
         args

   some.stuff
   some.stuff
   some.stuff


something.more.important!
look.at.me!


   more.stuff = boring


Gregory B. wrote:
> def foo("bar", :a => 1, :b => 2,
>                     :c => 3, :d => 4)
>
>
> end

But that's not legal. Presumably you meant either this:

def foo(bar, a = 1, b = 2,
                     c = 3, d = 4)


end

or this:

foo("bar", :a => 1, :b => 2,
                     :c => 3, :d => 4) do


end

Both break endless.rb. I sort of expected that the second one would
fail as soon as I saw it (do is the only thing that requires an end
but doesn't begin the expressions which it belongs to; I neglected to
consider the case of a do on a line after the one where it's method
call begins). But the first is a surprise.... that should have worked.
Well, they both should work, but now I have 2 bugs to fix. Thanks for
the test cases!
Petite A. (Guest)
on 2009-05-29 09:36
(Received via mailing list)
On May 28, 2009, at 10:53 PM, Juan Z. wrote:

> It undermines nothing.

"It depends on what the meaning of the words 'is' is."

Making Bill C. proud :D
Gregory B. (Guest)
on 2009-05-29 09:46
(Received via mailing list)
On Thu, May 28, 2009 at 5:03 PM, Caleb C. <removed_email_address@domain.invalid>
wrote:

> foo("bar", :a => 1, :b => 2,
>                     :c => 3, :d => 4) do
>
>
> end

Yeah, just this:

foo("bar", :a =>1, :b => 2,
                :c => 3, :d => 4)

with or without a block.


This is what I get for staring at the weird macruby method definition
syntax.   I'm not even sure if what I wrote was legal there, though :)
Gregory B. (Guest)
on 2009-05-29 09:49
(Received via mailing list)
On Thu, May 28, 2009 at 5:03 PM, Caleb C. <removed_email_address@domain.invalid>
wrote:

> def foo big,
>         list,
>         of,
>         args
>
>   some.stuff
>   some.stuff
>   some.stuff


So then that means the common indentataion of:

def foo
  bar
rescue
   0

would also break?   Just how many examples of problems do people need
here? :)
Eleanor McHugh (Guest)
on 2009-05-29 10:26
(Received via mailing list)
On 28 May 2009, at 19:55, Juan Z. wrote:
> Terseness is a perfectly reasonable goal.  It's a corollary to
> Occam's Razer.
> No?   If you're going to sacrifice conciseness you should have a
> good reason
> for doing so.

Occam's law applies to theory formation, not to literate exposition.
When writing code I'd rather err on the side of verbosity if that
expresses my model well to those who lack my implicit knowledge, than
terse and incomprehensible to anyone except myself.

>>
>> There is value in redundancy, and the trick is to find the right
>> balance, not to eliminate it completely.
>
> Exactly.  So there should be a choice.  Right?

There is. It's called Python, and as its proponents frequently inform
me it's every bit as powerful as Ruby.

>>    want to do this.
>>
>>    This is a powerful option.
>>
> It's possible to do this too.  Is it not?

And how do you embody syntactic rules for coping with such custom
indenting when the whole point is that they're both exceptional and
aesthetic in nature?


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
Reid T. (Guest)
on 2009-05-29 11:02
(Received via mailing list)
Caleb C. wrote:
If you'd wanted to indent less than the surrounding code,
>
>>                     :c => 3, :d => 4)
>>
>>
>> end
>
>
This would kill me.  I utilize temporary code all the time starting in
column 0
so that it will be easy to find and pull back out
Eleanor McHugh (Guest)
on 2009-05-29 11:04
(Received via mailing list)
On 28 May 2009, at 21:40, J Haas wrote:
> On May 28, 1:36 pm, Rimantas L. <removed_email_address@domain.invalid> wrote:
>>> Have you noticed that your post is broken into paragraphs, and those
>>> paragraphs are delimited solely by whitespace, and this does not
>>> impair readability?
>>
>> Do you know many other ways to break the text into paragraph?
>
> Yes. You could be required to type 'end' at the end of every
> paragraph. But that'd just be silly and redundant, considering that
> whitespace does a perfectly good job as a delimiter.

The only significant whitespace in paragraph delineation is a new
line, which funnily enough is also significant white space in Ruby.
The sentences within each paragraph are delineated with full stops and
other punctuation marks which are themselves meaningful. Whilst we
could probably abolish these and use indentation instead to group
sentences into paragraphs and sub-clauses into sentences, I'm not
currently aware of any natural language notation system which adopts
this approach.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
Juan Z. (Guest)
on 2009-05-29 11:18
(Received via mailing list)
On May 28, 2009, at 5:20 PM, Eleanor McHugh wrote:

> than terse and incomprehensible to anyone except myself.
I'd be careful about making such a narrow definition of the "law of
succinctness."   I'd also be careful about trying to twist the
definition of
terse towards meaning incomprehensible.   A part of the definition of
terse is
"easy to read."

You can choose whatever word you want to describe conciseness, but
most of them
imply or directly state clearness or an ease of understanding not
compromised
by beating around the bush or cluttering things up.  You can choose a
near
synonym for concise that sometimes has a sense of impoliteness to make
concise
look negative, but the fact is the computer doesn't care.

Trying to argue that longer is somehow inherently better doesn't make
any
sense.  If you really feel that way then Ruby is a poor choice
considering how
many wonderfully tedious languages there are just filled with
redundancy and
unnecessary syntax.   How about Java's long winded forced naming
conventions?
Or better yet how about C++ templates for readability? There's just a
ton of
information about every last detail concerning types and all kinds of
stuff and
lots of redundancy.  Certainly that is wonderfully readable compared
to Ruby.

Seriously, if you want to argue some other point about implementation
details
or some implication of a particular solution well then that's fair
game.   But
you're not going to get anywhere arguing that longer is better or
telling
people to go away and use some other language.
J Haas (Guest)
on 2009-05-29 11:34
(Received via mailing list)
> So then that means the common indentataion of:
>
> def foo
>   bar
> rescue
>    0
>
> would also break?  

I don't know if it works in Caleb's script, but this need not cause
any problems in a proper implementation of syntactic indentation, any
more than:

case foo:
  when 'bar'
    do_something
  when 'baz'
    do_something else

would, or for that matter

begin:
  do_something
rescue
  do_something_else

Certain keywords (like 'when' or 'else' or 'rescue') don't start new
blocks that need 'end' to close them, and they can safely be placed at
the same level of indentation as the blocks which must precede them.

> Just how many examples of problems do people need here? :)

One would be nice. Please, do try to make it a problem severe enough
to justify inflating the line count 20% or more, and also so critical
that people shouldn't even have the _option_ to use syntactic
indentation.
Eleanor McHugh (Guest)
on 2009-05-29 11:39
(Received via mailing list)
On 28 May 2009, at 23:06, Juan Z. wrote:
>> verbosity if that expresses my model well to those who lack my
>> implicit knowledge, than terse and incomprehensible to anyone
>> except myself.
>
> I'd be careful about making such a narrow definition of the "law of
> succinctness."   I'd also be careful about trying to twist the
> definition of
> terse towards meaning incomprehensible.   A part of the definition
> of terse is
> "easy to read."

As with most things in life, whether or not something is "easy to
read" depends upon your frame of reference. What makes perfect sense
to you today may not at a later date, and may never make sense to
someone else. That's why I mentioned implicit knowledge, a commodity
which is present in all skills and that by its nature is hard to
transmit because those who possess it are largely unaware of its
existence.

> You can choose whatever word you want to describe conciseness, but
> most of them
> imply or directly state clearness or an ease of understanding not
> compromised
> by beating around the bush or cluttering things up.  You can choose
> a near
> synonym for concise that sometimes has a sense of impoliteness to
> make concise
> look negative, but the fact is the computer doesn't care.

No, the computer doesn't care and is quite happy to be programmed in
its own binary language - just a stream of 1s and 0s. However the
history of language design has been to move away from direct machine
notation (which is tedious and error prone), co-opting syntactic and
semantic features from natural languages. This makes good sense as
code has to be designed and maintained by people who in general have a
higher facility with natural language than they do with machine code.
And one of the interesting things about natural language is that it's
not indentation sensitive.

> Trying to argue that longer is somehow inherently better doesn't
> make any
> sense.

You clearly haven't spent much time trying to maintain extremely terse
C or you'd have quite a different perspective.

> to Ruby.
There are two kinds of redundancy. That which comes from cut-and-paste
and is a code smell, and that which exists as a structural safeguard.
'end' is the latter kind of redundancy and whether you like it or not
many of us find that supposed lack of conciseness to be a concise
representation of block identity.

> Seriously, if you want to argue some other point about
> implementation details
> or some implication of a particular solution well then that's fair
> game.   But
> you're not going to get anywhere arguing that longer is better or
> telling
> people to go away and use some other language.

And you're not going to get anywhere by acting as if significant
indentation is a must-have for Ruby or any other language.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
Gregory B. (Guest)
on 2009-05-29 11:54
(Received via mailing list)
On Thu, May 28, 2009 at 7:00 PM, J Haas <removed_email_address@domain.invalid> 
wrote:

> One would be nice. Please, do try to make it a problem severe enough
> to justify inflating the line count 20% or more, and also so critical
> that people shouldn't even have the _option_ to use syntactic
> indentation.

Did I ever, at any point in this thread, suggest anything at all about
not having the option?
Or did I respond to your initial post nearly as soon as you wrote it
saying "Implement it and see if people like it".
Or did I say "I have no preference about significant whitespace"?

Seriously, you're doing something very harmful by continuing to treat
people this way.  You are discounting absolutely everything everyone
says and you're taking things out of context.  Please stop.   Please
unsubscribe if that's the only way you can manage to stop yourself.

-greg
Michael Bruschkewitz (Guest)
on 2009-05-29 13:00
(Received via mailing list)
"Reid T." <removed_email_address@domain.invalid> schrieb im Newsbeitrag
news:removed_email_address@domain.invalid...
> Michael Bruschkewitz wrote:
>>
>
>> If it would be strictly optional it would be fine.
>> Should be need to be explicitely allowed for not breaking existent code.
>> Maybe as gem possible.
>
> There's no way it could be *strictly* optional.

I dont really understand this sentence (too much indirection - I'm
german
and I'm tired...) Did you mean "It must be strictly optional" ?

> Unless you provide some way for
> persons that want code block ends to automatically convert code without
> ends to
> code with ends.
>

Maybe any code in any language should be stored in some generic form
meta
language (we would have enough space to store it now - car crysis left
enough oil to create magnetic tapes) and the _Editor_ provides the view
which best fits to the current developer. (Example: translate keyword to
japanese signs, direction of writing a.s.o.)
Editor could also apply current coding rules. The would increase code
safety
and security, and efficiency. It would even allow GUI's for creating
code
from/by Flowcharts.

I'm really serious.
This would be really a revolutionary improvement. (Removing most reasons
for
current holy wars and create a huge field for new, interesting ones.)
But these backbone language would not be Ruby.

Also, IMHO, PyI wouldt break principle of least surprise.

At breakfast I had the idea it would be possible to implement/apply it
to
current file it by simply using
"require 'tool4endH8ers.rb'" or
"require 'languageConverter_pyi.rb'" or
"require 'languageConverter_BASIC.rb'" or
"require 'languageConverter_f77.rb'" or...
"require 'applySomeOtherWeirdOptions.rb'" or...
at the beginning of each file or at the beginning of main file.
I'm sure some Kernel.magic would make this possible.

Why not think about providing a mechanism which provides this
possibility?

Regards,
Michael B.
Caleb C. (Guest)
on 2009-05-29 13:10
(Received via mailing list)
On 5/28/09, J Haas <removed_email_address@domain.invalid> wrote:
> any problems in a proper implementation of syntactic indentation, any
> more than:

Indeed. rescue, when, else, elsif, and ensure are special-cased. If
they occur on the beginning of a line with the same indentation level
as the last line with a beginword, an extra end is not inserted.
Juan Z. (Guest)
on 2009-05-29 13:11
(Received via mailing list)
>>
> And you're not going to get anywhere by acting as if significant
> indentation is a must-have for Ruby or any other language.

I never said it was.  In fact, in my response to you I didn't mention
significant indentation at all.  I disagreed with the current anti-
conciseness arguments.   I suggested that if you want to argue against
a language feature then you need stronger arguments than terse is hard
to read.    Possibly the problem is the term terse is being used
incorrectly.  It doesn't mean hard to read.   Terse may mean "smoothly
elegant, neat, clean, easy to understand, or even brusque.  But it
doesn't mean hard to read.

I'm perfectly happy if you have good arguments against any particular
language feature including significant indentation.   I'll be happy to
agree with your criticisms If I can find some validity in them.   I
don't own stock in any language features.

I am a bit intrigued by these indentation ideas though.  In both human
and computer languages we tend to shorten things that we use often --
even if it makes them irregular.    The 'end' word is one of the most
common things in Ruby.  Possibly the most common line in Ruby contains
nothing but 'end'.  It's perfectly reasonable to think about the
possibility of shortening it.
James B. (Guest)
on 2009-05-29 13:18
(Received via mailing list)
Caleb C. wrote:

> ...
> This (and your other, similar example) actually works in endless.rb
> right now. Leave off the end and it inserts one for you, just where
> you'd expect. You can always indent things more than necessary, and
> that's fine.


Interesting.  Thanks!




James
Gregory B. (Guest)
on 2009-05-29 13:21
(Received via mailing list)
On Thu, May 28, 2009 at 8:38 PM, Caleb C. <removed_email_address@domain.invalid>
wrote:
>> I don't know if it works in Caleb's script, but this need not cause
>> any problems in a proper implementation of syntactic indentation, any
>> more than:
>
> Indeed. rescue, when, else, elsif, and ensure are special-cased. If
> they occur on the beginning of a line with the same indentation level
> as the last line with a beginword, an extra end is not inserted.

Caleb, have you thought about toying around with forking Ruby and
invoking your pre-processor automatically in some way?   I think
that'd turn this conversation into something much more productive.

Even if it's not a realistic implementation at first, it could lead to
productive discussion on how it could be integrated, and what
syntactic changes it would need to make Matz happy.

-greg
James B. (Guest)
on 2009-05-29 13:57
(Received via mailing list)
Juan Z. wrote:

>
> Trying to argue that longer is somehow inherently better doesn't make any
> sense.

Same holds for the inverse. But no one has been arguing that longer is
inherently better.

My point is that zero entropy and  maximal information is a poor goal
when targeting people, that some amount of redundancy reduces errors and
improves communication (again, for people).

I do not have any objective way to say what, exactly, that is for a
programming language.  My own experience from working with indentation
sensitive languages is that the trade-offs do not always sit well with
me.   Nor does the verbosity of Java

My experience with Haskell has been much different than my attempts at
Python.  Maybe it's Haskell's emphasis on mathematical functions, on
using a format that employs (so it seems) a whole lot of equal signs.
The use of white space there feels much more natural than it did for me
with Python.  (I also think Haskell induces different expectations about
what things should look like. It would probably feel wrong to use do/end
for something that is essentially mathematics.)

The information provided by significant indentation,  while usable (and
possibly more efficient for some cases of human parsing), introduces
restrictions on how it may be used elsewhere, effectively limiting how a
writer expresses non-syntactical information in a program.

What puts me off so many discussions about code formatting is the idea
that code is first meant to provide instructions to a machine, and ideas
for people second.

The "machines first" attitude may be the reason for so much cruft in
Java.  I'm sure GvR had "people first" in mind when opting for
significant indentation, but perhaps he viewed writing software as
primarily an exercise in generating code, less as writing a document for
other humans that is also machine readable.  That is, the goal was
highly-readable computer expressions, not machine-readable people
expressions.


--
James B.

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
Juan Z. (Guest)
on 2009-05-29 14:52
(Received via mailing list)
On May 28, 2009, at 9:26 PM, James B. wrote:

> Juan Z. wrote:
>
>> Trying to argue that longer is somehow inherently better doesn't
>> make any
>> sense.
>
> Same holds for the inverse. But no one has been arguing that longer
> is inherently better.

Well, maybe we'll just have to agree to disagree on that one.  Shorter
is better to the degree that nothing is harmed by doing so.  If
significant indentation sufficiently harms something else then I agree
that is important too.
>
>
> My point is that zero entropy and  maximal information is a poor
> goal when targeting people, that some amount of redundancy reduces
> errors and improves communication (again, for people).
There is a well known and written about principle of economy that
applies universally to human languages.   If we're talking about
shortening everything then I'd agree with you completely.   But when
something is really common we alter the language to make it shorter.
An entire line occupied only by the word 'end' is one of if not the
most common line in Ruby.   That makes it a great candidate for
applying a principle of economy.
>
> I do not have any objective way to say what, exactly, that is for a
> programming language.  My own experience from working with
> indentation sensitive languages is that the trade-offs do not always
> sit well with me.   Nor does the verbosity of Java
The commonness of the occurrence is one key factor.  All those
needless semicolons in Java, for example.
>
>
> The information provided by significant indentation,  while usable
> (and possibly more efficient for some cases of human parsing),
> introduces restrictions on how it may be used elsewhere, effectively
> limiting how a writer expresses non-syntactical information in a
> program.
Well that could be a good argument against.  I'm not familiar enough
with such counter examples to say.  So far I've
been pretty impressed with what Caleb's tool can do.
> for other humans that is also machine readable.  That is, the goal
> was highly-readable computer expressions, not machine-readable
> people expressions.
I agree with you.  Java advocates I know will claim that static typing
is worth the added redundancy and verbosity because it reduces the
chance of type errors and provides structure.  They don't believe that
you can have industrial strength applications without it.   Sound
familiar?

My own guess is that static typing currently provides an efficiency
advantage that isn't yet available in most dynamic languages.
Actually, I've heard that Sun's JVM now throws away static type
information anyway.   It would be interesting to know more about that.

I write way too much Java.  I've been pretty disappointed that it
seems to be getting more verbose and less expressive for reason that
at this point still don't make much sense to me.  JRuby is a breath of
fresh air.
Reid T. (Guest)
on 2009-05-29 19:08
(Received via mailing list)
On Fri, 2009-05-29 at 17:56 +0900, Michael Bruschkewitz wrote:
>
> I dont really understand this sentence (too much indirection - I'm german
> and I'm tired...) Did you mean "It must be strictly optional" ?
What I mean is..
if endless ruby code is allowed, it cannot be strictly optional.  If a
core class or any other class/project that you utilize is coded without
ends, then you get endless ruby whether you want it or not.
Gregory B. (Guest)
on 2009-05-29 19:17
(Received via mailing list)
On Thu, May 28, 2009 at 6:06 PM, Juan Z. <removed_email_address@domain.invalid>
wrote:
>
> On May 28, 2009, at 5:20 PM, Eleanor McHugh wrote:
>
>> On 28 May 2009, at 19:55, Juan Z. wrote:

> Seriously, if you want to argue some other point about implementation
> details
> or some implication of a particular solution well then that's fair game.
> But
> you're not going to get anywhere arguing that longer is better or telling
> people to go away and use some other language.

And you're not going to get anywhere being a giant douche.  Or maybe
you think that (almost) everyone else in this thread is to blame.
Juan Z. (Guest)
on 2009-05-29 21:17
(Received via mailing list)
On May 28, 2009, at 6:11 PM, Gregory B. wrote:

>> game.
>> But
>> you're not going to get anywhere arguing that longer is better or
>> telling
>> people to go away and use some other language.
>
> And you're not going to get anywhere being a giant douche.  Or maybe
> you think that (almost) everyone else in this thread is to blame.

Is there a way to block users on this group who use vulgar language
with intent to offend?
Gregory B. (Guest)
on 2009-05-29 21:25
(Received via mailing list)
On Thu, May 28, 2009 at 8:14 PM, Juan Z. <removed_email_address@domain.invalid>
wrote:

> Is there a way to block users on this group who use vulgar language with
> intent to offend?

The same way you block users with intent to offend (or not) who do not
use vulgar language, with a kill-file in your mail client.   Another
way to avoid such discourse is to not act like a troll with no respect
for the other members of this list.

-greg
Caleb C. (Guest)
on 2009-05-29 21:30
(Received via mailing list)
On 5/28/09, Gregory B. <removed_email_address@domain.invalid> wrote:
> Caleb, have you thought about toying around with forking Ruby and
> invoking your pre-processor automatically in some way?   I think
> that'd turn this conversation into something much more productive.

It wouldn't be very hard, but that's more effort than I want to put
into it right now.

> Even if it's not a realistic implementation at first, it could lead to
> productive discussion on how it could be integrated, and what
> syntactic changes it would need to make Matz happy.

I made it to prove a point, and I feel  what I've done now is a
sufficient proof that it can be done, without buggy regex hackery, or
particular difficulty (given you have an already working lexer) and
the result can have very clean syntax.
Michael Bruschkewitz (Guest)
on 2009-05-29 21:32
(Received via mailing list)
"Gregory B." <removed_email_address@domain.invalid> schrieb im Newsbeitrag
news:removed_email_address@domain.invalid...
>
> -greg
>

Offender may have some problems staying kind and friendly.
People feeling offended have problems beeing tolerant.
(They should just skip the post when tolerance limit is reached.)
It is the same sort of social disability.

Some offendings may come from in-familiarity to english language or
cultural
differences.
Never offer left hand to muslims, for example. I had absolutely no idea
about this problem until I read/heard about real reason.

In this NG we should concentrae on language issues.

Best Regards,
Michael B.
Juan Z. (Guest)
on 2009-05-29 21:48
(Received via mailing list)
On May 29, 2009, at 5:00 AM, Michael Bruschkewitz wrote:

>> The same way you block users with intent to offend (or not) who do
> People feeling offended have problems beeing tolerant.
> (They should just skip the post when tolerance limit is reached.)
> It is the same sort of social disability.
>
> Some offendings may come from in-familiarity to english language or
> cultural differences.
> Never offer left hand to muslims, for example. I had absolutely no
> idea about this problem until I read/heard about real reason.
>
> In this NG we should concentrae on language issues.

It's impossible to never offend.  You can't please everybody all the
time as they say.  But in this case
there was no language misunderstanding.   The poster's intent was
specifically to be vulgar and offensive.  It's perfectly reasonable to
reject abusive behavior.
Gregory B. (Guest)
on 2009-05-29 22:11
(Received via mailing list)
On Fri, May 29, 2009 at 9:34 AM, Juan Z. <removed_email_address@domain.invalid>
wrote:

> It's impossible to never offend.  You can't please everybody all the time as
> they say.  But in this case
> there was no language misunderstanding.   The poster's intent was
> specifically to be vulgar and offensive.  It's perfectly reasonable to
> reject abusive behavior.

In all seriousness, I've found your behavior on this list abusive, and
I was venting my frustration.   I should have done that in a private
mail, but please do not push this issue and make it sound like I'm the
source of great pain and suffering here.

People only need to search the archives to see what my contributions
to this list have been like.

-greg
Michael Bruschkewitz (Guest)
on 2009-05-29 22:14
(Received via mailing list)
>"Juan Z." <removed_email_address@domain.invalid> schrieb im Newsbeitrag
>news:removed_email_address@domain.invalid...
> It's impossible to never offend.  You can't please everybody all the
> time as they say.  But in this case
> there was no language misunderstanding.   The poster's intent was
> specifically to be vulgar and offensive.  It's perfectly reasonable to
> reject abusive behavior.

Maybe it was just a very special try of being funny?

If somebody is really vulgar and offensive, he dis-qualifies himself.
IMHO, more than a *shrug* and ignore offensive wording would not be
appropriate.
There is no need for guards of morale in NG if everybody (who is
possible to
do that) tries to remain calm.

I, personally, prefer people calling me asshole to friendly stupids.

Let's stop wasting our resources.
Gregory B. (Guest)
on 2009-05-29 23:16
(Received via mailing list)
On Fri, May 29, 2009 at 1:24 PM, Caleb C. <removed_email_address@domain.invalid>
wrote:

> I made it to prove a point, and I feel  what I've done now is a
> sufficient proof that it can be done, without buggy regex hackery, or
> particular difficulty (given you have an already working lexer) and
> the result can have very clean syntax.

Yeah, that was very surprising.  Good work on that man, hopefully
it'll be put to good use, but anyway, it's nice to see the idea tried
out.

-greg
Robert H. (Guest)
on 2009-05-30 01:21
> Maybe it was just a very special try of being funny?

Whoever wrote it can clear this up easily by stating what his intention
was.

Personally, my experience was that sarcasm or irony often does not bode
well in written text. Additionally, often people assume that something
is insulting or otherwise harmful against them - written text is often
limited in expressing human *intentions*. Or, some people have a hard
time expressing their thoughts.

But anyway, let's jump to the proposal again (and we can see that this
generated quite a stir... huge huge huge here hehe.)

I dont want to write too much, so I try to be short and concise:

- Personally, i think it *would* be nice to omit "end" and have my code
still work. I do indent my code already with two spaces all the time for
every meaningful code block anyway. Those "end's" aren't really helpful
for my eyes.

- I do however not have a serious problem with that. It would be nice,
but it is nothing where I would say "ruby sucks" because I cant omit
ends. To me, it is not really important.

- As far as language design is concerned, I personally think it is not
elegant if a parser bothers too much about meaningful indent. Instead, I
think a parser should try to capture the INTENT of the programmer, and
it is stupid if a parser stops working because the INDENT was wrong. It
just strikes me as inelegant - and keep in mind that I said, I wouldn't
mind to omit end at all.
I found it silly to not be able to just paste code into the interactive
python shell, and have it work. It complained about whitespace crap, and
I found this insulting. I think the best way would be for a parser who
could allow for both, with "end" being the default, but a switch which
could allow for a shorter ruby-like syntax where one can omit "end".

- I think python has one solid argument going for it (and please also
keep in mind that I hate other python choices, especially the __foo__():
part. That includes the ':' in there as well) - whitespace and
homogeneous structure would be something _I_ would appreciate. I love
ruby's flexibility, but I would also love to have something
super-concise AND homogeneous. And more readable, IMHO, too.

- As written above, I have one problem with the python whitespace. And
this is the ':' part. I hate that.

'if foo:'

I do NOT want to get rid of "end" in ruby, if that means introducing
something like ':'. The ':' is not beautiful at all, and thus it would
not be a real improvement for me, if I have to clutter my code with ':'.

- I do not think that you applied the DRY statement correctly, because
DRY applies for code logic primarily, not for satisfying a parser. And
the "end" is there because of the parser.


> Programmers shouldn't be using freakin' tabs anyway,
> and if they are, they _definitely_ shouldn't be mixing them with spaces.

Personally I used to like tabs, and reasoned that people could set their
tabs width to whatever they like. But then I realized that i do comment
my own code a lot, and suddenly I was mixing tabs with spaces.

I stopped at that very day, and used 2 spaces (2, because I usually like
to have 80 chars per line, and not more. I am that old, really. I like
80 chars per line, even though i sometimes use more than that - i think
it is a good general rule of thumb to cut down below 80 chars / line,
and with 4 spaces i just hit that threshold sooner)


Anyway, I think this is all mostly just happy discussing here. Ruby is
the way it is, and to change something as fundamental as indent is way
too difficult and probably has no huge gain whatsoever. Didn't Guido
once say that, if he could switch one thing in python, he would no
longer use significant whitespace?
Eleanor McHugh (Guest)
on 2009-05-30 01:44
(Received via mailing list)
On 28 May 2009, at 22:22, Juan Z. wrote:
> On May 28, 2009, at 10:00 PM, Michael Bruschkewitz wrote:
>> Did somebody tried Brainf*ck language?
> Now there's a readable language!

INTERCAL's where the action's really at lol


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
Michael Bruschkewitz (Guest)
on 2009-05-30 01:51
(Received via mailing list)
"Reid T." <removed_email_address@domain.invalid> schrieb im Newsbeitrag
news:removed_email_address@domain.invalid...
> What I mean is..
> if endless ruby code is allowed, it cannot be strictly optional.  If a
> core class or any other class/project that you utilize is coded without
> ends, then you get endless ruby whether you want it or not.

For this reason, wouldn't it be possible to add an "option"-parameter to
"require"?
Eleanor McHugh (Guest)
on 2009-05-30 01:55
(Received via mailing list)
On 28 May 2009, at 22:47, Reid T. wrote:
> This would kill me.  I utilize temporary code all the time starting
> in column 0 so that it will be easy to find and pull back out

It's an old and well-established practice that I'm also guilty of most
days of the week :)


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
Eleanor McHugh (Guest)
on 2009-05-30 03:38
(Received via mailing list)
On 28 May 2009, at 20:41, Juan Z. wrote:
> Terse may mean "smoothly elegant, neat, clean, easy to understand,
> or even brusque.  But it doesn't mean hard to read.

We may well be separated by a common language. It's unusual here in
the UK for anyone to use the word 'terse' without meaning brusque with
a tendency to rudeness, and when applied to code it's common currency
for "reads like obfuscated C".

> about the possibility of shortening it.
True. But removing it altogether isn't the same as abbreviating it
(even txtspk leaves *some* of the characters in words to convey
meaning).


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
James B. (Guest)
on 2009-05-30 04:15
(Received via mailing list)
Gregory B. wrote:

>
> In all seriousness, I've found your behavior on this list abusive, and
> I was venting my frustration.   I should have done that in a private
> mail, but please do not push this issue and make it sound like I'm the
> source of great pain and suffering here.
>
> People only need to search the archives to see what my contributions
> to this list have been like.
>

Exactly true.

I'm offended by anyone trying to make Greg out to be some sort of
willfully and routinely vulgar troll.

His contributions to Ruby have been amazing, and I'm more than willing
to cut him whatever slack he needs.

Maybe some reflection on what might provoke someone such as Greg to
respond like that is more in order.


--
James B.

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
Reid T. (Guest)
on 2009-05-30 07:04
(Received via mailing list)
Eleanor McHugh wrote:
> Eleanor McHugh
> Games With Brains
> http://slides.games-with-brains.net
> ----
> raise ArgumentError unless @reality.responds_to? :reason
>
>
for some really significant whitespace..

http://compsoc.dur.ac.uk/whitespace/
Eleanor McHugh (Guest)
on 2009-05-30 08:48
(Received via mailing list)
On 29 May 2009, at 20:14, James B. wrote:
> Exactly true.
>
> I'm offended by anyone trying to make Greg out to be some sort of
> willfully and routinely vulgar troll.
>
> His contributions to Ruby have been amazing, and I'm more than
> willing to cut him whatever slack he needs.
>
> Maybe some reflection on what might provoke someone such as Greg to
> respond like that is more in order.

I felt that way when Tony had his outburst. I can't recall ever seeing
this extremity of reaction in a thread on ruby-talk in the years I've
been subscribed, and it either means that there's something
fundamental about this topic that pushes our buttons or that there was
something about the way it was presented that did likewise. Clearly a
raw nerve has been touched either way.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
Tony A. (Guest)
on 2009-05-30 11:38
(Received via mailing list)
On Fri, May 29, 2009 at 10:47 PM, Eleanor McHugh <
removed_email_address@domain.invalid> wrote:

> I felt that way when Tony had his outburst. I can't recall ever seeing this
> extremity of reaction in a thread on ruby-talk in the years I've been
> subscribed, and it either means that there's something fundamental about
> this topic that pushes our buttons or that there was something about the way
> it was presented that did likewise. Clearly a raw nerve has been touched
> either way.


There's nothing about the topic that pushes buttons for me.  I tried to
make
a Ruby-like language with a Pythonic lexer handling indentation
sensitivity.  I gave up, and in the end I think keeping the "end" token
was
the right decision.

But after painstakingly detailing the problems of doing this with a
Pythonic
lexer/grammar, and suggesting a Haskell-style lexer/grammar, I was
instead
strawmanned with claims that it's "impossible" and a bunch of personal
attacks from J Haas.  The guy was basically being a little twat, and all
he
had to offer was some script he didn't write that did some very much
informal and complicated regex munging to back up his claims.

It has been interesting to see the alternantive formally decidable
solutions
proposed here for the lexer, and I'm interested in possibly
incorporating
them into Reia.  In fact I'd be interested in a better description of
the
lexer behavior, although I see it's been released so I suppose I could
always check out the source myself.

That said restoring indentation sensitivity is rather low on my list of
priorities.
Roger P. (Guest)
on 2009-05-30 16:57
> What I mean is..
> if endless ruby code is allowed, it cannot be strictly optional.  If a
> core class or any other class/project that you utilize is coded without
> ends, then you get endless ruby whether you want it or not.

I think core classes will take a long time before any would be written
in endless style, so till then it could be optional.  Or did I
misunderstand?
That being said, if there were an endless gem then gems that are written
in endless could just depend on it. Thank you to the gems devs.
-=r
rzed (Guest)
on 2009-05-30 17:10
(Received via mailing list)
Caleb C. <removed_email_address@domain.invalid> wrote in
news:removed_email_address@domain.invalid:

> That script is a hack, however, since it doesn't lex its input
>     do_something
>   end until done?
> (However, you'd better make damn sure you get the end indented to
> the right level!)

If I'm reading this right, given
x.foreach ...
  if ...
    while ...
      do_something
something_else

... would pop an end at the level of the 'while' only. You really
need an end there and at each succeeding dedent level up to the level
of the next statement ('something_else'). Not saying this is
something that should be done, but if it is done, that's what you
need to do.
Roger P. (Guest)
on 2009-05-30 18:00
> If I'm reading this right, given
> x.foreach ...
>   if ...
>     while ...
>       do_something
> something_else
>
> ... would pop an end at the level of the 'while' only. You really
> need an end there and at each succeeding dedent level up to the level
> of the next statement ('something_else'). Not saying this is
> something that should be done, but if it is done, that's what you
> need to do.

Currently that would read
 x.foreach ...
   if ...
     while ...
       do_something
     end
    end
 end
 something_else

I believe.
Which makes me wonder
how does it differentiate between that and

> x.foreach ...
>   if ...
>     while ...
>       do_something
> .something_else

becoming

 x.foreach ...
   if ...
     while ...
       do_something
     end
    end
 end.something_else

is the "." special case?
-=r
Caleb C. (Guest)
on 2009-05-30 20:42
(Received via mailing list)
On 5/30/09, Tony A. <removed_email_address@domain.invalid> wrote:
> had to offer was some script he didn't write that did some very much
> informal and complicated regex munging to back up his claims.
>
> It has been interesting to see the alternantive formally decidable solutions
> proposed here for the lexer, and I'm interested in possibly incorporating

It's curious to me that you use phrases like 'formally decidable'. I'm
not sure this is really the best description. To my mind, the output
of pyrb.rb was perfectly decidable, and it was equally clear that it
had bugs. Fundamental bugs, that could be chased around but not really
fixed except by complete rewrite. It's a buggy approach because it
doesn't do what you're supposed to do in that kind of automatic
munger: actually tokenize the input stream.

Examples:

  begin # :
     foo
     bar
     baz

  begin p ":
    some more string here"
    foo
    bar

> them into Reia.  In fact I'd be interested in a better description of the
> lexer behavior, although I see it's been released so I suppose I could
> always check out the source myself.

RubyLexer is large and ugly, so I don't envy anyone trying to review
it. It's organized in a straightforward imperative manner, which is
the problem; hand-coded lexers are painful. Also, ruby syntax is very
complicated. If you want to know about something more specific about
its internals, please ask me.
Caleb C. (Guest)
on 2009-05-30 20:45
(Received via mailing list)
On 5/30/09, rzed <removed_email_address@domain.invalid> wrote:
>       do_something
> something_else
>
> ... would pop an end at the level of the 'while' only. You really

I guess you're reading it right, but I didn't write it right.
Endless.rb in fact does operate in the way you want; all three
constructs would be ended. But I see now that my description implies
only one end will be added.

Roger P. wrote:
>
>  x.foreach ...
>   if ...
>     while ...
>       do_something
>     end
>    end
>  end.something_else
>
> is the "." special case?

Currently, this case causes an error in endless.rb. It runs through
endless.rb just fine, but the output isn't legal ruby. Every end added
is followed by a semicolon.
Michael S. (Guest)
on 2009-05-30 21:35
(Received via mailing list)
On Wed, May 20, 2009 at 06:40:02AM +0900, J Haas wrote:
> Greetings, folks. First time poster

Last time I read ruby-talk@ via spambox was the tail of a similar
thread -- first-time poster wondering about python-like
whitespace semantics in Ruby, although *somewhat* less eager
to do his homework IIRC :-)

> But I digress... the purpose of this post is to talk about one
> of the relatively few areas where I think Python beats Ruby,
> and that's syntatically- significant indentation.

Well, guess you knew [most of] the answers in advance...

I for one do avoid Python for several reasons (thoroughly
as a sorta-developer and somewhat less so as a packager
for ALT Linux distribution).

Number one of them is immaturity of upstream management
(at least relatively to the popularity; think PHP).

Number two is that it's not up to people to use machines to push
their image of taste down someone else's throat.

And if I'd *have* to choose between Guido's one and Matz's style
of educating people with development tools, I'd still land here.

Fortunately we do have choice, and there are other languages
borrowing from both Python and Ruby as well.

Regarding "not DRY", but is it better to be dry?  Sometimes it's
just time to stop, think a bit and write: "end".  And continue. :)
Steven A. (Guest)
on 2009-05-30 23:05
(Received via mailing list)
After listening to this debate for some time, the position of allowing
optional Pythonic indentation seems increasingly persuasive.

First, no one is proposing to eliminate "end".  The "end" keyword can
still be used just as it always was. If we adopt J. Haas' proposal
that indentation blocks be demarcated by a colon, as in:

     if x:
         foo

...then the preprocessor can run ALL existing Ruby code unchanged,
even if the "end" keywords are misaligned.  Further, the colon gives a
visual cue that indentation syntax is being employed.  We could
further reduce some of the ambiguity from which Python suffers by, for
example, disallowing tabs as marks of indentation.  Spaces only, please.

Second, the idea that this change would be hard to implement has been
mostly rebutted, in my opinion.  Caleb's code does the job.  Ruby
could be trivially transformed to (a) include the preprocessor, and
(b) run it on Ruby files before processing them -- i.e. before lexing,
parsing, etc.  That would be the dead-easy way to implement this
proposal, requiring very little C.

Third, there is no doubt about the objective fact that Ruby code that
removes optional "end" keywords will be shorter, and I think
practically everyone agrees in principle with the idea that terseness
is a virtue unless there is some specific reason for being redundant.

Fourth, I thought the point was quite persuasive that Ruby also allows
semicolons to be entirely optional except in those specific cases on
the same line where they are needed.  This behavior and philosophy is
exactly analogous to the current proposal.  You could put a semicolon
at the end of every line in Ruby right now, but no one does.  Why
not?  Because they are redundant, because they are visual noise.

The point that has not been so thoroughly deconstructed are all the
possible odd syntactical limitations that might exist if this proposal
were adopted.  For example, I saw someone saying that "end" would not
be allowed inside any block that used indentation.  If this were
really necessary, to me, it would be a point against the significant-
whitespace proposal.  I don't really see why it would be necessary.  I
do see that, for the code to work with Caleb's preprocessor, any "end"
keywords used inside an indented block would themselves need to be
indented properly.  But this is another example of a minor syntactical
"gotcha" that could or would pop up.  How many other such kinks or
gotchas do you suppose there might be, once we delve more deeply into
actual implementation?

Having said that, I think the main problem boils down to aesthetics.
Some people, myself included, would prefer the whitespace-aware option
rather than typing a string of "end" keywords assuming they are
unnecessary.  Others find the "end" keywords to be visually helpful.
To argue against optional removal of "end" is to argue that others
should not be given the choice of removing "end" in their own code.
This position -- denying to others the option of doing things in a way
they prefer -- seems like a hard position to argue for.  However, I
think from the viewpoint of people who do not like significant
whitespace, the problem is that they know that if the proposal were
adopted, sooner or later they will encounter code that is formatted in
this way, and they will then be "forced" to deal with code they find
unpleasant.  In other words, someone will be forced to deal with code
they find difficult to work with, and those who prefer "end," quite
naturally, do not want to have to be the ones to deal with this.

I think in reality, the imposition on those who prefer "end" will be
minor.  All their own code will have "end".  The issue will arise in
situations where for some reason a person who prefers "end" is forced
to maintain code that uses indentation.  This could be exacerbated by,
e.g., a corporate coding standard that requires indentation syntax
wherever possible.  This, I think, is the future that those who like
the "end" keyword are trying to avoid.  If the significance of
whitespace were guaranteed never to be an issue that confronts them,
then I think few people would object to the inclusion of optional
indent-aware syntax.

I don't have an answer to this aesthetic problem, and I don't think
one is possible, since taste is taste and one cannot be argued out of
their preferences.  However, i would say that allowing people to do
things in different ways is part of the spirit and philosophy of
Ruby.  It's not that Ruby seeks to be able to do things in many ways,
but Ruby does make it easy to do things in different ways if those
ways are convenient and desirable to a substantial number of people --
e.g., curly brackets versus do..end, aliases, << versus insert, etc.
Also, making redundant syntax optional, e.g. semicolon, is, IMO,
entirely within the spirit and philosophy of Ruby.  It's hard to
understand why Ruby would allow semicolons to be optional but not
"end" keywords.

steven
Tony A. (Guest)
on 2009-05-30 23:22
(Received via mailing list)
On Sat, May 30, 2009 at 1:03 PM, Steven Arnold
<removed_email_address@domain.invalid>wrote:

> After listening to this debate for some time, the position of allowing
> optional Pythonic indentation seems increasingly persuasive.
>

That said, "optional Pythonic indentation" seems like a bit of a
misnomer in
this case.  This approach works a lot more like Haskell where indent
blocks
can be used in lieu of explicit delimiting tokens, however it is not
mandatory as is the case in Python.
Roger P. (Guest)
on 2009-05-30 23:48
> ...then the preprocessor can run ALL existing Ruby code unchanged,
> even if the "end" keywords are misaligned.

The preprocess could run all code that had misaligned end keywords,
however, it would break on things like
x = ":
 a string!"

Caleb's wouldn't, though (and also doesn't have the added :'s)

The thought would be that code written in endless "wouldn't have
misaligned end keywords."

Note also that ruby 1.9 if you pass it "-w" already somewhat tracks
alignment, if that's helpful at all.

> Further, the colon gives a
> visual cue that indentation syntax is being employed.  We could
> further reduce some of the ambiguity from which Python suffers by, for
> example, disallowing tabs as marks of indentation.  Spaces only, please.

That's a good idea.

-=r
Rimantas L. (Guest)
on 2009-05-31 00:00
(Received via mailing list)
> Third, there is no doubt about the objective fact that Ruby code that
> removes optional "end" keywords will be shorter, and I think practically
> everyone agrees in principle with the idea that terseness is a virtue unless
> there is some specific reason for being redundant.

No, I don't agree.

> Fourth, I thought the point was quite persuasive that Ruby also allows
> semicolons to be entirely optional except in those specific cases on the
> same line where they are needed.  This behavior and philosophy is exactly
> analogous to the current proposal.  You could put a semicolon at the end of
> every line in Ruby right now, but no one does.  Why not?  Because they are
> redundant, because they are visual noise.

Tracking newlines is easy, tracking indentation is not.

> Having said that, I think the main problem boils down to aesthetics.

No. It boils down to the mess this introduces.
There is Python for those who want Python.

> However, I think from the viewpoint of people who do
> not like significant whitespace, the problem is that they know that if the
> proposal were adopted, sooner or later they will encounter code that is
> formatted in this way, and they will then be "forced" to deal with code they
> find unpleasant.  In other words, someone will be forced to deal with code
> they find difficult to work with, and those who prefer "end," quite
> naturally, do not want to have to be the ones to deal with this.

That's correct.

> I think in reality, the imposition on those who prefer "end" will be minor.

I think otherwise.

> I don't have an answer to this aesthetic problem, and I don't think one is
> possible, since taste is taste and one cannot be argued out of their
> preferences.  However, i would say that allowing people to do things in
> different ways is part of the spirit and philosophy of Ruby.

Yes, please. there are whole languages for that.

>  It's hard to understand why Ruby would allow semicolons to be optional but
> not "end" keywords.

It is very easy to understand.

Regards,
Rimantas
Steven A. (Guest)
on 2009-05-31 00:40
(Received via mailing list)
On May 30, 2009, at 1:51 PM, Rimantas L. wrote:

>> Third, there is no doubt about the objective fact that Ruby code that
>> removes optional "end" keywords will be shorter, and I think
>> practically
>> everyone agrees in principle with the idea that terseness is a
>> virtue unless
>> there is some specific reason for being redundant.
>
> No, I don't agree.

I'm not sure which of these propositions you're disagreeing with.  I
will assume it's the second, since the first seems (to me) to be
virtually unassailable.

On that point, I said "practically everyone" rather than "everyone" to
account for those people who, like you, may not agree that concision
is a virtue.  Note that I also added the disclaimer "unless there is
some specific reason for being redundant."  One such reason that
advocates of "end" have put forward is clarity, and I agree that
clarity is a good reason to be less concise.  The difference of
opinion lies in the question of whether the "ends" make code more or
less clear.  My own feeling is they can sometimes, but for the most
part they just take up space.

> There is Python for those who want Python.

This is a commonly-used, but in my opinion fallacious argument that is
primarily intended to evoke the idea that those who support this
proposal are somehow traitors to Ruby, or not really Rubyists.  It's
the "love-it-or-leave-it" argument.  Any time any language change is
proposed, one could use the same argument: there is
<language_that_contains_feature_x> for those who want feature x.  I
want the Ruby language, but I think it might well be improved by
making a change.

>> naturally, do not want to have to be the ones to deal with this.
>
> That's correct.

Then we agree on the main point.  The nub of opposition is not
technical, but aesthetic dislike of indent-aware syntax, which causes
a fear of having to maintain such code in the future.

steven
James B. (Guest)
on 2009-05-31 08:25
(Received via mailing list)
Steven Arnold wrote:

> Then we agree on the main point.  The nub of opposition is not
> technical, but aesthetic dislike of indent-aware syntax, which causes a
> fear of having to maintain such code in the future.
>

And vice-versa, the current angst in people having to maintain code with
'end', and their fear that they will have to continue doing so in the
future if they cannot get 'end' dropped.

Who knew that programming was so scary?

More significant is that there are some people who may find endless Ruby
more aesthetic, yet still harder to actually work with, and so prefer to
have the extra token.

That is, it is not merely (or even) aesthetics , but, at least for some
people, an empirical problem in easily processing significant
indentation.

Plus there are concerns with editor support (code folding, start/end
block navigation, auto-formatting, ease of cut-n-paste, etc.).

The nubs are many.


--
James B.

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
Michael Bruschkewitz (Guest)
on 2009-05-31 13:25
(Received via mailing list)
"James B." <removed_email_address@domain.invalid> schrieb im Newsbeitrag
news:removed_email_address@domain.invalid...
> Who knew that programming was so scary?


When you start writing life-critical software, you will become scary
some
times.


> More significant is that there are some people who may find endless Ruby
> more aesthetic, yet still harder to actually work with, and so prefer to
> have the extra token.
>
> That is, it is not merely (or even) aesthetics , but, at least for some
> people, an empirical problem in easily processing significant indentation.

More Ruby people probably will find "endless" less "aesthetic".
(Is this really a proper english word? It's really un-aesthetic.)

Even bad "aesthetics" will spoil efficiency and therefore wasting
resources - that's the point where it wastes money - or, at least,
life-time
of developers which should better play with their children than with
whitespaces, tabs or linefeeds.
Michael Bruschkewitz (Guest)
on 2009-05-31 13:32
(Received via mailing list)
"Michael Bruschkewitz" <removed_email_address@domain.invalid>
schrieb im Newsbeitrag
news:2bc66$4a224c65$5b0edd4c$removed_email_address@domain.invalid...

> Even bad "aesthetics" will spoil efficiency and therefore wasting
> resources - that's the point where it wastes money - or, at least,
> life-time of developers which should better play with their children than
> with whitespaces, tabs or linefeeds.
>

P.S. ... or creating new ones! (children)
Michael Bruschkewitz (Guest)
on 2009-05-31 13:35
(Received via mailing list)
> for some really significant whitespace..
>
> http://compsoc.dur.ac.uk/whitespace/

Some more "professional" name and it would be a "must-have" on every
real
programmers CV!
Mark K. (Guest)
on 2009-05-31 18:45
(Received via mailing list)
> Since we're in the realm of the subjective, I don't understand why you
> and others are fighting so hard against having the _option_ of
> syntactic indentation. Why are you so gung-ho on forcing your own
> subjective interpretation of the "right balance" of useless redundancy
> on everyone else?
>
My best guess (and personal reason to be against such an option) is that
it would add complexity to programming and maintaining Ruby code without
actually providing new functionality (it would only add a new syntax
option).

An additional argument could be that Ruby works based on the principle
of least surprise (as Matz intended, please correct me if I am mistaken)
and that having an "end" to end a block of code (or to use {}) is not
very surprising as lots of languages work similarly.

I have not taken a look at Python myself, so I do not know how easy or
hard it would be to program blocks of code based on identation. The idea
does not seem very appealing to me. Even though I always take great care
in properly identing my code, I know lots of other programmers don't and
I would not be very happy if I had to track down their identation errors
all over the place.
Rick D. (Guest)
on 2009-05-31 18:49
(Received via mailing list)
On Sun, May 31, 2009 at 5:35 AM, Michael Bruschkewitz
<removed_email_address@domain.invalid> wrote:
>
>> for some really significant whitespace..
>>
>> http://compsoc.dur.ac.uk/whitespace/

Certainly "endless" and also perfectly "clear". <G>
--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
Mark K. (Guest)
on 2009-05-31 19:01
(Received via mailing list)
Juan Z. wrote:
> And arguably, excluding any discussion of indentation, Ruby is a
> better language.
And as you can see on the same lists the top 5 languages (which includes
PHP, which is the most popular scripting language) all use an "end" or
{} for code blocks. That could be a clear indication that identation is
not the preferred method to define code blocks.

> I'm told that at Google they won't even  let you code in Ruby.   They
> only allow a limited number of popular languages, which includes
> Python but not Ruby.
It makes sense to limit the amount of languages programmed in an
environment, as you need programmers with the appropriate knowledge and
skills to maintain your code. My previous employer did everything in PHP
5. This was not so because it is the best language for every job (it
clearly isn't), but because it was easy to hire and train programmers
with a decent skill level on it and all of the (relatively small)
company's programmers could work on all of the company's code.
Mark K. (Guest)
on 2009-05-31 19:08
(Received via mailing list)
There is simply no perfect programming language. If one would exist it
would be the only programming language and we would all be using it.
Andy F (Guest)
on 2009-06-02 09:20
(Received via mailing list)
> It's hard to understand why Ruby would allow semicolons to be optional but not "end" 
keywords.

There's necessarily a newline where the semicolon would be no? This
makes the ommission of semicolons more of an obvious choice to me than
removing ends.

> My best guess (and personal reason to be against such an option) is that it would add 
complexity
> to programming and maintaining Ruby code without actually providing new functionality 
(it would only
> add a new syntax option).

+1: you don't want to mire the progress of a language by constantly
seeking backward compatibility, but at the same time it seems like a
_lot_ of upheaval for a small change.

> Any time any language change is proposed, one could use the same argument: there is 
<language_that_contains_feature_x>
> for those who want feature x.  I want the Ruby language, but I think it might well be 
improved by making a change.

+1: new to Ruby and the list, so hope I'm not too rude in saying I'm not
impressed with some of the attitudes of 'piss off and use a different
language'. Everything's discussable!

> There is simply no perfect programming language. If one would exist it would be the only 
programming language
> and we would all be using it.

IMHO if that logic was right, then you're effectively saying all
software studios are using the best tools for the job?! Popularity isn't
the gauge of utility.

> Maybe any code in any language should be stored in some generic form meta language (we 
would have enough space to
> store it now - car crysis left enough oil to create magnetic tapes) and the _Editor_ 
provides the view which best fits to the
> current developer. (Example: translate keyword to japanese signs, direction of writing 
a.s.o.)

Love it! Be interested to see anyone playing with that idea in any
language. It'd certainly solve the endless debate.

A.
Eleanor McHugh (Guest)
on 2009-06-02 18:13
(Received via mailing list)
On 2 Jun 2009, at 06:20, Andy F wrote:
> +1: new to Ruby and the list, so hope I'm not too rude in saying I'm
> not impressed with some of the attitudes of 'piss off and use a
> different language'. Everything's discussable!

I'm not going to defend any 'piss off' attitude that may be inferred
from some responses to this discussion, but do bear in mind that on
any mailing list there are discussion topics which have been done to
death in the past and that when they recur the posters responsible
will get short shrift.

It's also incredibly rude for someone to make their first post to a
mailing list with something along the lines of "I'm new to this and
think it's really cool, but you're all dumb because..." which whilst
it isn't a fair characterisation of the original post in this thread
does sum up how some people will have perceived it. Were an
established poster to raise such a topic, having already demonstrated
that they understand the trade-offs in the design of Ruby, the
reaction would be very different - but then again the original post
itself would probably have been phrased very differently as well.

As to this particular topic. Outside the Python and Haskell
communities I've seen very little hunger for significant indentation,
and the benefits are hard to demonstrate as suitably compelling to
outweigh all of the other changes people would like to see in their
language of choice. In the case of the Ruby community the main hunger
seems to be for ever-more-powerful meta-programming techniques and
extension of the higher order functionals that so much of our code
comprises of.

In particular Python developers newly acquainted with Ruby tend to
underestimate the difference between statement-oriented and expression-
oriented languages. In the former a statement is an isolated entity
whereas in the latter every expression returns a value, and therefore
it is thoroughly legitimate to treat that expression as a sub-
expression. Whilst I don't doubt that expression-based languages can
be framed in a manner that is compatible with significant indentation,
in doing so they still need to guarantee maintainability.

Our penchant for a certain variety of meta-programming also makes me
uneasy about significant indentation and whilst that unease may be
misplaced I'm sure it's not an isolated phenomenon. The community
would need to be certain that a change such as significant indentation
didn't undermine either the fundamental ability to use those
techniques nor their maintainability, and in hindsight I think a lot
of the posts opposing such a change - even as an optional feature -
reflect that.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
Robert H. (Guest)
on 2009-06-03 20:30
> there are discussion topics which have been done to
> death in the past and that when they recur the posters
> responsible will get short shrift.

I do disagree with your opinion about this.

There is no "hive opinion". Everyone is an individual.

Some may have this opinion, some may have another opinion.

What you deem "have been done to death in the past" someone
else may regard as a topic that is not finished at all. Why
would they then follow your point of view about this?

I find it prematurely to stifle discussion just because someone
disagrees with something.

> It's also incredibly rude for someone to make their first post to
> a mailing list with something along the lines of "I'm new to this
> and think it's really cool, but you're all dumb because...

I do not think it is "incredibly rude".

Quite the opposite - I believe a healthy community must be able to
attract newbies just as easily, without an arrogant bossy tone to
deem what is rude and what is not. Ideas should be kept in free
flow rather than locked down.

The message is there, it is pointless to use argumentum ad hominem
against someone else just because someone gets mad over written
text.

Let's concentrate on the subject at hand without attacking whoever
voiced a specific opinion. People who do insult others aren't
likely to convince anyone whatsoever anyway. And this subject
seems to alienate people much more readily, in that they say
"i hate this idea", and then defend that point of view, rather
than judging from a neutral POINT of view.

And please:

> In the case of the Ruby community the main hunger
> seems to be for ever-more-powerful meta-programming techniques and
> extension of the higher order functionals that so much of our code
> comprises of.

This speculation should not be done about a whole "community".

Every community consists of individuals, even if they have a very
similar opinion about something, they still may have different
point of views or arguments as to how they reached that point.

It isn't good to unite all point of views into "logical groups".

For example:
So many people equate the Ruby on Rails community with the Ruby
community - but in my experience these two do not largely overlap.
It is simply unfair to attempt to equate different opinions into
one pool. What does "meta-programming" NEED to have to do anything
with indent at all?

Last but not least, the ultimate freedom would be to have the ability
to omit end as an optional feature in ruby available with a default
being the way it currently is.

To switch between indents, one could use #comment marks, like it is
done for the Encoding stuff already (or for vim files etc...)

Enforcement about official ruby stdlib could still follow one specific
guideline - i.e. it must be properly documented and tested, and it must
use "official" useage of end. (This would be an enforcement of a policy,
rather than syntax.)
Tony A. (Guest)
on 2009-06-03 21:57
(Received via mailing list)
On Tue, Jun 2, 2009 at 8:12 AM, Eleanor McHugh <
removed_email_address@domain.invalid> wrote:

> In particular Python developers newly acquainted with Ruby tend to
> underestimate the difference between statement-oriented and
> expression-oriented languages. In the former a statement is an isolated
> entity whereas in the latter every expression returns a value, and therefore
> it is thoroughly legitimate to treat that expression as a sub-expression.
> Whilst I don't doubt that expression-based languages can be framed in a
> manner that is compatible with significant indentation, in doing so they
> still need to guarantee maintainability.


Indeed!  Python's statement structured grammar is essential to the way
it
implements significant indentation.

What I find incredibly curious is people keep equating the solutions
proposed to Python (which has mandatory statement-structured
indentation)
when in actuality they resemble the Haskell approach (optional indent
blocks
in lieu of delimiting tokens in a pure expression grammar)

This is what I was trying to explain at the beginning of the thread (if
you
want significant indentation in Ruby look to Haskell, not Python), but
few
seemed to understand.  The proposed solutions aren't "Pythonic",
they're...
Haskellish?  Or whatever the proper term for that is.
Eleanor McHugh (Guest)
on 2009-06-04 01:16
(Received via mailing list)
On 3 Jun 2009, at 17:30, Marc H. wrote:
> What does "meta-programming" NEED to have to do anything
> with indent at all?

Because if indentation becomes significant it's important that it
doesn't break any central feature of Ruby, and my gut feeling (which I
concede may be totally misguided) is that the area where such breakage
is most likely to occur will be meta-programming. So whilst it may not
have anything to do with the matter at all, determining whether or not
that is the case is still an important consideration. At least for me.

> Last but not least, the ultimate freedom would be to have the ability
> to omit end as an optional feature in ruby available with a default
> being the way it currently is.

I'm not sure that is such an ultimate freedom, but if it is remember
that all freedom comes with responsibility. In this case ensuring code
consistency.

> To switch between indents, one could use #comment marks, like it is
> done for the Encoding stuff already (or for vim files etc...)

Making two distinct structural layouts interchangeable in a single
codebase would make them marginally less readable than sticking to one
or other convention. And as maintenance of code is often orders of
magnitude more expensive than development that difference of
readability equates to a real long-term cost.

> Enforcement about official ruby stdlib could still follow one specific
> guideline - i.e. it must be properly documented and tested, and it
> must
> use "official" useage of end. (This would be an enforcement of a
> policy,
> rather than syntax.)

The stdlib is as close to a definition of Ruby idiom as we have, so if
significant indentation isn't going to be allowed there it follows
that significant indentation will not become idiomatic and will
instead be idiosyncratic. If that's the case, then what problem is it
solving?


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
Caleb C. (Guest)
on 2009-06-04 05:11
(Received via mailing list)
On 6/3/09, Eleanor McHugh <removed_email_address@domain.invalid> wrote:
> On 3 Jun 2009, at 17:30, Marc H. wrote:
>> What does "meta-programming" NEED to have to do anything
>> with indent at all?
>
> Because if indentation becomes significant it's important that it
> doesn't break any central feature of Ruby, and my gut feeling (which I
> concede may be totally misguided) is that the area where such breakage
> is most likely to occur will be meta-programming. So whilst it may not
> have anything to do with the matter at all, determining whether or not
> that is the case is still an important consideration. At least for me.

So why metaprogramming, particularly? Ahhh, is it because code
generators may not take care to indent their generated code properly?
I know I've written code generators that do that...
Reid T. (Guest)
on 2009-06-04 06:45
(Received via mailing list)
Tony A. wrote:

> This is what I was trying to explain at the beginning of the thread (if you
> want significant indentation in Ruby look to Haskell, not Python), but few
> seemed to understand.  The proposed solutions aren't "Pythonic", they're...
> Haskellish?  Or whatever the proper term for that is.
>

can't resist    'Haskellish'.gsub!('ask','')
Tony A. (Guest)
on 2009-06-04 12:02
(Received via mailing list)
On Wed, Jun 3, 2009 at 8:44 PM, Reid T.
<removed_email_address@domain.invalid>wrote:

> Tony A. wrote:
> can't resist    'Haskellish'.gsub!('ask','')
>

I am not going to disagree
Eleanor McHugh (Guest)
on 2009-06-04 16:23
(Received via mailing list)
On 4 Jun 2009, at 02:10, Caleb C. wrote:
>> is most likely to occur will be meta-programming. So whilst it may
>> not
>> have anything to do with the matter at all, determining whether or
>> not
>> that is the case is still an important consideration. At least for
>> me.
>
> So why metaprogramming, particularly? Ahhh, is it because code
> generators may not take care to indent their generated code properly?
> I know I've written code generators that do that...

Precisely.

We use code generation so often in mainstream Ruby code - and
sometimes in some pretty arcane ways - that the possibility of
introducing a whole new category of defect into the process concerns
me much more than typing 'end' ever could.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
Caleb C. (Guest)
on 2009-06-04 20:30
(Received via mailing list)
On 6/4/09, Eleanor McHugh <removed_email_address@domain.invalid> wrote:
> me much more than typing 'end' ever could.
OTOH, as I am a macro bigot myself, I'd have to argue the position
that generating a bunch or ruby code to be passed to eval is the wrong
way to go about it; equivalent macros should be used instead.... ;)
Eleanor McHugh (Guest)
on 2009-06-04 20:43
(Received via mailing list)
On 4 Jun 2009, at 17:30, Caleb C. wrote:
>> sometimes in some pretty arcane ways - that the possibility of
>> introducing a whole new category of defect into the process concerns
>> me much more than typing 'end' ever could.
>
> OTOH, as I am a macro bigot myself, I'd have to argue the position
> that generating a bunch or ruby code to be passed to eval is the wrong
> way to go about it; equivalent macros should be used instead.... ;)

And I wouldn't disagree with you :)


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
This topic is locked and can not be replied to.