Pythonic indentation (or: beating a dead horse)
J Haas
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
Joel VanderWerf
> 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
J Haas
about... apparently wrapping my lines at 80 characters was not a good
idea. Sigh.
On May 19, 2:59 pm, 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
Benjamin Kudria
>
> 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: b...@kudria.net
Tony Arcieri
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 <Myr...@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
J Haas
> Well, tough?
I could probably have found a more tactful way of putting this. Sorry.
> I like to use tabs to indent, and spaces to align. (a lahttp://www.emacswiki.org/emacs/IntelligentTabs)
This wouldn't be a problem, at least it's not a problem in Python and
needn't be a problem in Ruby. Having an unclosed paren, bracket, or
brace results in automatic line continuation and you can put whatever
combination of spaces and tabs you'd like on the next line. It'll be
logically considered part of the line before.
Also, I should add that mixing tabs and spaces would only be a problem
if you did something like this: (leading dots represent spaces)
......while some_condition:
\t\tdo_something # interpreter can't tell indentation level here
You could freely mix tabs and spaces as long as they match up from the
start:
......while some_condition:
......\tdo_something # interpreter can tell that this indentation
level is "one more" than previous
> All kidding aside, who cares? Write a preprocessor.
Don't need to; it's already been done. But I'd rather see the language
improved.
--J
J Haas
> 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.
I'm having a hard time following why. Can you provide an example of a
Ruby snippet that couldn't be done with scoping defined by
indentation?
> In Python, all indent blocks are statements. This is why Python can't have
> multi-line lambdas using Python's indent rules: lambdas are only useful as
> expressions, but all indent blocks in Python are statements.
This seems like a problem with Python, not a problem with indentation.
> The same issue
> carries over to blocks, as a good deal of the time you want a method which
> takes a block to return a value (e.g. map, inject, filter, sort, grep)
Again, I would really like to see an example of the sort of thing
you'd want to do here that simply requires "end" to work.
> There's quite an interesting interplay of design decisions to make Python's
> indent-sensitive grammar work the way it does. Indent blocks in Python have
> no terminator token, whereas every expression in a Ruby-like grammar must be
> terminated with ";" or a newline.
Well, every expression in a Ruby-like grammar must be terminated by a
token. What that token must be depends on the grammar. Why not
something like this? (and please forgive the highly unorthodox
pseudocode syntax)
parse_line_indent:
if indentation = previous_line_indentation: do_nothing
if indentation > previous_line_indentation:
push_indentation_to_indent_stack_and_enter_new_scope
if indentation < previous_line_indentation:
while indentation > top_of_indent_stack:
insert_backtab_token # here's your statement terminator
pop_top_of_indent_stack
if indentation != top_of_indent_stack: raise IndentationError
In other words, the parser treats an indentation level less than the
indentation level of the previous line as a statement-terminating
token.
> Implicit line joining works in Python because the only syntactic
> constructions which can exist surrounded in [...] (...) {...} tokens are
> expressions, so you can't put an indent block inside of these. If you have
> an indent-sensitive Ruby with implicit line joining, you limit the
> expressiveness of what you can do inside any syntactic constructs enclosed
> by these tokens.
This sorta makes sense but I'd really like to see a concrete example
of what you're talking about. It doesn't seem like this would be an
insurmountable difficulty but it's hard to say without the example.
> If you want to have indent blocks in a purely expression-based grammar, you
> need to use a syntax more like Haskell.
Being completely unfamiliar with Haskell (functional programming's
never been my strong suit) I can't really comment.
> P.S. I tried to make a Ruby-like language with an indentation-sensitive
> syntax. These are the lessons I learned. I gave up and added an "end"
> keyword.
I'll be glad to take the benefit of your practical experience, but at
the risk of seriously violating DRY, some sort of demonstration of
something that you can do with "end" but couldn't do with indentation
would be nice.
--J
Tony Arcieri
On Tue, May 19, 2009 at 4:50 PM, J Haas <Myr...@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:
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
Eric Hodel
>>> This is *not* DRY. Or anything remotely resembling it. This is an
>>> ugly blemidh on a language that otherwise is very beautiful.
>>
>> It's a blemish all right, but not on the language.
>
> If not the language, then where? In the library code? Maybe those four
> places where "end" is repeated seven consecutive times are poorly
> engineered and could be refactored,
They almost certainly could be, this is a sign of strong code-smel
> but how about the nearly thousand
> times "end" is repeated three or more times? Is every one of those the
> result of poor engineering on the part of the library programmers, or
> were at least some of them forced on the programmers by the language?
>
> One statistic that I didn't print out from my script was that there
> are an average of 135 lines of "end" per file. For a language that
> prides itself on expressiveness and brevity, this is just plain silly.
Does anybody complain about terminating '}' in C, C++ or Java? Does
anybody complain about terminating '.' on sentences? (There's a
folowing capital letter for disambiguation!) I think we need to
remove all useles constructs from all languages
Benjamin Kudria
> Does anybody complain about terminating '}' in C, C++ or Java?
Python programmers?
:-)
> Does anybody
> complain about terminating '.' on sentences? (There's a following capital
> letter for disambiguation!)
I agree with your point, but I don't this argument helps - computer
languages and human languages are two fairly distinct classes, with
different origins, requirements, and, um...parsers.
In my opinion they aren't always comparable.
Ben Kudria
Eric Hodel
> On Tue, May 19, 2009 at 19:49, Eric Hodel <drb...@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
Gregory Brown
> Well, I think that's probably enough for my first post. Thank you for
> your
> time, and Matz, thanks for the language. Thoughts, anyone?
Implement it, post it on github, then post back here and see if people
like it. These conversations in which people pretend to try to
convince one another just to assert their views are much less
productive than just solving whatever the original problem is.
-greg
Benjamin Kudria
> I may have ben too sutle Maybe your email program spel-chex I certainly
> didnt have useles double leters in my original
Doh :-)
I have a compulsive habit of correcting (perceived!) typos in quotes.
I should probably stop.
Ben
Aaron Patterson
> On Tue, May 19, 2009 at 19:49, Eric Hodel <drb...@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/
Brian Candler
> 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/.
Juan Zanos
On May 19, 2009, at 5:40 PM, J Haas wrote:
> My friends, when ONE OUT OF EVERY SIX of your code lines consists of
> just the word "end", you have a problem with conciseness. I
Yes, it's a problem. There is no point in pretending otherwise. The
language
would be even better if this issue were solved. It sounds like it
could be
adequately solved with some type of meaningful indentation.
It doesn't seem like it has to be one way or another. You could have
meaningful indentation and still use end for ambiguous cases. That
would be
nice. This would also be consistent with Ruby's optional parens for
function
use and declaration. Backward compatibility would also make it
possible to
make the transition.
J Haas
> Does anybody complain about terminating '}' in C, C++ or Java?
I do, now. Redundancy irritates me.
> Does anybody complain about terminating '.' on sentences?
If the period accounted for one-sixth of English text, perhaps they
would.
J Haas
> Implement it, post it on github, then post back here and see if people
> like it. These conversations in which people pretend to try to
> convince one another just to assert their views are much less
> productive than just solving whatever the original problem is.
Ugh, pass. I've wasted far too much of my life coding what I thought
were useful features for open-source projects only to find that the
committers didn't share my opinion. I ain't touching something like
this unless there's at least some reasonable chance the patch might
actually get accepted.
If you want to try this out, as I said earlier in this thread,
preprocessors exist. And seem to work, which kind of belies the claim
that this change would be impossible.
Charles Johnson
> 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
Rick DeNatale
wellwhydontwegetridofallpunctuationthingslikespacescommassemicolonsquotesetcperiodcertainlytakeupmuchmoreofourprosethantheydeserveandcapitalizationeatsupvaluableverticalspaceandnoneedforparagraphseparationeither
Seriously, if you measure things by avoiding extra keystrokes, get a
better editor. I value readability over parsimony of lexical items.
--
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
Michael Bruschkewitz
"J Haas" <Myr...@gmail.com> schrieb im Newsbeitrag
news:abacc69e-f80e-4ef0...@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.
Juan Zanos
That would be a valid criticism if J Haas's suggestion made things
less readable. But having to scroll less makes things more readable.
Joshua Ballanco
> 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.
Roger Pack
>
> 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
Joel VanderWerf
> 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
J Haas
> Seriously, if you measure things by avoiding extra keystrokes, get a
> better editor. I value readability over parsimony of lexical items.
Cluttering up your code with "end" everywhere makes it less readable,
not more.
On May 20, 9:01 am, "Michael Bruschkewitz"
<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 assigning
> 1-Point size to End-Only-Lines?
Aside from the fact that this wouldn't solve the problem that I'd
still have to _write_ the damned things, this is possibly the
kludgiest solution imaginable.
> Wouldnt this be the easiest way to solve your problem?
The easiest way to solve _my_ problem would be for me to use one of
the preprocessing scripts that impose Python-like indentation syntax
on Ruby. But that wouldn't solve the larger problem, which is that
Ruby could be better than it is.
On May 20, 10:04 am, Joshua 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.
Rick DeNatale
> 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.
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.
J Haas
> Yeah the inheritance chain thing is hard.
> The closest you can come is with modules.
> class Object
> override do
> def print *args
> super *(args + [" :-)"])
> end
> end
> 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.
> > def do_something(a, b, c):
> > { print a, b, c } # this works
> > a + b + c
>
> and then afterward it picks up the previous indentation? I
> suppose...that would work. It's an odd use for {}'s though which are
> already pretty heavily used.
True, and I'm not too thrilled with the solution, but maybe there's
something better. {} is heavily used, but on the other hand one of its
common uses is to divide code into blocks, and that's what it's doing
here.
> Overall I like the idea--making "end's" optional would indeed be kind.
> It is better than a similar idea I had recently, which was to use : for
> single line blocks (only), i.e.
>
> if a == b : do_something
> instead of
> if a == b; do_something; end
This suggestion is not at all incompatible with mine, and in fact
that's the way Python does it too (except you'd have to put parens
after do_something :)...
if a==b:
# Nothing follows the colon, so this starts a new scope indented
past the if statement
do_something()
do_something_else()
if a==b: do_something() # code follows the colon, so it constitutes
the entire block
do_something_else()
if a==b:
do_something_else() # error, the parser expects a new level of
indentation
if a==b: do_something()
do_something_else() # error, the parser does not expect a deeper
indent
> The other concern is that "the allure of magic indentation wears thin
> for large docs" which fact "worked to ensure you kept your methods
> short."[1]
Well, all I can say is, that's his opinion. Hasn't lost its allure for
me. And if it did lose its allure, I would think that it wouldn't be
for large docs, it would be for deeply _nested_ docs. I definitely
sympathize with his mockery of the notion that this limitation is a
blessing in disguise because it encourages you to keep your methods
short... it reminds me of how I felt when I first heard that Java's
lack of pointers meant you couldn't write any pointer bugs. But my
employer imposes a strict 80-column limit on source files including
Python, we have a lot of Python code, and it all works out.
> Also could parsers handle it?
I think so, especially since the preprocessor I've used (wish I could
remember its name... it's not Lazibi [1]) does it in a fairly clever
way in Ruby itself, so I don't see why the parser couldn't do what it
does.
Thanks for your comments, I appreciate the feedback.
Tony Arcieri
On Wed, May 20, 2009 at 1:10 PM, J Haas <Myr...@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
Tony Arcieri
On Wed, May 20, 2009 at 1:25 PM, Tony Arcieri <to...@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
Juan Zanos
On May 20, 2009, at 2:51 PM, Rick DeNatale wrote:
> On Wed, May 20, 2009 at 2:35 PM, J Haas <Myr...@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.
Joshua Ballanco
>> Also could parsers handle it?
>
> I think so, especially since the preprocessor I've used (wish I could
> remember its name... it's not Lazibi [1]) does it in a fairly clever
> way in Ruby itself, so I don't see why the parser couldn't do what it
> does.
A friendly suggestion: One of Ruby's strengths (one that it shares
with Perl) is its power to manipulate and parse strings. If you're new
to Ruby, a script which takes your colon/de-indent syntax and turns it
into the proper do/end syntax sounds like a great project to get
started. Since you desire to write Ruby code in this way, it would
also give you a great excuse to approach this problem using TDD. That
is, write the code in the way you would like it to appear as a test,
then write the parser/de-re-mangler to have the test pass. I honestly
think you could have done this with the same amount of effort as it
has taken to reply to each of the e-mails in this thread.
Let me be frank: Your suggestion is not new. Code speaks louder than
words. When you _do_ implement this alternative Ruby syntax, I think
you may be surprised at the number of corner and edge cases. Ruby is
currently in the process of being standardized. I would imagine the
last thing that Ruby needs while undergoing the standardization
process is a new, optional syntax with a multitude of corner and edge
cases.
Cheers,
Josh
Gregory Brown
>
> On May 20, 2009, at 2:51 PM, Rick DeNatale wrote:
>
>> On Wed, May 20, 2009 at 2:35 PM, J Haas <Myr...@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.
>
> scrolling 16% more often? That must have some cost to readability.
If you break up code into more files, or use a folding editor, or use
an editor that lets you jump to code by a method name, scrolling is a
non-issue.
Rick's point remains. If this is an issue you're facing, get a better editor.
-greg
Robert Klemme
> 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/
Martin DeMello
>
> 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
J Haas
> I already responded to this. I guess you didn't see it.
I responded to your response, I guess you didn't see _that_. Tell me
what's wrong with the following alternatives to your examples:
> if foo
> blah
> elsif bar
> blah2
> else
> baz
Just like with your case example before, whoops! You're missing an
end, and the parser will complain when it sees the end-of-file without
a missing end. And just as I said with your case example before, I
sure hope this missing end isn't in the middle of a long file or you
get to spend a lot of time scrolling through your code looking for the
place where it's missing.
But if we amend your example to
if foo
blah
elsif bar
blah2
else
bar
end
...I really don't see what's wrong with this as an alternative:
if foo:
blah
elsif bar:
blah
else:
bar
No end necessary.
> Begin statements (ala try/catch in Python)
>
> begin
> somecode
> morecode
> rescue FooError
> some_rescue_action
> rescue BarError
> another_rescue_action
> ensure
> something_gets_done
Again, you're missing an end. Applying the same pattern I applied in
the if and case examples, I do not see what the problem is. How is it
any less functional than the current Ruby?
> Each of these statements is an expression with multiple clauses. How do you
> tell when these expressions are complete? Obviously a naive "dedent = end
> of expression" approach doesn't work in these cases.
Okay, I think I see what you're saying now. But each of those also, in
the clauses after the first one, begins with a keyword that is not
valid except as part of the previous expression. Does it solve the
problem if dedenting ends an expression unless it's immediately
followed by a keyword that makes no sense except as a continuation of
the expression?
> This doesn't work in a language where everything is an
> expression, because all expressions must be treated the same and all
> expressions must have an expression terminator (newline or semicolon)
You keep on saying this, yet I have not seen one example of code that
demonstrates that using dedent couldn't work. Basically, we're looking
for some code which, if you removed the all ends, a script following
simple deterministic rules would not be able to unambigiously decide
where to put them back. I agree that "put an end wherever you see a
dedent" is naive and wouldn't work... but "put an end wherever you see
a dedent which isn't followed by a keyword which extends the current
expression, such as elsif or rescue or ensure" might.
pat eyler
> On May 20, 8:51 am, 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.
--
thanks,
-pate
-------------------------
Don't judge those who choose to sin differently than you do
http://on-ruby.blogspot.com
http://eldersjournal.blogspot.com
Juan Zanos
On May 20, 2009, at 3:50 PM, Gregory Brown wrote:
> On Wed, May 20, 2009 at 3:44 PM, Juan Zanos
> <juan_...@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 <Myr...@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.
Ryo Furue
> On Wed, May 20, 2009 at 3:44 PM, Juan Zanos <juan_za...@talkhouse.com> wrote:
>
> > On May 20, 2009, at 2:51 PM, Rick DeNatale wrote:
>
>
> >>> On 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.
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
Joel VanderWerf
> I'm willing to admit that Python programs are generally shorter
Are you sure of that? Care for a round of golf?
Gregory Brown
> 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.
Roger Pack
>>
>> 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
Tony Arcieri
On Wed, May 20, 2009 at 2:30 PM, J Haas <Myr...@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
Gregory Brown
> On May 20, 9:50 am, Gregory Brown <gregory.t.br...@gmail.com> wrote:
>> Rick's point remains. If this is an issue you're facing, get a better editor.
>
> But, the amount of meaningful code displayed in a single screenshot
> still suffers. A screenful is a chunk of code
> you can see without scrolling or jumping. The more meaning it
> contains, the better you understand the code (as long as the meaning
> is cleanly laid out, of course).
I still think this is a straw man. I'm rarely concerned with the
'readability' of a whole page of code.
I feel like there is something wrong with my design when I have to
think at that level.
For what it's worth, I actually can care less whether whitespace is
significant or not. Significant whitespace doesn't bother me in Haml.
The lack of significant whitespace doesn't bother me in Ruby.
What does bother me is that people somehow think this issue is so
important and dire, yet they think it's someone else's job to fix it.
If you want Ruby with significant whitespace, build it. Don't try to
convince folks who don't care about the issue.
-greg
Juan Zanos
I'm saying that when all other factors are held constant more lines is
less readable. Your arguments ignore that and only place value on
editors and project management when the extra lines exist and
not when they don't. That's not a level playing field.
Thinking about ways to reduce this overhead in the language is good.
Gregory Brown
> I'm saying that when all other factors are held constant more lines is
> less readable. Your arguments ignore that and only place value on
> editors and project management when the extra lines exist and
> not when they don't. That's not a level playing field.
You're right. I should note that better design also mitigates most
of the concerns about the problems of whitespace significance (for
me).
But that doesn't invalidate my feeling that this whole stirrup about
'readability' is a straw man at best, and an indication of a poor
ability to write clean code without extra help at worst.
> Thinking about ways to reduce this overhead in the language is good.
And implementing them is great. Because it solves your problem for
you, and does not require convincing others that it is a problem.
Those who do find this desirable will use it. So what's stopping you?
-greg
Gary Wright
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
Tony Arcieri
On Wed, May 20, 2009 at 2:45 PM, Tony Arcieri <to...@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
Tony Arcieri
On Wed, May 20, 2009 at 4:18 PM, Tony Arcieri <to...@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
Juan Zanos
On May 20, 2009, at 5:41 PM, Gregory Brown wrote:
> On Wed, May 20, 2009 at 5:23 PM, Juan Zanos
> <juan_...@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.
Gregory Brown
That's right. I'm pretty awesome. Maybe RubyTalk can throw a party
in honor of me!
(But seriously, I'm just saying that design is multi-faceted, and
conciseness isn't a single pointed goal one can optimize for to any
great effect)
-greg
Steven Arnold
On May 20, 2009, at 4:31 PM, pat eyler wrote:
> And you're on a mailing list full of people who find that the Ruby-way
> makes sense to them. Don't knock it until you've tried it.
Just to kick in on this, I am a long-time Ruby programmer and Ruby is
my favorite language. I'd rather see full-strength macros than
optional removal of 'end' keywords. Having said that, let me admit I
do not know how complex it would be to implement a solution in Ruby
that optionally omits ends. Some have argued, with what seem like
plausible reasons, that it might be hard. Others have attempted to
rebut those reasons. I agree with the calculus that if it is very
difficult, it is not worth the benefit. If it is easy, I'd like to be
able to omit the 'end' statements. They are line noise to me
visually. They just get in the way.
Another concern I have about this idea, though, is having essentially
two forks of Ruby lexically speaking. It's not much of an obstacle,
but it is a minor difference that someone who comes along later to
maintain your code might find confusing or off-putting. And even
though this particular change might be relatively minor, where do we
draw the line? What makes us decide whether another optional syntax
change should be integrated into the language? Even many small
changes add up to a big difference in the way the code looks and the
ease of maintainability.
I guess, however, this is no more serious than the positioning-of-
brackets debate in C or even whether bracketless 'if' statements
should ever be used, e.g.:
if (foo)
bar();
baz();
The 'baz' function will execute regardless of the value of foo; this
code is therefore visually confusing.
Macros, as I suggested above, would _really_ move in the direction of
potential Ruby code that looks radically different. But the payoff
would be enormous expressive power, the ability to mold the language
to suit the application domain in a very comprehensive way. The
removal of 'end', by contrast, would be only a slight improvement. It
would remove some visual noise and might attract a few Python
programmers. As I said, I think it's worth it if it's easy to
implement, but not if it's more difficult.
steven
Bill Kelly
From: "Tony Arcieri" <to...@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
J Haas
Okay. But just to recap what's gone before: you've said all along that
Pythonic indentation in Ruby was impossible. It's impossible, because
it's incompatible with blocks. It's impossible, because everything's
an expression. It's impossible, because Guido said so. And I've asked
you over and over for an example demonstrating its impossibility.
You've had time to think it over, you were under no constraints, and
this is what you've come up with.
I found the old preprocessor script from awhile ago that I mentioned
earlier in this thread. I've pastebinned it at http://pastebin.com/m5fee1e92.
It's very short, and pretty simple. I have no doubt that it would need
a lot of work to be robust. (In particular, I think things need to be
added to the enumeration at line 68.)
But Tony, it blasted through your "impossible" example without
skipping a beat, working perfectly on the first try.
jhaas@littlefinger:~/pyruby$ cat pyrbtest.rb
__BEGIN__
# Look, ma! No ends!
foo = [1,2,3]
x = foo.map do |n|:
n += 1
n *= 2
result = case x:
when Array
x.map! do |n|:
n *= 3
n += 4
when NilClass
x
result = if result.size > 10:
result[0..2]
else:
result
p result
jhaas@littlefinger:~/pyruby$ irb
irb(main):001:0> require 'pyruby'
=> true
irb(main):002:0> require 'pyrbtest'
[16, 22, 28]
=> true
As I've said repeatedly, I don't follow your reasons for claiming that
this is impossible. Can you come up with a better demonstration?
J Haas
> n = 2 * -[1,2,3,4,5].inject(0) do |a, b|
> c = a * 2
> a * c + b
> end
> result = 8 * -if n > 0
> -n += 10000
> else
> n + 500000
> end
> puts result
__BEGIN__
n = 2 * -[1,2,3,4,5].inject(0) do |a, b|:
c = a * 2
a * c + b
result = 8 * -if n > 0:
-n += 10000
else:
n + 500000
puts result
Once again, worked perfectly on its first time through the
preprocessor.
J Haas
> I found the old preprocessor script from awhile ago that I mentioned
> earlier in this thread. I've pastebinned it athttp://pastebin.com/m5fee1e92.
Sorry for the repeated posts, but I forgot to mention: I did not write
this, although I did make minor modifications. I don't recall where I
found it, and Google was no help. I regret that I cannot credit the
author; should he happen to be reading this, speak up!
Steven Arnold
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
James Britt
>>
> 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
Roger Pack
> 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.
Steven Arnold
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
Tony Arcieri
On Wed, May 20, 2009 at 11:29 PM, Bill Kelly <bi...@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
Yossef Mendelssohn
> (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
Tony Arcieri
On Thu, May 21, 2009 at 4:29 PM, Ryan Davis <ryand...@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
Tony Arcieri
On Thu, May 21, 2009 at 5:20 PM, Tony Arcieri <to...@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
Tony Arcieri
On Thu, May 21, 2009 at 10:27 PM, J Haas <Myr...@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
Tony Arcieri
On Thu, May 21, 2009 at 10:27 PM, J Haas <Myr...@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
Juan Zanos
The Ant XML example is a bit ironic. Ant's creator regrets using
XML. He believes that he should have used a scripting language
instead. Take a look at Rake and you'll see a DSL that does what Ant
does and more.
James Britt
>
> 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.)
--
Ryan Davis
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).
Joshua Ballanco
>
> As I've said repeatedly, I don't follow your reasons for claiming that
> this is impossible. Can you come up with a better demonstration?
>
First, let me say thank you for the code. This community thrives on
code, not on bickering. More code is always a good thing. That said...
> cat tough.rb
# "end" can make things clearer, sometimes...
result = case ARGV[0]
when /^\d*$/
"That's an integer!"
when /^[A-Za-z]*$/
"That's a word!"
else
"That's something that's not an integer or a word..."
end if ARGV[0]
puts result
Jörg W Mittag
> 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
> 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
Reid Thompson
> 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.
>
>
input code, attempting to place 'end' in the proper place based on
indentation. It breaks silently if you happen to misplace your
whitespace incorrectly, placing an 'end' in the wrong place.
Roger Pack
> 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).
J Haas
> 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.
J Haas
> It doesn't really. Or at least only simplistically; by re-writing the
> input code, attempting to place 'end' in the proper place based on
> indentation. It breaks silently if you happen to misplace your
> whitespace incorrectly, placing an 'end' in the wrong place.
As I said when I posted it:
> It's very short, and pretty simple. I have no doubt that it
> would need a lot of work to be robust.
In its present form, this is not something I want to do in production
code. It does however serve at least one valuable purpose: it
demonstrates that the code snippet that Tony posted, that he
specifically contrived as an example of a piece of Ruby code that
would be utterly impossible to parse without 'end' statements, was in
fact quite easily parsable.
Roger Pack
> 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.
Tony Arcieri
On Fri, May 22, 2009 at 9:30 AM, J Haas <Myr...@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
Michael Bruschkewitz
"J Haas" <Myr...@gmail.com> schrieb im Newsbeitrag
news:3dd501b0-84bc-4781...@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#?
James Britt
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
> 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.
Reid Thompson
> 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.
>
error when indentation is fouled.
James Britt
Sure, if in fact the indentation is fouled.
My concern is that you can mistakenly add 4 spaces instead of two, or
vice versa, and get valid code (i.e. the parser does not see anything
technically wrong) yet not have the code you really wanted.
James
Bill Kelly
From: "James Britt" <james...@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
Yukihiro Matsumoto
|A valid objection that was raised in the earlier thread was regarding
|a quick and easy and common debugging technique: throwing in print
|statements
|
| def do_something(a, b, c)
|print a, b, c # for debugging purposes
| a + b + c
| end
|
| def do_something(a, b, c):
|print a, b, c # error! unexpected indentation level
| a + b + c
| end
Despite some might expect, I am not fully against block-by-indentation
a la Python, as long as
* we keep end and brace blocks as well, of course.
* prohibit mixing tabs and spaces in indentation mode
* nice and compatible syntax. for compatibility and other reasons,
colons do not work for block-by-indentation-marker.
I haven't found any good syntax so far. Besides that 'end's and
braces often work nice for my eyes.
matz.
J Haas
> 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.
David Masover
> 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.
John W Higgins
On Mon, May 25, 2009 at 9:40 AM, J Haas <Myr...@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
Caleb Clausen
> Now, having said all that: I do not _know_ that Tony's claim is false.
> As I said, I was surprised to be told that my proposal was impossible
> and I lack the theoretical background to prove otherwise. So if anyone
> out there agrees with Tony that Pythonic indentation in Ruby would not
> be merely ill-advised but _impossible_ I'd appreciate an example. Then
> I can stop wasting my time.
It's certainly not impossible, as the script you posted shows. That
script is a hack, however, since it doesn't lex its input properly and
it will fail in obscure cases. I've written a proper implementation,
based on my RubyLexer library.
Basically, it makes the end keyword optional. If you leave off the
end, the preprocessor inserts an end for you at the next line indented
at or below the level of indentation of the line which started the scope.
End is optional, so you can still write things like this:
begin
do_something
end until done?
(However, you'd better make damn sure you get the end indented to the
right level!)
This script uses RubyLexer to extract a stream of tokens and modify
it, then turn those tokens back into ruby code. Since RubyLexer is a
complete stand-alone lexer, this should be a very thorough solution,
free of insoluable little problems due to the script's inability to
follow where comments and strings start and stop. (That said, I'm sure
there will be some problems with it, as it's pretty raw code.)
As different programs have a variety of interpretations as to the
width of a tab character, tabs for indentation are absolutely
forbidden by endless.rb.
If you're interested, please see:
http://gist.github.com/117694
David Masover
> My concern is that you can mistakenly add 4 spaces instead of two, or
> vice versa, and get valid code (i.e. the parser does not see anything
> technically wrong) yet not have the code you really wanted.
You can get the same problem by misplacing a bracket or a paren. The only
difference I see is that the indentation is a lot more visibly obvious.
Joshua Ballanco
On May 25, 2009, at 9:40 AM, J Haas wrote:
> As I said, I was surprised to be told that my proposal was impossible
> and I lack the theoretical background to prove otherwise. So if anyone
> out there agrees with Tony that Pythonic indentation in Ruby would not
> be merely ill-advised but _impossible_ I'd appreciate an example. Then
> I can stop wasting my time.
I was on a questionable connection at the time, so my original message
may not have gotten to the mailing list:
> cat impossible.rb
# This one can't be done in Pythonic style:
result = case ARGV[0]
when /^\d*$/
"That's an integer!"
when /^[A-Za-z]*$/
"That looks like a word..."
else
"That's not an integer or a word."
end if ARGV[0]
puts result if result
Cheers,
Josh
James Britt
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=).
Caleb Clausen
> 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.
Michael Bruschkewitz
"David Masover" <ni...@slaphack.com> schrieb im Newsbeitrag
news:200905251330...@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.
Roger Pack
> 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!
sunnia
> 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
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’t intend to
overload your email with unnecessary messages…
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:
“And remember David and Solomon, when they gave judgment concerning
the field when people’s 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.” (Quran
21:78-79)
God also says:
“O 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.” (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:
“So 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.” (Quran 5:49)
God also says:
“…And if you judge (O Muhammad), judge between them with justice.
Verily, God loves those who act justly.” (Quran 5:42)
And He says:
“But 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.” (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:
“If 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.” (Ahmed)
God’s Messenger said:
“You 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.” (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:
“The Muslims are unanimously agreed that a judicial system must be
established for the people.”
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:
“O you who believe! Stand out firmly for justice...” (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:
“People have to have a judicial authority or their rights will
disappear.”
The duties of the judiciary include enjoining what is right, helping
the oppressed, securing people’s 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.
———————————-
For more information about Islam
http://www.islambasics.com/index.php
http://www.islamtoday.net/english/
http://www.islamweb.net/ver2/MainPage/indexe.php
Contact Us At
J Haas
> 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
Reid Thompson
'end's included
Alex
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
Eleanor McHugh
> I find this code less readable than the above original code with the
> 'end's included
+1 - the significant white space is one of several reasons I've never
managed to get comfy with python.
Personally I like 'end' because it makes it explicitly clear that the
programmer's intent was to end a block at that point, and I've wasted
enough of my life tracking down nesting errors not to want to give up
that extra bit of insight. If other people feel differently, well it's
there code and they're free to do as they please with it so long as
I'm not expected to maintain it.
Ellie
Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
Tony Arcieri
On Wed, May 27, 2009 at 10:41 AM, Reid Thompson <reid.t...@ateb.com>wrote:
> I find this code less readable than the above original code with the
> 'end's included
>
I like the symmetry that end statements give to the code. It feels more...
balanced or something.
--
Tony Arcieri
medioh.com