Elseif?

ruby-talk
1

Yuk! Ruby was presented to me as a 'clean' language.
Aliases are -- in my not-so-humble-opinion -- an abomination.
Aliases mean that when reading someone else's code you have to remember TWO things instead of one.
They serve no purpose except the preservation of the status quo of a cat-heard of programmers.

But then, my first language was 1620 machine language.
Not even mnemonics, just a string of numbers to program the beast...

···

Daniel Carrera wrote:

> I don't think that Ruby is a democracy. :slight_smile:

And that's a good thing.

> (... I think that there is such thing
> as too many ways to do it).

But we already have aliases all over the place in the classes
and libraries. Look at just the Array class:

  collect! map!
  size length
  indices indexes
  slice
  to_ary to_a

And one of them is just a change of spelling.

Seems like adding an 'elseif' alias is a simple and
forward-looking thing to do. Drop 'elsif' some day.

And I don't buy the premise that 'elseif' is harder than 'elsif'.
They're both pronounced "else if", right?

--
Mike Hall

2

Hi,

But we already have aliases all over the place in the classes
and libraries. Look at just the Array class:

collect! map!
size length
indices indexes
slice
to_ary to_a

Yuk! Ruby was presented to me as a ‘clean’ language.
Aliases are – in my not-so-humble-opinion – an abomination.
Aliases mean that when reading someone else’s code you have to remember TWO things instead of one.
They serve no purpose except the preservation of the status quo of a cat-heard of programmers.

I used to think these kinds of aliases were kind of quirky when I first read
through Pickaxe learning Ruby… However, in some code I wrote last night,
I used collect and map one right after another. Because the particular
naming in this context seemed more appropriately analogous to what the
code was doing… The lines are:

image_filenames.map! {|fname| File.basename(fname, “.jpg”) }

bead_shots = image_filenames.collect {|fname| BeadShot.new(fname) }

…See? 'Cause I wanted to “map” the filenames to some alternate
arrangement; but I wanted to “collect” BeadShot objects from the
filenames! :slight_smile: I thought it was pretty cool that Ruby allowed me to
specify my intent in a way that seemed so natural to me… I could
envision using :size vs. :length similarly…

(to_ary and to_a? well… dunno about that :slight_smile:

Just my thoughts . . .

Regards,

Bill

···

From: “Ted” ted@datacomm.com

3

Ted wrote:

Yuk! Ruby was presented to me as a ‘clean’ language.
Aliases are – in my not-so-humble-opinion – an abomination.
Aliases mean that when reading someone else’s code you have to remember TWO things instead of one.
They serve no purpose except the preservation of the status quo of a cat-heard of programmers.

Yes they do. They provide information about intent. Granted, some
aliases have little variance between the meanings, but when you are
reading someones code, there are two things going on. What does it do
and why does it do it? The first is closely knit to the love of the
“There is only one way to do it”, since it is easier to figure out what
the code actually does. (Python?) IMHO, that is akin to treating the
human brain like a compiler.

The “Why does it do it”, is the perspective of sane fans of TIMTOWDY.
(Ruby?) Unfortunately, some other (insane) fans of TIMTOWDY manage to
drop both the why and the what. (Perl?) The discussion about the
proposals of the Stack and Queue aliases is a good example of a sane use
of TIMTOWDY. There is so much power in Ruby, that using descriptive
aliases communicating intent is like using those eclipse glasses: With
them you can stare at the Sun without going blind. (I.e. understand how
someone uses an Array without going mad.)

But I’m not for the elseif alias, though. Keywords are sacred and should
be kept to a minimum. If anything, howsabout dumping it all together and
parse the combination “else if” specially?

···

–
([ Kent Dahl ]/)_ ~ [ http://www.stud.ntnu.no/~kentda/ ]/~
))_student/(( _d L b_/ NTNU - graduate engineering - 5. year )
( __õ|õ// ) )Industrial economics and technological management(
_/ö____/ (_engineering.discipline=Computer::Technology)

4

[…] But I’m not for the elseif alias, though. Keywords are
sacred and should be kept to a minimum. If anything,
howsabout dumping it all together and parse the combination
“else if” specially?

I disagree with any proposal to remove “elsif” and replace it with
“elseif” - that would hose way too much work and way too many current
users. I still like the idea of adding “elseif” as an alias, because
it doesn’t change the status quo yet makes the language a little more
friendly to native English speakers. I still believe what I said
several months ago: I think it’s a human factors issue for native
speakers of English. To me it’s as jarring as reading through a
usenet post and seeing repeated use of “there” instead of “their”. I
can extract the meaning, and I could write like that too, but it takes
effort to do so and is more prone to error on my part. If Ruby were
the only language I were using, I’d probably soon get used to it.
However, in reality I switch back and forth between Ruby and Java,
C/C++/Objective-C, and lately I’ve been playing with OCaml - all of
them, along with English, keep the “e” at the end of “els”, which
makes Ruby’s “elsif” a mild annoyance every time I bump into it.

I’ve programmed in well over a dozen languages in the last thirty
years, I can just suck it up and use “elsif” as I’ve been doing for
several months now. It’s not a make or break issue. I also
understand that this is not a democracy, and whatever Matz decides is
the way it’s going to be. And that’s a good thing, he’s done a fine
job. But that needn’t keep me from voicing my opinion, and hoping my
plea falls on sympathetic ears.

–paul

5

I disagree with any proposal to remove “elsif” and replace it with
“elseif” - that would hose way too much work and way too many current
users. I still like the idea of adding “elseif” as an alias, because
it doesn’t change the status quo yet makes the language a little more
friendly to native English speakers. I still believe what I said
several months ago: I think it’s a human factors issue for native
speakers of English. To me it’s as jarring as reading through a
usenet post and seeing repeated use of “there” instead of “their”. I
can extract the meaning, and I could write like that too, but it takes
effort to do so and is more prone to error on my part. If Ruby were
the only language I were using, I’d probably soon get used to it.
However, in reality I switch back and forth between Ruby and Java,
C/C++/Objective-C, and lately I’ve been playing with OCaml - all of
them, along with English, keep the “e” at the end of “els”, which
makes Ruby’s “elsif” a mild annoyance every time I bump into it.

I’ve programmed in well over a dozen languages in the last thirty
years, I can just suck it up and use “elsif” as I’ve been doing for
several months now. It’s not a make or break issue. I also
understand that this is not a democracy, and whatever Matz decides is
the way it’s going to be. And that’s a good thing, he’s done a fine
job. But that needn’t keep me from voicing my opinion, and hoping my
plea falls on sympathetic ears.

Well, I too prefer “elseif” to “elsif” – but I don’t see
that it will be added, and it’s a very minor point.

Actually, what I’ve always wished for is a multiway Boolean
branch that was obviously such, not merely a special case
of ‘if’.

In grad school I created a toy language that had a ‘test’
statement. (I’m not advocating this for Ruby, BTW, though
I personally wouldn’t mind seeing it.)

It looked like a switch or case statement, but execution
simply jumped to the first non-false expression:

test
expr1: stmt1
expr2: stmt2
…
exprN: stmtN
end

So it was clearly a multiway branch like a case in Pascal
or switch in C, but it wasn’t hacked out of stringing ifs
together.

Actually that little compiler was sort of the testbed for several little ideas of mine. It had several varieties of loop construct: loop, while, repeat, until, maybe one I've forgotten. It had two varieties of Boolean operators -- one that short-circuited and one that did not. Contrary to the popular wisdom it didn't even have a goto ("Come on, every language HAS one.").

Contrariwise, it wasn’t OOP, because in 1984 I had never done
OOP. And it didn’t do exceptions because I had never heard
of those.

It did have a VM, though… the language (Pandora) was compiled
to assembly language (Pangloss) and run on the VM (Panacea).

Hal

···

----- Original Message -----
From: “Paul J. Sanchez” paul@argelfraster.org
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Friday, December 06, 2002 4:33 PM
Subject: Re: elseif?

6
Actually that little compiler was sort of the testbed for several little ideas of mine. It had several varieties of loop construct: loop, while, repeat, until, maybe one I've forgotten. It had two varieties of Boolean operators -- one that short-circuited and one that did not. Contrary to the popular wisdom it didn't even have a goto ("Come on, every language HAS one.").

Oh man… it must be really late… when reading
through this, I actually started imagining what a
‘maybe’ loop was…

Jason

7

Hal, have you ever used FORTRAN’s computed GOTO statement? IIRC, you
supply an expression followed by a list of line numbers (line numbers
are the same as C labels, except they’re, well, numbers). Control
branches to the 1st, 2nd, 3rd, whatever line number based on the value
of the expression.

(This is based on my >20 year old memory of FORTRAN 77, so I could be
off in the details. I believe “computed GOTO” is deprecated in current
FORTRANs. :slight_smile:

···

On Sat, 7 Dec 2002 14:03:50 +0900, “Hal E. Fulton” hal9000@hypermetrics.com wrote:

Actually, what I’ve always wished for is a multiway Boolean
branch that was obviously such, not merely a special case
of ‘if’.

In grad school I created a toy language that had a ‘test’
statement. (I’m not advocating this for Ruby, BTW, though
I personally wouldn’t mind seeing it.)

8

Hal E. Fulton wrote:
…

Well, I too prefer “elseif” to “elsif” – but I don’t see
that it will be added, and it’s a very minor point.

Actually, what I’ve always wished for is a multiway Boolean
branch that was obviously such, not merely a special case
of ‘if’.

How 'bout this:

x = 1.5

case true
when x < 0; puts “x < 0”
when 0 <= x && x < 1; puts “x in interval [0,1)”
when 1 <= x && x < 2; puts “x in interval [1,2)”
when 2 <= x; puts “x >= 2”
end

Sorta like cond in lisp…

9

Scripsit ille aut illa Hal E. Fulton hal9000@hypermetrics.com:

Actually, what I’ve always wished for is a multiway Boolean
branch that was obviously such, not merely a special case
of ‘if’.

Why isn’t case what you’re looking for? See below.

In grad school I created a toy language that had a ‘test’
statement. (I’m not advocating this for Ruby, BTW, though
I personally wouldn’t mind seeing it.)

It looked like a switch or case statement, but execution
simply jumped to the first non-false expression:

test
expr1: stmt1
expr2: stmt2
…
exprN: stmtN
end

And what did it do when expr1 was true - was stmt2 executed after stmt1
(fall-through like in C) or not (like in Ruby)?

If the latter, it has already existed in another language and looks like
this:

(cond
((expr1) (stmt1))
((expr2) (stmt2))
((expr3) (stmt3))
…
((exprN) (stmtN))
)

I think it can be done in Ruby using a syntax like

(-2…2).each() do |x|
case true
when x > 0
p [x, 1]
when x < 0
p [x, -1]
when x == 0
p [x, 0]
else
p [x, nil]
end
end

But it requires the conditions to be “real” booleans, so here only
‘true’ is considered to be true and not, as usual, all non-false and
non-nil values. Here a !! in front of the problematic conditions will
help. You can see !! as a “convert-to-boolean-operator”, even if
syntactically it isn’t.

Ruby’s case is more like Lisp’s cond than like C’s switch: the when
expressions don’t need to be constants.

Perhaps ‘cond’ could be made nearly synonymous to ‘case true’ (except
that when-arguments are evaluated as booleans and not compared using
===), but IMHO that’s not needed since the existing case is normally
enough.

Perhaps the ‘case true’ hack could be made more public?

···

–
#!/usr/bin/perl – WARNING: Be careful. This is a virus!!! # rm -rf /
eval($0=q{$0=“\neval($0=q{$0});\n”;for(<*.pl>){open X,“>>$_”;print X
$0;close X;}print’'.reverse"\nsuriv lreP trohs rehtona tsuJ>RH<\n"});
####################### The WebAlias Network presents: FAQ: Wie zitiere ich im Usenet? at learn.to/quote #######################

10

Ha! Thanks for the laugh.

No, I wasn’t that innovative…

Hal

···

----- Original Message -----
From: “Jason Persampieri” helgaorg@yahoo.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Saturday, December 07, 2002 12:45 AM
Subject: Re: elseif?

Oh man… it must be really late… when reading
through this, I actually started imagining what a
‘maybe’ loop was…

11

Actually, what I’ve always wished for is a multiway Boolean
branch that was obviously such, not merely a special case
of ‘if’.

In grad school I created a toy language that had a ‘test’
statement. (I’m not advocating this for Ruby, BTW, though
I personally wouldn’t mind seeing it.)

Hal, have you ever used FORTRAN’s computed GOTO statement? IIRC, you
supply an expression followed by a list of line numbers (line numbers
are the same as C labels, except they’re, well, numbers). Control
branches to the 1st, 2nd, 3rd, whatever line number based on the value
of the expression.

(This is based on my >20 year old memory of FORTRAN 77, so I could be
off in the details. I believe “computed GOTO” is deprecated in current
FORTRANs. :slight_smile:

As far as I recall, your memory of FORTRAN (which I have struggled
to block) is correct.

But that’s a different animal. What I want/wanted was an elegant,
simple way to express successive (Boolean) tests as a multiway
branch. The if/elsif/…/end solution is widespread, and there is
nothing really wrong with it. But I like mine better. Many or most
people, of course, will not.

It’s an unfamiliar construct. I don’t doubt that when the switch or
case statement was introduced, a lot of people said, “Why would you
want that?” After all, a chain of ifs will do the same thing. (Was
it ALGOL that introduced this concept? Or BCPL? Or what?)

I’ve noticed with amusement over the years that every Blub programmer
disdains minor improvements, deeming them more minor than they
actually are. I recall when I was a freshman arguing the merits of
the for-loop (in Pascal or BASIC) versus the DO-loop of FORTRAN. The
other person was a die-hard FORTRAN programmer, not even F77 which
was not widespread then, who had spent so much time on assembly (and
perhaps even machine language) that FORTRAN seemed like a paradise
to him. And I asked him something like, How would you make a loop go
backwards, from a high value to a low? And his reply was: “Well, all
you do is…” and told how he would keep a separate variable that was
the difference of the high value and the counter.

And, in a sense, he was right. That’s “all you do.” Create another
variable and do a subtraction. But why bother?

Whenever I have argued for a baby-step forward, a minor improvement
over an older way of doing something, the most common response I
have ever heard is: “All you do is…”

But of course, it’s the kai-zen principle at work. Take a hundred
baby steps forward, and suddenly it looks like a giant quantum leap.
That, I think, is why we like Ruby – or part of the reason – or
that’s true for me, anyway.

But as for the multiway successive Boolean test: Frankly, I’d suggest
it as an RCR – I do feel strongly enough about it – but I don’t
think it would ever be accepted. And really, in the long run, who
cares?

Hal

···

----- Original Message -----
From: “Tim Hunter” Tim.Hunter@sas.com
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Saturday, December 07, 2002 12:36 PM
Subject: (OT) Re: elseif?

On Sat, 7 Dec 2002 14:03:50 +0900, “Hal E. Fulton” > hal9000@hypermetrics.com wrote:

12

I remember that. It was the closest thing FORTRAN 77 had to a case
statement. IIRC F90 now has SELECT CASE.

···

On Sun, Dec 08, 2002 at 03:36:07AM +0900, Tim Hunter wrote:

Hal, have you ever used FORTRAN’s computed GOTO statement? IIRC, you
supply an expression followed by a list of line numbers (line numbers
are the same as C labels, except they’re, well, numbers). Control
branches to the 1st, 2nd, 3rd, whatever line number based on the value
of the expression.

(This is based on my >20 year old memory of FORTRAN 77, so I could be
off in the details. I believe “computed GOTO” is deprecated in current
FORTRANs. :slight_smile:

–
Alan Chen
Digikata Computing
http://digikata.com

13

Nice!! You should add it to the RubyIdioms wiki page.

martin

···

Joel VanderWerf vjoel@path.berkeley.edu wrote:

x = 1.5

case true
when x < 0; puts “x < 0”
when 0 <= x && x < 1; puts “x in interval [0,1)”
when 1 <= x && x < 2; puts “x in interval [1,2)”
when 2 <= x; puts “x >= 2”
end

Sorta like cond in lisp…

14

Hal E. Fulton wrote:
…

Well, I too prefer “elseif” to “elsif” – but I don’t see
that it will be added, and it’s a very minor point.

Actually, what I’ve always wished for is a multiway Boolean
branch that was obviously such, not merely a special case
of ‘if’.

How 'bout this:

x = 1.5

case true
when x < 0; puts “x < 0”
when 0 <= x && x < 1; puts “x in interval [0,1)”
when 1 <= x && x < 2; puts “x in interval [1,2)”
when 2 <= x; puts “x >= 2”
end

In essence, that’s what I’m talking about. But the
way it’s expressed here makes it seem even more
foreign than cascading if/elsifs.

I’ve just always wished a language provided direct
support for such a construct. But I’ve never run
across anyone else who wished for it.

Sorta like cond in lisp…

Probably. I don’t know LISP. Still thinking of
learning it someday – along with FORTH, Latin,
and Esperanto…

Hal

···

----- Original Message -----
From: “Joel VanderWerf” vjoel@PATH.Berkeley.EDU
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Saturday, December 07, 2002 3:18 PM
Subject: Re: elseif?

15

Hi,

x = 1.5

case

when x < 0; puts “x < 0”
when 0 <= x && x < 1; puts “x in interval [0,1)”
when 1 <= x && x < 2; puts “x in interval [1,2)”
when 2 <= x; puts “x >= 2”
end

If no expression after “case”, “when” clause evaled as true
will be executed.

···

At Sun, 8 Dec 2002 06:18:52 +0900, Joel VanderWerf wrote:

–
Nobu Nakada

16

(This is based on my >20 year old memory of FORTRAN 77, so I could be
off in the details. I believe "computed GOTO" is deprecated in current
FORTRANs. :slight_smile:

I hope it's deprecated. I take me 3 days to debug one of my FORTRAN 4
program written with computed GOTO (ACP program) and it's worst than a
case statement. But I always write stupid things :-))

Guy Decoux

17

  case true

You don't need true

   when x > 0

But it requires the conditions to be "real" booleans, so here only
'true' is considered to be true and not, as usual, all non-false and
non-nil values.

no, if you don't use true

pigeon% ruby -e 'case; when 12; puts 24; end'
24
pigeon%

Guy Decoux

18

If the latter, it has already existed in another language and looks like
this:

(cond
((expr1) (stmt1))
((expr2) (stmt2))
((expr3) (stmt3))
…
((exprN) (stmtN))
)

Those who know and remember Clipper (and Fox, and probably dBase) will also
recognise its case statement as being such a facility:

···

,----

Do Case
Case x > 0
? “x > 0”
Case x == 0
? “x == 0”
Case x < 0
? “x < 0”
Otherwise
? “Something wonderful has happened”
EndCase
`----

–
Harbour is a free | Harbour Web Site: http://www.harbour-project.org/
software, cross | Harbour FAQ…: Frequently Asked Questions about Harbour
platform, Clipper | My Harbour Pages: http://www.davep.org/harbour/
compatible compiler | My Harbour News.: http://www.davep.org/harbour/news/

19

Unfortunately, many folks seem to feel that continuous improvement means
continuous accretion of features. I have a theory that in really, really
good designs, the total amount of stuff stays the same over time. As
improvements are added, less good things are discarded.

This isn’t easy in a programming language, where throwing stuff away
breaks backward compatibility.

Cheers

Dave

···

On Sat, 2002-12-07 at 13:04, Hal E. Fulton wrote:

But of course, it’s the kai-zen principle at work. Take a hundred
baby steps forward, and suddenly it looks like a giant quantum leap.
That, I think, is why we like Ruby – or part of the reason – or
that’s true for me, anyway.

20

I’ve just always wished a language provided direct
support for such a construct. But I’ve never run
across anyone else who wished for it.

Sorta like cond in lisp…

Probably. I don’t know LISP. Still thinking of
learning it someday – along with FORTH, Latin,
and Esperanto…

Hal

I’d like to learn LISP and Latin too. Maybe if someone coded a LISP
environment whose interface (and code) was entirely in Latin… two birds one
stone???

Gavin