Greetings, folks. First time poster, so if I breach
any etiquette I sincerely apologize. I'm a bit of a Ruby Nuby 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/ruby-talk/252034
(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:

> Examined 1433 files in /usr/lib/ruby/1.8.
> Total non-empty lines: 193458
> Lines consisting of NOTHING BUT THE WORD END: 31587 (a whopping 16.33%)
>
> Streaks:
> 7: 4
> 6: 37
> 5: 28
> 4: 159
> 3: 765
> 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

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.

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

It's a blemish all right, but not on the language.

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

On Tue, May 19, 2009 at 17:40, J Haas <Myrdred@gmail.com> 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 Kudria
-- 
http://ben.kudria.net | Jabber: ben@kudria.net

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=A0pm, Joel VanderWerf <vj...@path.berkeley.edu> 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

[Note:  parts of this message were removed to make it a legal post.]

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 <Myrdred@gmail.com> 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 Locke, 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.

-- 
Tony Arcieri
medioh.com

On May 19, 3:20=A0pm, Benjamin Kudria <b...@kudria.net> 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.emacsw=
iki.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

On May 19, 3:23=A0pm, Tony Arcieri <t...@medioh.com> wrote:
> On Tue, May 19, 2009 at 3:40 PM, J Haas <Myrd...@gmail.com> 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. =A0You can have the Pythonic indent syntax or a purely expression
> based grammar with multi-line blocks. =A0You 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. =A0This is why Python can't =
have
> multi-line lambdas using Python's indent rules: lambdas are only useful a=
s
> expressions, but all indent blocks in Python are statements.

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

>=A0The same issue
> carries over to blocks, as a good deal of the time you want a method whic=
h
> 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. =A0Indent 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 =3D 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 !=3D 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. =A0If you =
have
> an indent-sensitive Ruby with implicit line joining, you limit the
> expressiveness of what you can do inside any syntactic constructs enclose=
d
> 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, y=
ou
> 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. =A0These are the lessons I learned. =A0I gave up and added an "en=
d"
> 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

[Note:  parts of this message were removed to make it a legal post.]

On Tue, May 19, 2009 at 4:50 PM, J Haas <Myrdred@gmail.com> 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.livelogix.net/logix/tutorial/3-Introduction-For-Python-Folks.html

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.



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

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?

-- 
Tony Arcieri
medioh.com

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

On Tue, May 19, 2009 at 19:49, Eric Hodel <drbrain@segment7.net> wrote:
> Does anybody complain about terminating '}' in C, C++ or Java?

Python programmers?

:-)

>=C2=A0Does anybody
> complain about terminating '.' on sentences? =C2=A0(There's a following c=
apital
> 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
--=20
http://ben.kudria.net | Jabber: ben@kudria.net

On May 19, 2009, at 16:58, Benjamin Kudria wrote:

> On Tue, May 19, 2009 at 19:49, Eric Hodel <drbrain@segment7.net>  
> 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.

I may have ben too sutle  Maybe your email program spel-chex  I  
certainly didnt have useles double leters in my original

On Tue, May 19, 2009 at 5:40 PM, J Haas <Myrdred@gmail.com> 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

On Tue, May 19, 2009 at 20:11, Eric Hodel <drbrain@segment7.net> wrote:
> I may have ben too sutle =C2=A0Maybe your email program spel-chex =C2=A0I=
 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
--=20
http://ben.kudria.net | Jabber: ben@kudria.net

On Wed, May 20, 2009 at 08:58:44AM +0900, Benjamin Kudria wrote:
> On Tue, May 19, 2009 at 19:49, Eric Hodel <drbrain@segment7.net> 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.

Did you include Comparable and implement <=> ?

-- 
Aaron Patterson
http://tenderlovemaking.com/

J Haas wrote:
> I'm a bit of a Ruby Nuby
...
> 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.
-- 
Posted via http://www.ruby-forum.com/.

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. 

On May 19, 4:49=A0pm, Eric Hodel <drbr...@segment7.net> wrote:
> Does anybody complain about terminating '}' in C, C++ or Java?

I do, now. Redundancy irritates me.

>=A0Does anybody complain about terminating '.' on sentences?

If the period accounted for one-sixth of English text, perhaps they
would.

On May 19, 5:19=A0pm, Gregory Brown <gregory.t.br...@gmail.com> wrote:
> Implement it, post it on github, then post back here and see if people
> like it. =A0 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.

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 Johnson
Advanced Computing Center for Research and Education
Vanderbilt University

On Wed, May 20, 2009 at 11:05 AM, J Haas <Myrdred@gmail.com> wrote:
> On May 19, 4:49=A0pm, Eric Hodel <drbr...@segment7.net> wrote:
>> Does anybody complain about terminating '}' in C, C++ or Java?
>
> I do, now. Redundancy irritates me.
>
>>=A0Does anybody complain about terminating '.' on sentences?
>
> If the period accounted for one-sixth of English text, perhaps they
> would.

wellwhydontwegetridofallpunctuationthingslikespacescommassemicolonsquoteset=
cperiodcertainlytakeupmuchmoreofourprosethantheydeserveandcapitalizationeat=
supvaluableverticalspaceandnoneedforparagraphseparationeither

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



--=20
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" <Myrdred@gmail.com> schrieb im Newsbeitrag 
news:abacc69e-f80e-4ef0-a07f-fe2e7af8e124@c7g2000prc.googlegroups.com...
...."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.

On May 20, 2009, at 11:51 AM, Rick DeNatale wrote:

> On Wed, May 20, 2009 at 11:05 AM, J Haas <Myrdred@gmail.com> wrote:
>> On May 19, 4:49 pm, Eric Hodel <drbr...@segment7.net> 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
>

That would be a valid criticism if J Haas's suggestion made things  
less readable.   But having to scroll less makes things more readable. 
   

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

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. But I don't like end end end end.
> say = (phrase):
>   10 times (i):
>     20 times (j):
>       phrase print
> _say
> The closing "_ say" ends the block saved to "say" var.

> ...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_chain-in-models/


> 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 Arcieri'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&thread=256682
-- 
Posted via http://www.ruby-forum.com/.

Joshua Ballanco 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. But I don't like end end end end.
>> say = (phrase):
>>   10 times (i):
>>     20 times (j):
>>       phrase print
>> _say
>> 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

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

On May 20, 8:51=A0am, Rick DeNatale <rick.denat...@gmail.com> wrote:
> Seriously, if you measure things by avoiding extra keystrokes, get a
> better editor. =A0I 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"
<brusch4_removeunderlinesandtextbetwe...@gmx.net> 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 assignin=
g
> 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 Ballanco <jball...@gmail.com> 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.

On Wed, May 20, 2009 at 2:35 PM, J Haas <Myrdred@gmail.com> wrote:
> On May 20, 8:51=A0am, Rick DeNatale <rick.denat...@gmail.com> wrote:
>> Seriously, if you measure things by avoiding extra keystrokes, get a
>> better editor. =A0I 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.



--=20
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

On May 20, 10:23=A0am, Roger Pack <rogerpack2...@gmail.com> wrote:
> Yeah the inheritance chain thing is hard.
> The closest you can come is with modules.
> ...
> class Object
> =A0override do
> =A0 =A0def print *args
> =A0 =A0 =A0super *(args + [" :-)"])
> =A0 =A0end
> =A0end
> end
>
> >> print 3
>
> 3 :-)

Nifty! Thanks.

> The only complaint I've heard about it was from Tony Arcieri'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.

> > =A0 def do_something(a, b, c):
> > { print a, b, c } =A0# this works
> > =A0 =A0 a + b + c
>
> and then afterward it picks up the previous indentation? I
> suppose...that would work. =A0It'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 =3D=3D b : do_something
> instead of
> if a =3D=3D 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=3D=3Db:
  # Nothing follows the colon, so this starts a new scope indented
past the if statement
  do_something()
do_something_else()

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

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

if a=3D=3Db: 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/

[Note:  parts of this message were removed to make it a legal post.]

On Wed, May 20, 2009 at 1:10 PM, J Haas <Myrdred@gmail.com> 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 Arcieri
medioh.com

[Note:  parts of this message were removed to make it a legal post.]

On Wed, May 20, 2009 at 1:25 PM, Tony Arcieri <tony@medioh.com> wrote:

> 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: [... snip ...]
>
> Begin statements (ala try/catch in Python) [... snip ...]
>
> Case statements: [... snip ...]
>
> case foo
> when bar
>  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.

-- 
Tony Arcieri
medioh.com

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

> On Wed, May 20, 2009 at 2:35 PM, J Haas <Myrdred@gmail.com> wrote:
>> On May 20, 8:51 am, Rick DeNatale <rick.denat...@gmail.com> wrote:
>>> Seriously, if you measure things by avoiding extra keystrokes, get a
>>> better editor.  I value readability over parsimony of lexical items.
>>
>> Cluttering up your code with "end" everywhere makes it less readable,
>> not more.
>
> Honestly, that's subjective. Some people prefer delimiters some don't.

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

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

On Wed, May 20, 2009 at 3:44 PM, Juan Zanos <juan_zanos@talkhouse.com> wrot=
e:
>
> On May 20, 2009, at 2:51 PM, Rick DeNatale wrote:
>
>> On Wed, May 20, 2009 at 2:35 PM, J Haas <Myrdred@gmail.com> wrote:
>>>
>>> On May 20, 8:51 am, Rick DeNatale <rick.denat...@gmail.com> wrote:
>>>>
>>>> Seriously, if you measure things by avoiding extra keystrokes, get a
>>>> better editor. =A0I 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? =A0 Neither method is ambiguous. =A0So no problem there=
 =A0But
> =A0scrolling 16% more often? =A0 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 edit=
or.

-greg

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

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

On Thu, May 21, 2009 at 12:21 AM, Rick DeNatale <rick.denatale@gmail.com> 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

On May 20, 12:25=A0pm, Tony Arcieri <t...@medioh.com> wrote:
> I already responded to this. =A0I 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
> =A0 blah
> elsif bar
> =A0 blah2
> else
> =A0 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.

> Begin statements (ala try/catch in Python)
>
> begin
> =A0 somecode
> =A0 morecode
> rescue FooError
> =A0 some_rescue_action
> rescue BarError
> =A0 another_rescue_action
> ensure
> =A0 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. =A0How d=
o you
> tell when these expressions are complete? =A0Obviously a naive "dedent =
=3D 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.

On Wed, May 20, 2009 at 12:35 PM, J Haas <Myrdred@gmail.com> wrote:
> On May 20, 8:51=A0am, Rick DeNatale <rick.denat...@gmail.com> 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.


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

http://on-ruby.blogspot.com
http://eldersjournal.blogspot.com

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

> On Wed, May 20, 2009 at 3:44 PM, Juan Zanos  
> <juan_zanos@talkhouse.com> wrote:
>>
>> On May 20, 2009, at 2:51 PM, Rick DeNatale wrote:
>>
>>> On Wed, May 20, 2009 at 2:35 PM, J Haas <Myrdred@gmail.com> wrote:
>>>>
>>>> On May 20, 8:51 am, Rick DeNatale <rick.denat...@gmail.com> wrote:
>>>>>
>>>>> Seriously, if you measure things by avoiding extra keystrokes,  
>>>>> get a
>>>>> better editor.  I value readability over parsimony of lexical  
>>>>> items.
>>>>
>>>> Cluttering up your code with "end" everywhere makes it less  
>>>> readable,
>>>> not more.
>>>
>>> Honestly, that's subjective. Some people prefer delimiters some  
>>> don't.
>>
>> Is it subjective?   Neither method is ambiguous.  So no problem  
>> there.  But
>>  scrolling 16% more often?   That must have some cost to readability.
>
> If you break up code into more files, or use a folding editor, or use
> an editor that lets you jump to code by a method name, scrolling is a
> non-issue.
>
> Rick's point remains.  If this is an issue you're facing, get a  
> better editor.
>
> -greg
>


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

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

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

On May 20, 9:50=A0am, Gregory Brown <gregory.t.br...@gmail.com> wrote:
> On Wed, May 20, 2009 at 3:44 PM, Juan Zanos <juan_za...@talkhouse.com> wr=
ote:
>
> > On May 20, 2009, at 2:51 PM, Rick DeNatale wrote:
>
> >> On Wed, May 20, 2009 at 2:35 PM, J Haas <Myrd...@gmail.com> wrote:
>
> >>> On May 20, 8:51 am, Rick DeNatale <rick.denat...@gmail.com> wrote:
>
> >>>> Seriously, if you measure things by avoiding extra keystrokes, get a
> >>>> better editor. =A0I value readability over parsimony of lexical item=
s.
>
> >>> 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? =A0 Neither method is ambiguous. =A0So no problem the=
re =A0But
> > =A0scrolling 16% more often? =A0 That must have some cost to readabilit=
y.
>
> 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. =A0If 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

Juan Zanos wrote:
> I'm willing to admit that Python programs are generally shorter

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

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

On Wed, May 20, 2009 at 4:32 PM, Juan Zanos <juan_zanos@talkhouse.com> wrot=
e:

> You want me to have even more files and spend even more time folding and
> unfolding things. =A0And you assume I use a crummy editor and there is a
> better one that magically makes a surprising number of wasted lines
> irrelevant. =A0I 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.

>> 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
-- 
Posted via http://www.ruby-forum.com/.

[Note:  parts of this message were removed to make it a legal post.]

On Wed, May 20, 2009 at 2:30 PM, J Haas <Myrdred@gmail.com> 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.

-- 
Tony Arcieri
medioh.com

On Wed, May 20, 2009 at 4:40 PM, Ryo Furue <furue@hawaii.edu> wrote:
> On May 20, 9:50=A0am, Gregory Brown <gregory.t.br...@gmail.com> wrote:

>> Rick's point remains. =A0If this is an issue you're facing, get a better=
 editor.
>
> But, the amount of meaningful code displayed in a single screenshot
> still suffers. =A0A screenful is a chunk of code
> you can see without scrolling or jumping. =A0The 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

On May 20, 2009, at 4:39 PM, Gregory Brown wrote:

> On Wed, May 20, 2009 at 4:32 PM, Juan Zanos  
> <juan_zanos@talkhouse.com> 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.
>


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. 

On Wed, May 20, 2009 at 5:23 PM, Juan Zanos <juan_zanos@talkhouse.com> wrot=
e:


> I'm saying that when all other factors are held =A0constant more lines is
> less readable. =A0Your arguments ignore that and only place value on
> editors and project management when the extra lines exist and
> not when they don't. =A0 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

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 Wright

[Note:  parts of this message were removed to make it a legal post.]

On Wed, May 20, 2009 at 2:45 PM, Tony Arcieri <tony@medioh.com> 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 Arcieri
medioh.com

[Note:  parts of this message were removed to make it a legal post.]

On Wed, May 20, 2009 at 4:18 PM, Tony Arcieri <tony@medioh.com> 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:

> 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.
>
> But the complexity of any proposed solution for this puzzle is immense, to
> me: it requires the parser (or more precisely, the lexer) to be able to
> switch back and forth between indent-sensitive and indent-insensitive modes,
> keeping a stack of previous modes and indentation level. Technically that
> 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 Goldberg contraption<http://www.rube-goldberg.com/html/gallery.htm>
> .
>
You are proposing a Rube Goldberg contraption whereby the scanner would
require some degree of grammatical awareness.  This is a complex solution.
The minor flaw is that you don't like "end" statements.  Is the minor flaw
of having repeated end statements really worth the level of complexity the
solution would require?

-- 
Tony Arcieri
medioh.com

On May 20, 2009, at 5:41 PM, Gregory Brown wrote:

> On Wed, May 20, 2009 at 5:23 PM, Juan Zanos  
> <juan_zanos@talkhouse.com> 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.

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. 

On Wed, May 20, 2009 at 9:38 PM, Juan Zanos <juan_zanos@talkhouse.com> wrot=
e:
>
> On May 20, 2009, at 5:41 PM, Gregory Brown 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. =A0If only those folks of poor ability could design so well a=
s
> 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

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

From: "Tony Arcieri" <tony@medioh.com>
>
> 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

  

[Note:  parts of this message were removed to make it a legal post.]

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

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


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

-- 
Tony Arcieri
medioh.com

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

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

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

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

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

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


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

a ? b :
 c

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

Best of luck.
-=r
-- 
Posted via http://www.ruby-forum.com/.

On May 20, 1:45=A0pm, Tony Arcieri <t...@medioh.com> wrote:
> Okay, you just want an example I guess. =A0Code speaks louder than words!
>
> Here is an example Ruby program:
>
> foo =3D [1,2,3]
> x =3D foo.map do |n|
> =A0 n +=3D 1
> =A0 n *=3D 2
> end
> result =3D case x
> when Array
> =A0 x.map! do |n|
> =A0 =A0 n *=3D 3
> =A0 =A0 n +=3D 4
> =A0 end
> when NilClass
> =A0 x
> end
> result =3D if result.size > 10
> =A0 result[0..2]
> else
> =A0 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/m5fee1e9=
2.
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 =3D [1,2,3]
x =3D foo.map do |n|:
  n +=3D 1
  n *=3D 2

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

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

p result
jhaas@littlefinger:~/pyruby$ irb
irb(main):001:0> require 'pyruby'
=3D> true
irb(main):002:0> require 'pyrbtest'
[16, 22, 28]
=3D> 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?

On May 20, 3:18=A0pm, Tony Arcieri <t...@medioh.com> wrote:
> n =3D 2 * -[1,2,3,4,5].inject(0) do |a, b|
> =A0 c =3D a * 2
> =A0 a * c + b
> end
> result =3D 8 * -if n > 0
> =A0 -n +=3D 10000
> else
> =A0 n + 500000
> end
> puts result

__BEGIN__

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

Once again, worked perfectly on its first time through the
preprocessor.

On May 21, 9:16=A0am, J Haas <Myrd...@gmail.com> wrote:
> I found the old preprocessor script from awhile ago that I mentioned
> earlier in this thread. I've pastebinned it athttp://pastebin.com/m5fee1e=
92.

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!

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

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

I was thinking more like Lisp macros.  Check out:

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

steven

On May 21, 2009, at 1:26 PM, Steven Arnold wrote:

>
> On May 21, 2009, at 8:06 AM, Roger Pack wrote:
>
>> Interesting--it's been awhile since I used C...what would
>> macros...essentially do? An example of them?
>
> I was thinking more like Lisp macros.  Check out:
>
>    http://www.defmacro.org/ramblings/lisp.html
>
> 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. 
  

Joshua Ballanco 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 Britt

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

Tony Arcieri wrote:

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


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 Britt

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

On May 20, 2009, at 15:28 , Tony Arcieri 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).

[Note:  parts of this message were removed to make it a legal post.]

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

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


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!

-- 
Tony Arcieri
medioh.com

On May 21, 1:12=A0pm, James Britt <james.br...@gmail.com> 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.

--
-yossef

[Note:  parts of this message were removed to make it a legal post.]

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

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

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.

-- 
Tony Arcieri
medioh.com

On May 21, 2009, at 10:24 PM, Tony Arcieri 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

[Note:  parts of this message were removed to make it a legal post.]

On Thu, May 21, 2009 at 10:27 PM, J Haas <Myrdred@gmail.com> 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 Arcieri
medioh.com

[Note:  parts of this message were removed to make it a legal post.]

On Thu, May 21, 2009 at 10:27 PM, J Haas <Myrdred@gmail.com> 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?

-- 
Tony Arcieri
medioh.com

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

Juan Zanos wrote:
> On May 21, 2009, at 1:26 PM, Steven Arnold wrote:
>> On May 21, 2009, at 8:06 AM, Roger Pack wrote:
>>> Interesting--it's been awhile since I used C...what would
>>> macros...essentially do? An example of them?
>> I was thinking more like Lisp macros.  Check out:
>>
>>    http://www.defmacro.org/ramblings/lisp.html
> 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.

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

On Fri, 2009-05-22 at 14:33 +0900, Tony Arcieri 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.

> 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
-- 
Posted via http://www.ruby-forum.com/.

On May 21, 10:33 pm, Tony Arcieri <t...@medioh.com> 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 Arcieri <t...@medioh.com> wrote:
> On Tue, May 19, 2009 at 3:40 PM, J Haas <Myrd...@gmail.com> 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.

On May 22, 6:32=A0am, Reid Thompson <reid.thomp...@ateb.com> wrote:
> It doesn't really. =A0Or at least only simplistically; by re-writing the
> input code, attempting to place 'end' in the proper place based on
> indentation. =A0It 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.

> 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
-- 
Posted via http://www.ruby-forum.com/.

[Note:  parts of this message were removed to make it a legal post.]

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

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

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.

-- 
Tony Arcieri
medioh.com

"J Haas" <Myrdred@gmail.com> schrieb im Newsbeitrag 
news:3dd501b0-84bc-4781-af21-f09714148e6b@y6g2000prf.googlegroups.com...
>> 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#?

Reid Thompson wrote:
> On Fri, 2009-05-22 at 14:33 +0900, Tony Arcieri wrote:
>> Well great!  I'm not really sure how that script works, but cool.
>> However,
>> what you have there is a marked departure from how Python actually
>> works.
>> But if you're happy with it, great.  Go for it and see how popular you
>> can
>> make it.
>>
>>
> It doesn't really.  Or at least only simplistically; by re-writing the
> input code, attempting to place 'end' in the proper place based on
> indentation.  It breaks silently if you happen to misplace your
> whitespace incorrectly, placing an 'end' in the wrong place.


This is an interesting aspect of indentation-sensitive syntax.

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

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

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



-- 
James Britt

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

J Haas wrote:
> On May 21, 10:33 pm, Tony Arcieri <t...@medioh.com> 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 Britt

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

James Britt wrote:
> I've wondered if this sort thing is a problem in Python; perhaps it is 
> less likely there that any accidental indent or out-dent will still give 
>  you well-formed code.
> 
I've only minimally looked at python, but I'm pretty sure that it will throw an 
error when indentation is fouled.

Reid Thompson wrote:
> James Britt wrote:
>> I've wondered if this sort thing is a problem in Python; perhaps it is 
>> less likely there that any accidental indent or out-dent will still 
>> give  you well-formed code.
>>
> I've only minimally looked at python, but I'm pretty sure that it will 
> throw an error when indentation is fouled.

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

From: "James Britt" <james.britt@gmail.com>
> 
> 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

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.

On May 22, 1:02 pm, Tony Arcieri <t...@medioh.com> 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?

> A multi-line block returning a value, e.g.
> foo = somemethod do |arg1, arg2, arg3|
>   x = do_something arg1
>   y = do_something_else x, arg2
>   and_something_else_again y, arg3
> end
>
> Or for that matter, a multi-line lambda:
>
> foo = lambda do |arg1, arg2, arg3|
>   x = do_something arg1
>   y = do_something_else x, arg2
>   and_something_else_again y, arg3
> end

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

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

Or this?

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

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

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

Your response was:

> Okay, you just want an example I guess.

(jh: what was your first clue?)

> Here is an example Ruby program:
>
> foo = [1,2,3]
> x = foo.map do |n|
>   n += 1
>   n *= 2
> end
> result = case x
> when Array
>   x.map! do |n|
>     n *= 3
>     n += 4
>   end
> when NilClass
>   x
> end
> result = if result.size > 10
>   result[0..2]
> else
>   result
> end
> p result
>
> The output of this program is:
>
> [16, 22, 28]
>
> Show me how you would parse the equivalent program in an
> indentation-sensitive Ruby, e.g.:

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

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

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

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

And this:

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

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

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

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

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

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

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

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

And then, without even waiting for a reply:

> you're being a right c--t

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

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

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

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

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

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

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

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

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

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

[Note:  parts of this message were removed to make it a legal post.]

On Mon, May 25, 2009 at 9:40 AM, J Haas <Myrdred@gmail.com> 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

On 5/25/09, J Haas <Myrdred@gmail.com> 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

On Sunday 24 May 2009 03:42:19 pm James Britt 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.

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

David Masover wrote:
> On Sunday 24 May 2009 03:42:19 pm James Britt 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 Britt

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

On 5/25/09, Joshua Ballanco <jballanc@gmail.com> wrote:
> 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

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.

"David Masover" <ninja@slaphack.com> schrieb im Newsbeitrag 
news:200905251330.22874.ninja@slaphack.com...
> On Wednesday 20 May 2009 05:28:34 pm Tony Arcieri 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.

> 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
-- 
Posted via http://www.ruby-forum.com/.

On May 20, 6:36=A0pm, Joel VanderWerf <vj...@path.berkeley.edu> wrote:
> Joshua Ballanco 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. But I don't like end end end end.
> >> say =3D (phrase):
> >> =A0 10 times (i):
> >> =A0 =A0 20 times (j):
> >> =A0 =A0 =A0 phrase print
> >> _say
> >> 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
>
> --
> =A0 =A0 =A0 =A0vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

The Judicial System in Islam : Its Legal Basis and Islam Ruling
Please forgive us for any disturbance, but we have an important
subject to address to you regarding FAITH, and we Don=92t intend to
overload your email with unnecessary messages=85

The Judicial System in Islam : Its Legal Basis and Islam Ruling

By The Editorial Team of Dr. Abdurrahman al-Muala (translated by
islamtoday.com)


Defining the Judicial System and its Legal basis

The judicial system in Islam is a system for deciding between people
in litigation with the aim of settling their disputes in accordance
with the injunctions of the Divine Law, injunctions that are taken
from the Quran and Sunnah.

All of the Messengers of God (may God praise them all) acted as
judges. God says:

=93And remember David and Solomon, when they gave judgment concerning
the field when people=92s sheep had browsed therein at night, and We
were witness to their judgment. And We made Solomon to understand the
case. And to each of them We gave good judgment and knowledge.=94 (Quran
21:78-79)
God also says:

=93O David, verily we have placed you as a successor on Earth, so judge
between people in truth, and do not follow your desires for it will
mislead you from the path of God. Verily, those who stray from the
path of God have a severe punishment because they forgot the day of
reckoning.=94 (Quran 38:26)

Prophet Muhammad, who came with the final and eternal Message, was
ordered by God to pass judgment in disputes just as he was ordered to
spread the word of God and call people to Islam. This is mentioned in
the Quran in a number of places. God says, for instance:

=93So judge (O Muhammad) between them by what God has revealed and do
not follow their vain desires, but beware of them lest they turn you
away from some of what God has sent down to you.=94 (Quran 5:49)

God also says:

=93=85And if you judge (O Muhammad), judge between them with justice.
Verily, God loves those who act justly.=94 (Quran 5:42)

And He says:

=93But no, by your Lord, they shall have no faith until they make you (O
Muhammad) judge in all their disputes and find in themselves no
resistance against your decisions and accept them with full
submission.=94 (Quran 4:65)

The Sunnah also provides for the legal basis of the Islamic judicial
system. It is related by Amr b. al-Aas that the Prophet said:

=93If a judge gives a judgment using his best judgment and is correct,
then he receives a double reward (from God). If he uses his best
judgment but makes a mistake, then he receives a single
reward.=94 (Ahmed)

God=92s Messenger said:

=93You should not wish to be like other people, except in two cases: a
man who God has given wealth and he spends it on Truth and another who
God has granted wisdom and he gives verdicts on its basis and teaches
others.=94 (Saheeh Al-Bukhari, Saheeh Muslim)

Many scholars have related to us that there is consensus among Muslims
on the legal status of the judicial system in Islam. Ibn Qudamah says:

=93The Muslims are unanimously agreed that a judicial system must be
established for the people.=94
The Islamic Ruling Concerning the Judiciary

The jurists agree that the duties of the judge are an obligation that
must be carried out by society. If some members of society carry out
this duty, it is sufficient for everyone. If, on the other hand,
everyone neglects it, then everyone in society is sinful.

The proof that these duties are obligatory comes from the Quran:

=93O you who believe! Stand out firmly for justice...=94 (Quran 4:135)

It is only necessary for a small number of individuals to perform
judicial duties since judicial concerns come under the broad duty of
enjoining what is right and forbidding what is wrong. It is not
obligatory for every individual to carry out this duty as long as some
people are doing so.

The affairs of the people will not be correct and upright without a
judicial system. It is, consequently, obligatory for one to exist,
just like it is necessary to have a military. Imam Ahmad, one of the
greatest and most well-known scholars of Islam said:

=93People have to have a judicial authority or their rights will
disappear.=94

The duties of the judiciary include enjoining what is right, helping
the oppressed, securing people=92s rights, and keeping oppressive
behavior in check. None of these duties can be performed without the
appointment of a judiciary.

A judicial system is a necessity for the prosperity and development of
nations. It is needed to secure human happiness, protect the rights of
the oppressed, and restrain the oppressor. It is the way to resolve
disputes and ensure human rights. It facilitates enjoining what is
right, forbidding what is wrong, and curbing immoral behavior. In this
way, a just social order can be enjoyed by all sectors of society, and
every individual can feel secure in his life, property, honor, and
liberty. In this environment, nations can progress, civilization can
be achieved, and people are free to pursue what will better them both
spiritually and materially.




=97=97=97=97=97=97=97=97=97=97=97-


For more information about Islam

http://english.islamway.com/

http://www.islamhouse.com/

http://www.discoverislam.com/

http://www.islambasics.com/index.php

http://english.islamway.com/

http://www.islamtoday.net/english/

http://www.islamweb.net/ver2/MainPage/indexe.php

http://www.sultan.org/

http://www.islamonline.net/

Contact Us At

imanway.qa@gmail.com

On May 22, 9:01=A0am, Roger Pack <rogerpack2...@gmail.com> wrote:
> Tony's point was that certain constructs, like case statements, won't be
> transformable into indentation only blocks. =A0Does 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 =3D UserSession.find
    end

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

    def require_user
      unless current_user
        store_location
        flash[:notice] =3D "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] =3D "You must be logged out to access this page"
        redirect_to account_url
        return false
      end
    end

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

    def redirect_back_or_default(default)
      redirect_to(session[:return_to] || default)
      session[:return_to] =3D 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 =3D UserSession.find

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

    def require_user:
      unless current_user:
        store_location
        flash[:notice] =3D "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] =3D "You must be logged out to access this page"
        redirect_to account_url
        return false

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

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

[Note:  parts of this message were removed to make it a legal post.]

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

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

> On May 22, 9:01 am, Roger Pack <rogerpack2...@gmail.com> wrote:
> > Tony's point was that certain constructs, like case statements, won't be
> > transformable into indentation only blocks.  Does that make sense?
>
> 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
>
>
>

> 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
-- 
Posted via http://www.ruby-forum.com/.

On 5/27/09, Roger Pack <rogerpack2005@gmail.com> 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.)

> #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
-- 
Posted via http://www.ruby-forum.com/.

On May 27, 4:32=A0pm, Caleb Clausen <vikk...@gmail.com> wrote:
> On 5/27/09, Roger Pack <rogerpack2...@gmail.com> 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 remind=
er.

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.

On May 27, 2009, at 9:35 AM, J Haas wrote:

> On May 22, 9:01 am, Roger Pack <rogerpack2...@gmail.com> wrote:
>> Tony's point was that certain constructs, like case statements,  
>> won't be
>> transformable into indentation only blocks.  Does that make sense?
>
> 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.)

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

J Haas <Myrdred@gmail.com> wrote:
> few areas where I think Python beats Ruby, and that's syntatically-
> significant
> indentation.
You think so, I'm not. ;)

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

On Thu, 2009-05-28 at 14:40 +0900, Joshua Ballanco wrote:
> the ruby-vim files 

could you provide an url for these?

Thanks,
reid

On May 27, 2009, at 12:35 PM, J Haas wrote:

> On May 22, 9:01 am, Roger Pack <rogerpack2...@gmail.com> wrote:
>> Tony's point was that certain constructs, like case statements,  
>> won't be
>> transformable into indentation only blocks.  Does that make sense?
>
> 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
>
> On May 27, 2009, at 12:35 PM, J Haas wrote:
>
>> On May 22, 9:01 am, Roger Pack <rogerpack2...@gmail.com> wrote:
>>> Tony's point was that certain constructs, like case statements,  
>>> won't be
>>> transformable into indentation only blocks.  Does that make sense?
>>
>> 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
>>
>>
> As this debate unfolds 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 do.  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.  It's  
> trivially
> easy to read.  It can't just be me.  There seems to be no shortage  
> of Python
> folk who have no problem either.  Objectively, being forced to  
> explicitly type
> 'end' all the time seems to takes up a whole lot of space.
>
> 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
>
>
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.

On 5/27/09, Roger Pack <rogerpack2005@gmail.com> 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.)

On 28 May 2009, at 15:06, Juan Zanos 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.

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

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

Eleanor McHugh <eleanor@games-with-brains.com> writes:

> On 28 May 2009, at 15:06, Juan Zanos 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.

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

-- 
__Pascal Bourguignon__

On May 28, 7:19=A0am, Caleb Clausen <vikk...@gmail.com> 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.

On 5/28/09, Eleanor McHugh <eleanor@games-with-brains.com> 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 Ballanco 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.

On 5/28/09, J Haas <Myrdred@gmail.com> wrote:
> On May 28, 7:19 am, Caleb Clausen <vikk...@gmail.com> 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.)

On May 28, 2009, at 12:39 PM, Caleb Clausen wrote:
> On 5/28/09, Eleanor McHugh <eleanor@games-with-brains.com> 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 Wright

On May 28, 9:59=A0am, Caleb Clausen <vikk...@gmail.com> 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:
>
> =A0 if foo: =A0#new-style indentation block
> =A0 =A0while bar #old-style ended block
> baz
> =A0 =A0end
>
> 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.

On 28 May 2009, at 17:39, Caleb Clausen wrote:
> On 5/28/09, Eleanor McHugh <eleanor@games-with-brains.com> 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 Ballanco 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.

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

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.

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

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

On May 28, 2009, at 12:39 PM, Caleb Clausen wrote:

> On 5/28/09, Eleanor McHugh <eleanor@games-with-brains.com> 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 Ballanco 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.

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.

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

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.

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

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.

On 5/28/09, Eleanor McHugh <eleanor@games-with-brains.com> 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.

On 5/28/09, J Haas <Myrdred@gmail.com> 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?

On May 28, 12:33=A0pm, Caleb Clausen <vikk...@gmail.com> 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:
>
> =A0 while foo;
> =A0 =A0 =A0bar

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.

> 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
--
http://rimantas.com/

On May 28, 2009, at 4:09 PM, Rimantas Liubertas wrote:

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

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?

>> 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
--
http://rimantas.com/

On May 28, 2009, at 4:32 PM, Rimantas Liubertas wrote:

>>> 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
> --
> http://rimantas.com/
>

You'll have to start shopping for a new language.   White space is  
already significant in Ruby. 
  

On 28 May 2009, at 20:13, Caleb Clausen wrote:
> On 5/28/09, Eleanor McHugh <eleanor@games-with-brains.com> 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.

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

[Note:  parts of this message were removed to make it a legal post.]

On Thu, May 28, 2009 at 1:33 PM, Caleb Clausen <vikkous@gmail.com> 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.

-- 
Tony Arcieri
medioh.com

Tony Arcieri 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

[Note:  parts of this message were removed to make it a legal post.]

On Thu, May 28, 2009 at 6:52 PM, James Britt <james.britt@gmail.com> 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-sensitivity-post-mortem.html

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.

--
Tony Arcieri
medioh.com

Tony Arcieri wrote:
> On Thu, May 28, 2009 at 6:52 PM, James Britt <james.britt@gmail.com> 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-sensitivity-post-mortem.html
> 
> 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 Britt

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

"Roger Pack" <rogerpack2005@gmail.com> schrieb im Newsbeitrag 
news:80e443053d990f42b14f60bbc47e560d@ruby-forum.com...
> @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.

"J Haas" <Myrdred@gmail.com> schrieb im Newsbeitrag 
news:90debbfe-01b0-466c-8be9-fa95a4ae0c75@x31g2000prc.googlegroups.com...

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

"Juan Zanos" <juan_zanos@talkhouse.com> schrieb im Newsbeitrag 
news:57F45D4C-3FC9-40F9-86E5-B104805756B0@talkhouse.com...
>
> On May 28, 2009, at 4:32 PM, Rimantas Liubertas wrote:
>
>>>> 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
>> --
>> http://rimantas.com/
>>
>
> You'll have to start shopping for a new language.   White space is
> already significant in Ruby.
>
>

Did somebody tried Brainf*ck language? 

On May 28, 2009, at 10:00 PM, Michael Bruschkewitz wrote:

>
> "Juan Zanos" <juan_zanos@talkhouse.com> schrieb im Newsbeitrag news:57F45D4C-3FC9-40F9-86E5-B104805756B0@talkhouse.com 
> ...
>>
>> On May 28, 2009, at 4:32 PM, Rimantas Liubertas wrote:
>>
>>>>> 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
>>> --
>>> http://rimantas.com/
>>>
>>
>> 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!

> 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/tpci/index.html 
).   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.

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.

On May 28, 2009, at 9:39 AM, Caleb Clausen wrote:

> I feel that I did address this point adequately already, so it's
> annoying to see both you and Joshua Ballanco 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

On Fri, May 29, 2009 at 12:54 AM, Joshua Ballanco <jballanc@gmail.com> 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

"Reid Thompson" <reid.thompson@ateb.com> schrieb im Newsbeitrag 
news:4A1F5409.4020909@ateb.com...
> 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. 

On Fri, 2009-05-29 at 17:56 +0900, Michael Bruschkewitz wrote:
> "Reid Thompson" <reid.thompson@ateb.com> schrieb im Newsbeitrag 
> news:4A1F5409.4020909@ateb.com...
> > 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" ?
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.  

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

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

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

On 28 May 2009, at 22:22, Juan Zanos 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

"Reid Thompson" <reid.thompson@ateb.com> schrieb im Newsbeitrag 
news:1243609487.3435.5.camel@raker.ateb.com...
> 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 wrote:
> On 28 May 2009, at 22:22, Juan Zanos 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
> 
> 
for some really significant whitespace..

http://compsoc.dur.ac.uk/whitespace/

> 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
-- 
Posted via http://www.ruby-forum.com/.

Caleb Clausen <vikkous@gmail.com> wrote in
news:347c648b0905251250j61ce408cva469529722fe500c@mail.gmail.com: 

> On 5/25/09, J Haas <Myrdred@gmail.com> 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!)

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.

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

-- 
rzed

> 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

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

On 5/30/09, rzed <rzantow@gmail.com> wrote:
> Caleb Clausen <vikkous@gmail.com> wrote
>> 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.
>
> 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

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 Pack wrote:
> 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?

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.

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

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

> ...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
-- 
Posted via http://www.ruby-forum.com/.

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

On Sun, May 31, 2009 at 5:35 AM, Michael Bruschkewitz
<brusch4_removeunderlinesandtextbetween_@gmx.net> 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

Juan Zanos wrote:
>> 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/tpci/index.html).   
> 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.

> 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.)
-- 
Posted via http://www.ruby-forum.com/.

On 3 Jun 2009, at 17:30, Marc Heiler 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

On 6/3/09, Eleanor McHugh <eleanor@games-with-brains.com> wrote:
> On 3 Jun 2009, at 17:30, Marc Heiler 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...

On 4 Jun 2009, at 02:10, Caleb Clausen wrote:
> On 6/3/09, Eleanor McHugh <eleanor@games-with-brains.com> wrote:
>> On 3 Jun 2009, at 17:30, Marc Heiler 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...

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

On 6/4/09, Eleanor McHugh <eleanor@games-with-brains.com> wrote:
> On 4 Jun 2009, at 02:10, Caleb Clausen wrote:
>> 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.

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

On 4 Jun 2009, at 17:30, Caleb Clausen wrote:
> On 6/4/09, Eleanor McHugh <eleanor@games-with-brains.com> wrote:
>> On 4 Jun 2009, at 02:10, Caleb Clausen wrote:
>>> 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.
>
> 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