Non-declared variables

ruby-talk
1

> Every language feature that reduces how much typing I have
> to do is a tangible benefit to me. It eases stress on my
> body machine, and speeds the delivery of my code.

That seems a ridiculous thing to say to me. Time taken to type out
code is not the limiting factor in your productivity.

You're right, it's too much of a blanket statement. I would not want to
program in APL[1], for example, despite it's terseness.

On the other hand, I wouldn't want added to Ruby requirements to:
* Declare all my variables before using them.
* Write out Block.new( arg1, arg2 ){ body } for all blocks.
* Use 'definition' in place of 'def'
* Put parentheses around all method calls
* Use .send( "foo=", 12 ) to invoke a setter method
* Include types for every variable, argument, and method return
  (either as static types or 'suggestions')

etc.

The original post in this thread suggests that omitting declarations of
variables leads to debugging problems for no real gain. My intended
point was that (for me) a lot of Ruby's elegance comes from its
simplicity of expression. Ruby doesn't do anything that I can't do in
Lua or JavaScript, except make my life as a programmer way easier.

[1] APL (programming language) - Wikipedia

···

From: Martin Coxall [mailto:pseudo.meta@gmail.com]

2

"Gavin Kistner" <gavin.kistner@anark.com> writes:

The original post in this thread suggests that omitting declarations of
variables leads to debugging problems for no real gain. My intended
point was that (for me) a lot of Ruby's elegance comes from its
simplicity of expression. Ruby doesn't do anything that I can't do in
Lua or JavaScript, except make my life as a programmer way easier.

I think what the OP was getting at is that assignment syntax is
identical to declaration syntax, and there's no clear distinction
between the two. Therefore, when you want an assignment to be an
assignment of an already declared variable, you have nothing checking
you for typos.

This has nothing to do, by the way, with variable typing. As an
example, perl with the "strict" flag on behaves this way, requiring
variables to be declared before use and most perl programmers don't
find the extra checking cumbersome (in fact, if you go to perlmonks,
the first thing they'll ask you to do is to turn on "use strict").
Although variables can be declared in outher ways (it is, after all,
perl) most perl programmers just put "my " in front of their first
usage of a variable, and that's that. You can declare and assign in
one statement, or do them in two.

In ruby, I imagine that we'd evolve some syntax like this:

class Foo
  def initialize(name, thing)
    n @name = name
    n @thing = thing
    n @count = 0
  end

  def inc
    # This line is an error at class definition parse time, because
    # I typoed a variable name
    @coutn += 1
  end

  def compute
    # these four will be initialized to nil
    n a,b,c,d
    # I can now use a, b, c, and d as local variables without further
    # declaration.
  end
end

Note that separating declaration from assignment also makes it dirt
simple to decide the proper scope of a variable, instead of having to
have the switch between ruby 1.9 and ruby 2.0 of various scoping
details.

I'd welcome such a syntax to ruby - requiring, of course, a per-file
strictness switch; no point in killing backwards compatibility - and I
think that the extra typing would provide sufficient benefit to be
worth it. Note that block parameters are already declared in the ||
list at the start of the block, so nothing changes in:
  myArray.each {|a,b| alert(a,b)}
although I may want to think carefully about what that block means in
the presence of a declared variable called 'b' in the surrounding
scope. I generally wouldn't want the variable capture ruby does
presently, but some might.

···

--
s=%q( Daniel Martin -- martin@snowplow.org
       puts "s=%q(#{s})",s.map{|i|i}[1] )
       puts "s=%q(#{s})",s.map{|i|i}[1]

3

Its probably best to have a strict option like in perl and VB.net. If
I am understanding what Daniel is saying properly and ruby works in
such a way that what should be a typo that generates an error is
accepted by ruby as a legit variable in spite of the fact that the
programmer really meant to say count it creates a set of situations
that are very error prone and that is not a good thing.

···

On 10/16/06, Daniel Martin <martin@snowplow.org> wrote:

"Gavin Kistner" <gavin.kistner@anark.com> writes:

> The original post in this thread suggests that omitting declarations of
> variables leads to debugging problems for no real gain. My intended
> point was that (for me) a lot of Ruby's elegance comes from its
> simplicity of expression. Ruby doesn't do anything that I can't do in
> Lua or JavaScript, except make my life as a programmer way easier.

I think what the OP was getting at is that assignment syntax is
identical to declaration syntax, and there's no clear distinction
between the two. Therefore, when you want an assignment to be an
assignment of an already declared variable, you have nothing checking
you for typos.

This has nothing to do, by the way, with variable typing. As an
example, perl with the "strict" flag on behaves this way, requiring
variables to be declared before use and most perl programmers don't
find the extra checking cumbersome (in fact, if you go to perlmonks,
the first thing they'll ask you to do is to turn on "use strict").
Although variables can be declared in outher ways (it is, after all,
perl) most perl programmers just put "my " in front of their first
usage of a variable, and that's that. You can declare and assign in
one statement, or do them in two.

In ruby, I imagine that we'd evolve some syntax like this:

class Foo
  def initialize(name, thing)
    n @name = name
    n @thing = thing
    n @count = 0
  end

  def inc
    # This line is an error at class definition parse time, because
    # I typoed a variable name
    @coutn += 1
  end

  def compute
    # these four will be initialized to nil
    n a,b,c,d
    # I can now use a, b, c, and d as local variables without further
    # declaration.
  end
end

Note that separating declaration from assignment also makes it dirt
simple to decide the proper scope of a variable, instead of having to
have the switch between ruby 1.9 and ruby 2.0 of various scoping
details.

I'd welcome such a syntax to ruby - requiring, of course, a per-file
strictness switch; no point in killing backwards compatibility - and I
think that the extra typing would provide sufficient benefit to be
worth it. Note that block parameters are already declared in the ||
list at the start of the block, so nothing changes in:
  myArray.each {|a,b| alert(a,b)}
although I may want to think carefully about what that block means in
the presence of a declared variable called 'b' in the surrounding
scope. I generally wouldn't want the variable capture ruby does
presently, but some might.

--
s=%q( Daniel Martin -- martin@snowplow.org
       puts "s=%q(#{s})",s.map{|i|i}[1] )
       puts "s=%q(#{s})",s.map{|i|i}[1]

4

Kevin Olemoh wrote:

Its probably best to have a strict option like in perl and VB.net. If
I am understanding what Daniel is saying properly and ruby works in
such a way that what should be a typo that generates an error is
accepted by ruby as a legit variable in spite of the fact that the
programmer really meant to say count it creates a set of situations
that are very error prone and that is not a good thing.

I very much agree, being a longtime Perl programmer (10+ years). When "use strict" was first introduced, a very similar discussion ensued on the Perl lists about how it was going to be cumbersome/etc. As Kevin says, years later the first thing everyone says in Perl-land is to "use strict", so much that many discussions have considered turning it on by default.

My one comment would be to use a common idiom in other languages, like "var", rather than "n".

BTW, howdy all (first post).

Cheers,
Nate

5

Its probably best to have a strict option like in perl and VB.net. If
I am understanding what Daniel is saying properly and ruby works in
such a way that what should be a typo that generates an error is
accepted by ruby as a legit variable in spite of the fact that the
programmer really meant to say count it creates a set of situations
that are very error prone and that is not a good thing.

harp:~ > ruby -W -e' @var=42; p @typo '
-e:1: warning: instance variable @typo not initialized
nil

q: why is top posting bad?

-a

···

On Wed, 18 Oct 2006, Kevin Olemoh wrote:
a: it's hard to follow.
--
my religion is very simple. my religion is kindness. -- the dalai lama

6

it's a nice idea, but not as a default, consider Object#method_missing,
Module#const_missing, etc. they rely on being fired when something is not
defined...

-a

···

On Wed, 18 Oct 2006, Nate Wiger wrote:

Kevin Olemoh wrote:

Its probably best to have a strict option like in perl and VB.net. If
I am understanding what Daniel is saying properly and ruby works in
such a way that what should be a typo that generates an error is
accepted by ruby as a legit variable in spite of the fact that the
programmer really meant to say count it creates a set of situations
that are very error prone and that is not a good thing.

I very much agree, being a longtime Perl programmer (10+ years). When "use strict" was first introduced, a very similar discussion ensued on the Perl lists about how it was going to be cumbersome/etc. As Kevin says, years later the first thing everyone says in Perl-land is to "use strict", so much that many discussions have considered turning it on by default.

My one comment would be to use a common idiom in other languages, like "var", rather than "n".

BTW, howdy all (first post).

--
my religion is very simple. my religion is kindness. -- the dalai lama

7

Not only that. Consider that the 'my' operator in perl is more than
just a convenient way to get the interpreter to check your spelling
with the strict pragma. It's actually there as a scoping construct:
if you don't declare a variable with 'my', what you get is a package
(global) variable rather than a lexical.

···

On 10/17/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:

it's a nice idea, but not as a default, consider Object#method_missing,
Module#const_missing, etc. they rely on being fired when something is not
defined...

--
Lou.

8

Louis J Scoras wrote:

it's a nice idea, but not as a default, consider Object#method_missing,
Module#const_missing, etc. they rely on being fired when something is not
defined...

Not only that. Consider that the 'my' operator in perl is more than
just a convenient way to get the interpreter to check your spelling
with the strict pragma. It's actually there as a scoping construct:
if you don't declare a variable with 'my', what you get is a package
(global) variable rather than a lexical.

I don't think it needs to be a default but it could be advisable to encourage its use especially among people new to Ruby and/or programming in general. I have not come to the point where the things I write in ruby are particularly long but I can easily see that as my programs get larger and larger I am more likely to run into this quirk. Autocompletion is great and all but it's a bit of a crutch in this case; after all what happens if I have to end up coding in notepad or something like that? (I think I would just kill myself if I had to code anything in notepad....but it could happen.)

···

On 10/17/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote: