Yet Another useless Ruby 2 Idea

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?

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.

···

On Sunday 31 July 2005 21:21, gabriele renzi wrote:

--
Stefan

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.

Hello gabriele,

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?

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 ?

···

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

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

Close enough?

T.

Stefan Lang ha scritto:

···

On Sunday 31 July 2005 21:21, gabriele renzi wrote:

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

Trans ha scritto:

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.

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

If you want python syntax, use python

···

On 7/31/05, Lothar Scholz <mailinglists@scriptolutions.com> wrote:

Hello gabriele,

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

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 ?

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

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

Jeff Wood

Lothar Scholz ha scritto:

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

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

T.

gabriele renzi wrote:

Lothar Scholz ha scritto:

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

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.

Jeff Wood <jeff.darklight@gmail.com> writes:

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?

···

--
Daniel Brockman <daniel@brockman.se>

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

···

On 8/3/05, Daniel Brockman <daniel@brockman.se> wrote:

Jeff Wood <jeff.darklight@gmail.com> writes:

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?

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

While I agree with your sentiment, I'd propose that Ruby didn't "steal"
ideas from other languages but chose to stand on the shoulders of giants
and "build" on those ideas. :slight_smile:

···

On Thu, 2005-08-04 at 12:16 +0900, Daniel Brockman wrote:

Jeff Wood <jeff.darklight@gmail.com> writes:

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

Daniel Brockman wrote:

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

Because Python has a special -t option just to help debug the problems that structurally significant indentation causes?

If I didn't vehemently object to significant whitespace, I'd be using Python rather than Ruby. If Ruby gained the significant whitespace 'feature', I'd go back to Perl.

mathew

···

--
<URL:http://www.pobox.com/~meta/&gt;
          WE HAVE TACOS

You don't need significant whitespace. What you do need is for nested defs to be illegal.
That's how ocaml works, not with significant whitespace. (At least as far as stament terminators are concerned)

···

On Aug 1, 2005, at 2:51 PM, Adam P. Jenkins wrote:

gabriele renzi wrote:

Lothar Scholz ha scritto:

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

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.

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:

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

I mean, the python versions are way more readable in these cases.
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.

···

On 8/3/05, Austin Ziegler <halostatue@gmail.com> wrote:

On 8/3/05, Daniel Brockman <daniel@brockman.se> wrote:
> Jeff Wood <jeff.darklight@gmail.com> writes:
>> 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?

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
--
Austin Ziegler * halostatue@gmail.com
              * Alternate: austin@halostatue.ca

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

Jeff Wood

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

Absolutely.

Yes, I hate Python's syntactically significant whitespace.

Indeed. It is the most important 1 reason for me not using Python on a regular basis. Seeing Ruby and knowing that it does not have syntactically significant whitespace is excellent and one of the reasons that made me look more closely at Ruby.

The number of times a visually correct Python script I've written doesn't work because I've mixed up tabs and spaces (and then have to go through finding out where the failure is) - you have no idea how much this irritates. Its like paddling through treacle. I don't think I have ever successfully written a Python script without falling foul of this ridiculous concept.

Makefiles also mix up spaces and tabs and often fail if you put the wrong invisible character in the wrong place. Its a nightmare. People knew that Makefile syntax was daft before Python was born. Why anyone would want to put that into a computer language beggars belief.

you want X, use Y". But we should also discourage the importation of
the worst features of other languages.

Well said.

Stephen

···

In message <9e7db9110508032058703f5f84@mail.gmail.com>, Austin Ziegler <halostatue@gmail.com> writes
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk/software.html
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting

mathew <meta@pobox.com> writes:

Python has a special -t option just to help debug the
problems that structurally significant indentation causes

   -t Issue a warning when a source file mixes tabs and
        spaces for indentation in a way that makes it depend
        on the worth of a tab expressed in spaces.

That problem is caused by people using physical tabs.

Just ban tabs altogether. Problem solved.

···

--
Daniel Brockman <daniel@brockman.se>

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.

···

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