Yet Another useless Ruby 2 Idea

[gabriele renzi]

Hi gurus and nubys,

Hearing about ocaml in the last weeks and having noticed matz'
hack about using ;; as a block terminator (side by side with "end"),
I realized that it could be nice if ruby could work the same ocaml does
WRT to block terminator, I mean, make them optional when there is no
ambiguity

What I am thinking is cases like these in ruby:


def foo
def bar
# bar gets defined as if it was declared
# out of foo, quite useless
end
end

and

def foo
#SyntaxError
Someconstant or class Foo or module Foo
end

it could be cool if ruby could threat this cases as if there was an
implicit block terminator, like ocaml does, so we could write

class Foo
def bar(x)
puts x
def baz
puts 'baz'
Const=:someconstant
end

instead of

class Foo
def bar(x)
puts x
end
def baz
puts 'baz'
end
Const=:someconst
end

Ok, I admit that it's not a big deal, but what do people think of this?

 

[Stefan Lang]

Hi gurus and nubys,

Hearing about ocaml in the last weeks and having noticed matz'
hack about using ;; as a block terminator (side by side with
"end"), I realized that it could be nice if ruby could work the
same ocaml does WRT to block terminator, I mean, make them optional
when there is no ambiguity [...]
it could be cool if ruby could threat this cases as if there was an
implicit block terminator, like ocaml does, so we could write

class Foo
def bar(x)
puts x
def baz
puts 'baz'
Const=:someconstant
end

instead of

class Foo
def bar(x)
puts x
end
def baz
puts 'baz'
end
Const=:someconst
end

but it could also mean:

class Foo
def bar(x)
end
puts x
def baz
end
puts 'baz'
Const=:someconstant
end

unless indentation is significant.

 

[Trans]

def foo
def bar
# bar gets defined as if it was declared
# out of foo, quite useless
end
end

Better if #bar is local to the scope of foo.

T.

 

[gabriele renzi]

Stefan Lang ha scritto:

Hi gurus and nubys,

Hearing about ocaml in the last weeks and having noticed matz'
hack about using ;; as a block terminator (side by side with
"end"), I realized that it could be nice if ruby could work the
same ocaml does WRT to block terminator, I mean, make them optional
when there is no ambiguity
[...]

it could be cool if ruby could threat this cases as if there was an
implicit block terminator, like ocaml does, so we could write

class Foo
def bar(x)
puts x
def baz
puts 'baz'
Const=:someconstant
end

instead of

class Foo
def bar(x)
puts x
end
def baz
puts 'baz'
end
Const=:someconst
end

but it could also mean:

class Foo
def bar(x)
end
puts x
def baz
end
puts 'baz'
Const=:someconstant
end

unless indentation is significant.

well, I thought that if you wanted to write the equivalent of what you
just wrote, you'd just use an explicit block termination (no need for
meaningful indentation.
Nevertheless, the fact that this was'nt obvious probably shows that this
is a bad idea

 

[gabriele renzi]

Trans ha scritto:

Better if #bar is local to the scope of foo.

yes, but that would mean changing the semantic of def..end, from "define
a method for instances of self" to "define a method in a pseudo obkect
only available here".

 

[Lothar Scholz]

Hello gabriele,

gr> it could be cool if ruby could threat this cases as if there was an
gr> implicit block terminator, like ocaml does, so we could write

gr> class Foo
gr> def bar(x)
gr> puts x
gr> def baz
gr> puts 'baz'
gr> Const=:someconstant
gr> end

gr> instead of

gr> class Foo
gr> def bar(x)
gr> puts x
gr> end
gr> def baz
gr> puts 'baz'
gr> end
gr> Const=:someconst
gr> end

gr> Ok, I admit that it's not a big deal, but what do people think of this?

Sorry for being very rude, but this one is the one of the most stupid and ugly idea
i'have seen in the last weeks.

It hides errors, reduces readability and just for the benefit to save a few keystrokes ?

 

[Lothar Scholz]

Hello gabriele,

gr> it could be cool if ruby could threat this cases as if there was an
gr> implicit block terminator, like ocaml does, so we could write

gr> class Foo
gr> def bar(x)
gr> puts x
gr> def baz
gr> puts 'baz'
gr> Const=:someconstant
gr> end

gr> instead of

gr> class Foo
gr> def bar(x)
gr> puts x
gr> end
gr> def baz
gr> puts 'baz'
gr> end
gr> Const=:someconst
gr> end

gr> Ok, I admit that it's not a big deal, but what do people think of this?

Sorry for being very rude, but this one is the one of the most stupid and ugly idea
i'have seen in the last weeks.

It hides errors, reduces readability and just for the benefit to save a few keystrokes ?

 

[Jeff Wood]

If you want python syntax, use python

Hello gabriele,
=20
gr> it could be cool if ruby could threat this cases as if there was an
gr> implicit block terminator, like ocaml does, so we could write
=20
gr> class Foo
gr> def bar(x)
gr> puts x
gr> def baz
gr> puts 'baz'
gr> Const=3D:someconstant
gr> end
=20
gr> instead of
=20
gr> class Foo
gr> def bar(x)
gr> puts x
gr> end
gr> def baz
gr> puts 'baz'
gr> end
gr> Const=3D:someconst
gr> end
=20
gr> Ok, I admit that it's not a big deal, but what do people think of thi= s?
=20
Sorry for being very rude, but this one is the one of the most stupid and= ugly idea
i'have seen in the last weeks.
=20
It hides errors, reduces readability and just for the benefit to save a f= ew keystrokes ?
=20
--
Best regards, emailto: scholz at scriptolutions d= ot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
=20
=20
=20
=20

--=20
"So long, and thanks for all the fish"

Jeff Wood

 

[gabriele renzi]

Lothar Scholz ha scritto:

gr> Ok, I admit that it's not a big deal, but what do people think of this?


Sorry for being very rude, but this one is the one of the most stupid and ugly idea
i'have seen in the last weeks.

It hides errors, reduces readability and just for the benefit to save a few keystrokes ?

the rudeness it's ok, but I disagree that it reduces readability.
My main reason is that imho it actually improves it, but obviously it
must be a personal opinion since we disagree on it.

OTOH I don't see which kind of errors it does hide.

 

[Trans]

yes, but that would mean changing the semantic of def..end, from "define

a method for instances of self" to "define a method in a pseudo obkect
only available here"

2 cents says it's already been done by someone living in Japan

T.

 

[Adam P. Jenkins]

Lothar Scholz ha scritto:



the rudeness it's ok, but I disagree that it reduces readability.
My main reason is that imho it actually improves it, but obviously it
must be a personal opinion since we disagree on it.

OTOH I don't see which kind of errors it does hide.

Take your example:

class Foo
def bar(x)
puts x
def baz
puts 'baz'
Const=:someconstant
end

With the existing syntax, this would unambigously be a syntax error due
to missing end keywords. With your proposal, it could be correct, or
it could really be this (only indentation changed), with the last two
"end"s missing:

class Foo
def bar(x)
puts x
def baz
puts 'baz'
Const=:someconstant
end

or

class Foo
def bar(x)
puts x
def baz
puts 'baz'
Const=:someconstant
end

or

class Foo
def bar(x)
puts x
def baz
puts 'baz'
Const=:someconstant
end

or various other indentation permutations. In short, without
significant whitespace, the meaning of the code is now ambiguous. This
is the problem with Python's significant whitespace: if you accidentally
re-indent something, it's impossible to just highlight the code and tell
the editor to re-format, because there is literally no way for the
editor to tell what was intended.

 

[Daniel Brockman]

If you want python syntax, use python

Yeah, and if you want regular expressions, use Perl.
Last time I checked, Guido did not have any patents on
layout-based syntax.

I'm sorry, but I'm so tired of the categorical ``if you
want feature X, use language Y'' arguments.

Ruby has stolen tons of ideas from all over the place,
and that has served us well. Why stop now?

 

[Trans]

class Foo
def bar(x)
puts x
end
def baz
puts 'baz'
end
Const=:someconst
end

Close enough?

T.

 

[Austin Ziegler]

Yeah, and if you want regular expressions, use Perl. Last time I
checked, Guido did not have any patents on layout-based syntax.
=20
I'm sorry, but I'm so tired of the categorical ``if you want
feature X, use language Y'' arguments.
=20
Ruby has stolen tons of ideas from all over the place, and that
has served us well. Why stop now?

No one is suggesting to stop now. Layout-based syntax, however, is a
stupid idea that should have died with punch cards.

Yes, I hate Python's syntactically significant whitespace. There's
other things (maybe) that Ruby can learn from Python, but this isn't
one of them.

In general, I agree with you -- we shouldn't by and large say "if
you want X, use Y". But we should also discourage the importation of
the worst features of other languages.

-austin
--=20
Austin Ziegler * (e-mail address removed)
* Alternate: (e-mail address removed)

 

[Jeff Wood]

I'm not saying there are NO features of python that are cool... I like
their list comprehensions

but, I do dislike the whitespace formatting extremely.

so, the list comprehensions are like

[ item*2 for item in items ]

which is the same as: items.collect { |item| item*2 }

I think their version is more readable...

but beyond that, they have a cool conditional clause for the comprehensions=
...

[ item*2 for item in items if item > 2 ]

... which lets you run a conditional filter, and then a procedure on
the elements that passed.

which would be the same as:=20

temp =3D items.select { |item| item > 2 }
temp.collect { |item| item*2 }

I mean, the python versions are way more readable in these cases.=20
those would be a nice little bit of syntax to pick up.

So, I'm not saying there aren't some cool features ... I think we
should have tuples too ( frozen lists that are optimized for speed
since they are immutable )

Anyways, that's all I've got for now. Not trying to be bigotted, but
I think Ruby's syntax is just fine as it is ( as far as indentation
vs. end. )

Hope that makes sense.

j.

=20
No one is suggesting to stop now. Layout-based syntax, however, is a
stupid idea that should have died with punch cards.
=20
Yes, I hate Python's syntactically significant whitespace. There's
other things (maybe) that Ruby can learn from Python, but this isn't
one of them.
=20
In general, I agree with you -- we shouldn't by and large say "if
you want X, use Y". But we should also discourage the importation of
the worst features of other languages.
=20
-austin
--
Austin Ziegler * (e-mail address removed)
* Alternate: (e-mail address removed)
=20
=20

--=20
"So long, and thanks for all the fish"

Jeff Wood

 

[David A. Black]

Hi --

but beyond that, they have a cool conditional clause for the comprehensions...

[ item*2 for item in items if item > 2 ]

... which lets you run a conditional filter, and then a procedure on
the elements that passed.

which would be the same as:

temp = items.select { |item| item > 2 }
temp.collect { |item| item*2 }

You don't need 'temp' there:

items.select {|item| item > 2 }.map {|item| item * 2 }


David

 

[James McCarthy]

I like ruby syntax, I havent used python much so I cant compare but
I'm very very happy with how loose ruby can be.


--=20
My Blog: http://27degrees.blogspot.org

 

[Jeff Wood]

Yeah, I figured that out right after I had posted my message...

But still, you can see that the python syntax is quite a bit more
readable ( at least in this case ).

j.

Hi --
=20
On Thu, 4 Aug 2005, Jeff Wood wrote:
=20

but beyond that, they have a cool conditional clause for the comprehens= ions...

[ item*2 for item in items if item > 2 ]

... which lets you run a conditional filter, and then a procedure on
the elements that passed.

which would be the same as:

temp =3D items.select { |item| item > 2 }
temp.collect { |item| item*2 }

=20
You don't need 'temp' there:
=20
items.select {|item| item > 2 }.map {|item| item * 2 }
=20
=20
David
=20
--
David A. Black
(e-mail address removed)
=20
=20

--=20
"So long, and thanks for all the fish"

Jeff Wood

 

[Dave Fayram]

Yeah, I figured that out right after I had posted my message...
=20
But still, you can see that the python syntax is quite a bit more
readable ( at least in this case ).
=20
j.

Not to pick a fight, but that's just fine by me. Python sacrifices
nearly everything for readability. It's a language that revolves
around making code readable. If Python is occasionally more readable,
that's just fine. Ruby has a goal of being pleasant to write and work
with as well as being reasonably readable. I'd feel far more
comfortable when I work with Ruby, and it is usually quite readable. I
feel far more constrained when I write Python, but the output is
nearly always extremely readable.

The fact that Ruby can compete with Python in terms of readability is
a testament to how far it has come.



--=20
--=20
Dave Fayram (II)
(e-mail address removed)

 

[David A. Black]

Hi --

Yeah, I figured that out right after I had posted my message...

But still, you can see that the python syntax is quite a bit more
readable ( at least in this case ).

I have reluctantly given up on "readable" as a useful adjective. Like
"intuitive", it's used as a term of praise but apparently (trusting
the available evidence) doesn't mean anything. (The available
evidence is people, over the years, describing some very cryptic
things as more "readable" than their, ummm, non-cryptic equivalents


In this case, I have no trouble visually parsing either. But I take
such difficulties on faith in every case.

You could also do:

array.map {|item| item * 2 if item > 2 }.compact

though there's always the snag of cases where nil is OK as a value for
the resulting array. It's kind of hard to think how one would
implement #map_if. (Maybe something with enum_for or generator?)


David

j.

Hi --

but beyond that, they have a cool conditional clause for the comprehensions...

[ item*2 for item in items if item > 2 ]

... which lets you run a conditional filter, and then a procedure on
the elements that passed.

which would be the same as:

temp = items.select { |item| item > 2 }
temp.collect { |item| item*2 }

You don't need 'temp' there:

items.select {|item| item > 2 }.map {|item| item * 2 }


David