What is the reason for this syntax?

Hello I have been using ruby off and on for a few months and I have been
having a great time with the language but a few things bother me about
the syntax of the language itself. The two glaring issues are:

  1. The syntax errors generated by the following code:

a.each
do
#stuff
end

for reasons I do not understand ruby demands that, that line be written
as:
a.each do
#stuff
end

Quite frankly I find the second form to be more difficult to read
especially if one tends to create blocks with braces rather than the do
end keywords like I do. Is there some specific reason that both forms
are not supported by Ruby? It is needlessly restrictive with respect to
formatting in my opinion, perhaps a kind ruby-core developer could sneak
this syntax change into a future release?

  1. What is with the elseif syntax specifically why is it elsif instead
    of elseif when ruby already has an else keyword? I can’t count how many
    times I got errors because I decided to type elseif instead of elsif
    while doing something with an if statement. I can name at least two
    popular languages that use elseif not to mention the fact that if
    English is your first language you will probably spell out else without
    even realizing it since that is the correct way to spell the word in
    English. Yes I know its a minor thing but if no one voices their
    gripes how do people know something might need a bit of tweaking? :slight_smile:

Kevin:

  1. That is how it works and for me syntax #2 looks more easier.

  2. elsif is same one we use in perl.

Ruby has more perl in it than python. It seems like you were a python
programmer that’s why. I am perl programmer that this is natural to me.

Kevin O. wrote:

In Ruby an expression continues on the next line if syntax
unambiguously shows that the expression is incomplete.

In this case “a.each” is a complete expression by itself (a method call
with no arguments and no block), and so the “do” on the following line
occurs without anything to take the block.

Vidar

Kevin O. wrote:

for reasons I do not understand ruby demands that, that line be written as:
a.each do
#stuff
end

In ruby statements are terminated by newlines and block is a parameter
to the each method here, consider:

def meth *args
end

meth
1,2

what is Ruby supposed to do in such situation ? In your case you are
calling the each method without any argument and supplying another
statement:

do
end

which obviously is wrong

On the other hand Ruby allows breaking statements when situation is more
obvious:

def meth *args

end

meth 1,
2

Quite frankly I find the second form to be more difficult to read
especially if one tends to create blocks with braces rather than the do
end keywords like I do. Is there some specific reason that both forms
are not supported by Ruby? It is needlessly restrictive with respect to
formatting in my opinion, perhaps a kind ruby-core developer could sneak
this syntax change into a future release?

Nope, they are not equivalent. The {} form binds tighter than do end.

def meth,arg
yield
end

and:

meth a do

end

block applied to the meth method

meth a {

}

block applied do a (which could be a method call) and the result of a
block would be passed to the meth method

lopex

On Oct 4, 2006, at 3:39 PM, Kevin O. wrote:

end

for reasons I do not understand ruby demands that, that line be
written as:
a.each do
#stuff
end

Blocks are part of the syntax of a method call (do/end or {})
Blocks are optional.
Newlines terminate statements.

The net result of those three things is that:

a.each

is considered a syntactically valid and complete statement. Leaving
Ruby to try
to interpret

do
#stuff
end

as the next statement, which fails. If Ruby executes
‘a.each’ (without the
block) you’ll get a runtime exception. It is correct syntax, but
‘each’ insists
that it be called with a block.

You could of course give a hint to the parser that you want to
continue the statement:

a.each \
do
#stuff
end

but escaping the newline in this case doesn’t improve the readability
(IMHO).

  1. What is with the elseif syntax specifically why is it elsif
    instead of elseif when ruby already has an else keyword? I can’t
    count how many times I got errors because I decided to type elseif
    instead of elsif while doing something with an if statement. I can
    name at least two popular languages that use elseif not to mention
    the fact that if English is your first language you will probably
    spell out else without even realizing it since that is the correct
    way to spell the word in English. Yes I know its a minor thing
    but if no one voices their gripes how do people know something
    might need a bit of tweaking? :slight_smile:

I doubt a survey of languages would come up with any sort of
consistency for the keyword in this case, so you are basically asking
why doesn’t Ruby use the same syntax for the particular languages
that you are familiar with, which seems like a somewhat arbitrary
expectation and one that could never be satisfied for everyone.

I’m not a parsing/grammar expert, but I also suspect there is some
benefit to keywords not being prefixes of other keywords so that
‘else’ and ‘elseif’ create more parsing issues than ‘else’ and
‘elsif’. I’m sure someone else could elaborate on that thought.

Gary W.

Just Another Victim of the Ambient M. wrote:

been having a great time with the language but a few things bother me
as:
a.each
The following code:
#stuff
You could of course give a hint to the parser that you want to continue

I doubt a survey of languages would come up with any sort of consistency

In fact, Ruby has deep Perl roots, which is why so much of its syntax 

is so Perl-like (just note its regular expressions). Perl uses “elsif”
and, thus, so does Ruby. Personally, I don’t like it either but what can
you do…

Thank you all for your explanations of the syntax I pointed out. All I
really want with respect to the blocks is the freedom to put the braces
where I like without escape sequences of course. The elsif thing I can
pretty much avoid with a case the majority of the time just as I do in
VB. (Cases for t3h win!! :P) It could be worse though this could be Bash
with elif and fi to close an if >:o

Just to add to a very good response to the original post…

[email protected] wrote in message
news:[email protected]

do
Blocks are optional.
do
#stuff
end

The following code:

a.each
do
#stuff
end

...is the equivalent of to:

a.each; # note the optional statement terminator…
do
#stuff
end

do

two popular languages that use elseif not to mention the fact that if

I’m not a parsing/grammar expert, but I also suspect there is some
benefit to keywords not being prefixes of other keywords so that ‘else’
and ‘elseif’ create more parsing issues than ‘else’ and ‘elsif’. I’m
sure someone else could elaborate on that thought.

In fact, Ruby has deep Perl roots, which is why so much of its 

syntax
is so Perl-like (just note its regular expressions). Perl uses “elsif”
and, thus, so does Ruby. Personally, I don’t like it either but what
can
you do…

David V. wrote:

Not in a semicolon-free language, I’m afraid. And if nothing else, this
reinforces use of a common style convention, which is a Good Thing.

Well let’s not go too far down that path, now, or we might add something
horrid like syntactic indentation…

Charles Oliver N. wrote:

Well let’s not go too far down that path, now, or we might add something
horrid like syntactic indentation…

I like Python syntax, actually. It just takes a while for your brain to
stop breaking at the thought of pressing backspace meaning “end block”
:wink:

David V.

On 10/6/06, David V. [email protected] wrote:

Kevin O. wrote:

Thank you all for your explanations of the syntax I pointed out. All I
really want with respect to the blocks is the freedom to put the braces
where I like without escape sequences of course.

So, use a ‘’ at the end of a line to indicate it continues on the
next. Not the end of the world.

Martin

Kevin O. wrote:

Thank you all for your explanations of the syntax I pointed out. All I
really want with respect to the blocks is the freedom to put the braces
where I like without escape sequences of course.

Not in a semicolon-free language, I’m afraid. And if nothing else, this
reinforces use of a common style convention, which is a Good Thing.

Most of the people willing to fight vocally for the freedom to ignore
indentation and code style guidelines I’ve met never used CVS to see
just how horribly two people that have different autoformatting set in
their editors / IDEs confuse diff…

David V.

On 10/5/06, Charles Oliver N. [email protected] wrote:

David V. wrote:

Not in a semicolon-free language, I’m afraid. And if nothing else, this
reinforces use of a common style convention, which is a Good Thing.

Well let’s not go too far down that path, now, or we might add something
horrid like syntactic indentation…

Exactly what I was thinking. On the other hand, although I don’t care
for Python, the whitespace thing doesn’t bother me in Haskell. I
don’t know why, but I get the feeling that it wouldn’t be so bad in
Ruby code either, but it’s just a guess.

To tell the truth, I do wish there was a visible statement seperator
though (semi-colon). I find this

some_long_variable name = long_expression_which_needs
  + to_break_across_lines;

 method
   .chaing
   .is.more.noticiable;

to be more readable than:

some_long_variable name = long_expression_which_needs +
  to_break_across_lines

method.
  chaining.
  stands.out.less

Also, a syntax for associating more than one block with a method would
be nice too.

Of course these are minor gripes. As it is often cited, ruby is a
beautiful language.

On 10/6/06, Jean H. [email protected] wrote:

As far as I know nothing prevents you from using a semi-colon at the
end of your statements if you wish …

Sure you can, but that solves a different problem really. If you want
to continue with more than one expression per line, reach for the
semicolon. You see this idiom a lot when building up a hash with
inject.

some_enumerable.inject(Hash.new(0)) {|h, i| h[i]+= 1 ; h}

Since the semicolon is not required though–i.e.: an endline is a
valid separator–you must leave the line in a place such that the
parsing will be unambiguous. Lines need to be broken after operators
rather than before. The reason you would want it the other way around
is so that you can see what’s going on in the code by scanning the
beginning of the lines.

People really should be able to write code in the way that they
understand they shoulf not need to concern themselves with wrapping
their minds around a contrivance of the language they happen to be
using to get something done. Things like requiring the use of the
ternary operator (A special form of if in c/c++) in certain situations
are just mistakes on the part of the people who created the language.

I’m very glad I bothered to bring this up since at least now I have a
workaround until such time that the defacto requirement for K&R style
indentation with respect to blocks is removed. I doubt any of us
would think it good to disallow the use of single letter variables in
Ruby simply because the makers all happen to think that single letter
variables are bad formatting. (Which they are but as long as you keep
them to blocks they are fine in Ruby anyway.) People would be better
served encouraging people to use comments in code other people could
reasonably be expected to need or want to read rather than forcing
users to use obscure forms of some structures, or building in silly
things like syntactic indentation that expects you to judge whitespace
for the beggining and ending of various things.
It really does not matter how neat syntactically a language is if you
do not explain what your code is doing especially in a language such
as this that does not require explicit declaration of variables as
well as support (to an extent at least.) for implicit conversion of
data types.

These features do encourage what could very well be considered bad
programming ppractice since variables can pretty much appear anywhere
with no readily apparent indication of how they got there. (blocks) I
cannot express how thankful I am that ruby-core documentation is
generally incredibly well written and detailed as it offsets a great
deal of the potential WTF factor that this language could produce.

I was also wondering is there a way to not have to write the
following:

magick::fobar.blah
or simillar when using libraries?
further more what exactly is magick:: supposed to be called?

On 10/6/06, Louis J Scoras [email protected] wrote:

don’t know why, but I get the feeling that it wouldn’t be so bad in
Ruby code either, but it’s just a guess.

To tell the truth, I do wish there was a visible statement seperator
though (semi-colon). I find this
[…]
As far as I know nothing prevents you from using a semi-colon at the
end of your statements if you wish …
see :

irb(main):001:0> class A; def t; @t||=[];end;end;
irb(main):002:0* a=A.new
=> #<A:0x100d29e8>
irb(main):013:0> u=a.
irb(main):014:0* t.
irb(main):015:0* length;
irb(main):016:0* u
=> 0

it does work so if you have some really long statement on multiple
lines and you want a visual marker at the end, go ahead, semi-colon
works just fine

Sorry for jumping in mid-thread, but…

Kevin O. wrote:

People really should be able to write code in the way that they
understand they shoulf not need to concern themselves with wrapping
their minds around a contrivance of the language they happen to be
using to get something done.
Everything is a contrivance of the language you’re using in some
respect, no matter which language you’re talking about.

Things like requiring the use of the
ternary operator (A special form of if in c/c++) in certain situations
are just mistakes on the part of the people who created the language.
Where are ternary operators required?

I’m very glad I bothered to bring this up since at least now I have a
workaround until such time that the defacto requirement for K&R style
indentation with respect to blocks is removed.
Why would it be removed? The current situation is consistent, clear and
easy to understand.

<snip an argument I didn’t follow>

It really does not matter how neat syntactically a language is if you
do not explain what your code is doing especially in a language such
as this that does not require explicit declaration of variables as
well as support (to an extent at least.) for implicit conversion of
data types.
I think what you’re saying is that if you don’t understand a language,
it won’t be obvious what’s going on. Welcome to the learning curve!
I’m not sure if you’re arguing for type coercion or not here, but that
way lies (more or less) religious arguments in which Ruby’s position is
clear and well-known.

I was also wondering is there a way to not have to write the following:

magick::fobar.blah
or simillar when using libraries?
further more what exactly is magick:: supposed to be called?
In this case, Magick would be a module. The same syntax can be used for
classes, though. If you want to short-cut it, you can say:

include Magick
Fobar.blah

The ‘include Magick’ line adds the Magick module to the list of places
that are searched for the Fobar class.

Vidar H. wrote:

In Ruby an expression continues on the next line if syntax
unambiguously shows that the expression is incomplete.

So why can’t the parser continue a statement on to the next line if the
syntax unambiguously shows that the expression on the next line is the
continuation of the line before it, such as lines starting with do or
.foo which are incorrect otherwise?

On Oct 6, 2006, at 11:15 AM, Kevin O. wrote:

I’m very glad I bothered to bring this up since at least now I have a
workaround until such time that the defacto requirement for K&R style
indentation with respect to blocks is removed.

I’m not sure where you are going with this but I think it is terribly
misleading to think of Ruby blocks (do/end and {}) as in any way similar
to the blocks deliminated by {} in C. They use the same punctuation,
but
beyond that they have vastly different semantics and so I’m not sure how
it follows necessarily that their textual representation would be
similar.

I was also wondering is there a way to not have to write the
following:

magick::fobar.blah
or simillar when using libraries?
further more what exactly is magick:: supposed to be called?

Sure you can write:

magick.foobar.blah	# instead of using the scope :: operator

or you can create a temporary reference

fb = magick::foobar
fb.blah

I think there are two schools of thought on the :: scope operator.

  1. Only use it to access constants:

    Math::PI

  2. Use it as in 1) but also use it when calling class methods:

    Math::sin(0)

Its use in 1) is required, that is the only way you can access
constants within
modules or classes.

Its use in 2) is a style choice. Ruby is just as happy to access
class methods
using the dot notation:

Math.sin(0)

For method and constant lookup you can create shortcuts by using
include:

PI # uninitialized constant
include Math # add Math to the search path for constants and methods
PI # OK now because Math is searched also

So in your example, if magick was a module (Magick) and foobar was a
constant (Foobar)
you could do:

Magick::Foobar	# explicit access
Foobar.blah	# error
include Magick	# include Magick in method/constant lookup path
Foobar.blah	# ok now

This also works if foobar is a method for similar reasons but Magick
has to be a module
for include to work, and the include has to be executed in a module
(or top level) scope.

You could also use ‘extend’ to make a particular object search Magick
for methods and
constants:

class A; end
a = A.new
a.foobar	# error
a.extend Magick
a.foobar

Gary W.

On 2006.10.07 00:50, John T. wrote:

Vidar H. wrote:

In Ruby an expression continues on the next line if syntax
unambiguously shows that the expression is incomplete.

So why can’t the parser continue a statement on to the next line if the
syntax unambiguously shows that the expression on the next line is the
continuation of the line before it, such as lines starting with do or
.foo which are incorrect otherwise?

It might require arbitrary parsing lookahead or other facilitation at
the parser/lexer level.

In any case, I just suggest getting over it (pun intended) and falling
in line (muhahaa) with the normal Ruby layout :slight_smile:

Kevin O. wrote:

People really should be able to write code in the way that they
understand

Let me introduce you to Real Life. This specific variant of that
interesting game has you working as a programmer. And lo and behold, you
work on a project with several people on it. And it’s highly probable
some 75%-90% of your work will be in a team, and some of that will be
either maintaining code written by others, or writing code others
maintain.

People should write code OTHERS will understand. Irregardless of your
personal preference, you are to use the prevalent / official convention
in a given language when writing any nonpersonal code.
Whitespace-sensitivity flames aside, this is one of the points on which
Guido van Rossum is so right it ain’t funny anymore.

ternary operator (A special form of if in c/c++)

Ternary operator isn’t a special form of if in C or C++. I don’t feel in
the mood for prechewing and spoonfeeding, so no code snippets today.

Also, for heaven’s sake, LEARN a programming language before you flame
it.

I have a workaround

Which you shouldn’t use.

[snip rest of rant]

David V.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs