If we really wanted a kitchen sink language we would drop Ruby here and
now and start using Lisp and Ada. But no one likes to spend their day at
the kitchen sink.
Now there’s a quotable quote!
All I ask it that the request adds functionality to the language and not
sugar. ‘with’, ‘x++’, ‘elseif’, ‘new’ and the rest are just plain sugar.
Ehh, sometimes I like sugar. YMMV. Ruby has a
lot already, though, and there is probably
such a thing as too much.
Aren’t you glad Matz is in charge of Ruby rather
than a committee?
Hal
···
----- Original Message -----
From: “Peter Hickman” peter@semantico.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Wednesday, July 16, 2003 9:47 AM
Subject: Re: Keyword “with”
Actually, VB complements the ‘with’ block with a unary . operator, which
is IMO the cleanest way to scope both local and object variables and
methods. At least, when I thought of the instance_eval/with trick, I
gave up on it because I couldn’t think of a way to simulate unary .s
Now there’s a thought. The unary . is not so
bad in my opinion. We already have the unary ::
in Ruby (::X means Object::X).
Sounds like a huge parser change to me, though.
Perhaps far too much in exchange for a small
benefit. Wonder what Matz would think of it?
Hal
···
----- Original Message -----
From: “Martin DeMello” martindemello@yahoo.com
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Wednesday, July 16, 2003 9:48 AM
Subject: Re: Keyword “with”
A little sugar isn’t so bad, after all, this isn’t RubyAtkins
An example of good sugar: All the methods in Kernel don’t have to
be preceeded by Kernel…
Well, then you should like Common Lisp and Ada. They have lots of
functionality, but not much sugar.
But there’s nothing wrong with sugar, syntactic or otherwise. Many of
the things I like about various programming languages falls squarely
in the “sugar” category. The heart of usability in general is usualy
redundancy and shortcuts - basically, a general lack of strict
adherence to orthogonality (what Larry Wall calls “diagonality”).
This is as true for usability of programming languages as it
is in other arenas.
Besides, many of Ruby’s built-in classes and modules are already
full of sugar - duplicated functionality with multiple interfaces.
Method names that are exact synonyms, operators that accomplish
the same thing as a method call, etc. Adding more would hardly
be a case of tarnishing a previously minimal design.
-Mark
···
On Wed, Jul 16, 2003 at 11:47:39PM +0900, Peter Hickman wrote:
If we really wanted a kitchen sink language we would drop Ruby here and
now and start using Lisp and Ada. But no one likes to spend their day at
the kitchen sink.
All I ask it that the request adds functionality to the language and not
sugar. ‘with’, ‘x++’, ‘elseif’, ‘new’ and the rest are just plain sugar.
“warning: on line 765 of myfile.rb: @myvar may not have been initialized”
I think the second one is more useful, and it is a typical type of output from
compilers for compiled languages. It is much quicker and zeroes in on the
actual problem faster than a test failing. I’m of course not advocating that
Ruby become a compiled language, but it would be nice if there were a way to
do the kind of checks that a compiler does.
Ben
···
On Wed July 16 2003 10:49 am, John Johnson wrote:
Is there a good way to get what type checking does for you? Maybe some
…
catching typos, like calling the class variable @my_var, but ending up
using it as @myvar.
The fundamental reason, I think,
is that a Fixnum object (upon which such an operator would operate)
should never be mutable.
Yes.
The x+=1 operator emphasizes that a new Fixnum
object is being assigned to the applicable variable.
No. (To me, anyway).
I can’t say I associate “new object being created” with “+=”. Now I know,
deep down, that it’s syntactic equivalence to “= … + …”, and THAT
emphasizes “new object”, but on a more gutteral level, “+=” means “new
object creation” no more than “++” would.
Lisp programmers have enquired about macros (occasionally).
Are there good ways of doing what Lisp macros do for you?
Perl has input filters (see the perlfilter docs) that sort of act like a pre-processor
for yout source. This was originally intended for encrypting source-code, but now is
used for lots of other purposes. Perl even has a command line argument (-p, I believe)
that will pass the source through the c pre-processor before Perl interprets it.
I wonder how difficult it would be to do input filters for Ruby?
On the otherhand, it’s probably not a feature needed in Ruby as much as it is in Perl.
Would the filter operate on strings or parse trees?
Strings wouldn’t satisfy the Lisp folks, because they’re used to
s-expressions.
I think a big reason ‘with’ has not been accepted is that
Matz remains unconvinced. It’s rather a Pascalism, and I
recall he said he never liked Pascal.
Ooops…
(Does anybody listen? No? Ok: I admit that I like Pascal as a language for
learning. It has some shortcomings especially with regard to IO but it
provides a verbose syntax that makes programs easy to read and understand.
But don’t tell matz…)
I actually liked Pascal very much also, especially
when I learned it after coming from BASIC and FORTRAN.
It was like a friendlier kind of ALGOL.
It had significant problems, but the Borland variant
fixed most of these (while introducing one or two more).
And nowadays Object Pascal is not perfect, but I say it
is as good as C++ or better.
Hal
···
----- Original Message -----
From: “Robert Klemme” bob.news@gmx.net
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, July 17, 2003 8:35 AM
Subject: Re: Keyword “with”
All I ask it that the request adds functionality to the language and not
sugar. ‘with’, ‘x++’, ‘elseif’, ‘new’ and the rest are just plain sugar.
A little sugar isn’t so bad, after all, this isn’t RubyAtkins
An example of good sugar: All the methods in Kernel don’t have to
be preceeded by Kernel…
If we really wanted a kitchen sink language we would drop Ruby here and
now and start using Lisp and Ada. But no one likes to spend their day at
the kitchen sink.
Now there’s a quotable quote!
At least this time my name is on it!
Aren’t you glad Matz is in charge of Ruby rather
than a committee?
Is there a good way to get what type checking does for you? Maybe some
…
catching typos, like calling the class variable @my_var, but ending up
using it as @myvar.
Test First Design?
Ok, but compare:
“Test 473 failed: expecting 17, got 18”
with
“warning: on line 765 of myfile.rb: @myvar may not have been initialized”
catching typos, like calling the class variable @my_var, but ending up
using it as @myvar.
John Johnson said:
Test First Design?
Ben Giddings said:
Ok, but compare:
“Test 473 failed: expecting 17, got 18”
with
“warning: on line 765 of myfile.rb: @myvar may not have been initialized”
Granted, but a good unit test wouldn’t be testing much more than a small
segment of your code; really no more than a single method. After seeing
which test failed, it should be fairly simple to track down the method &
see the line with the error.
Now, if the method being tested has >765 lines in it… that’s a whole
other problem!
-Ryan
PS - Hey Ruby-ists… I guess now I’m officially not “just lurking” the
mailing list. Hello!
$ ruby -w -e ‘puts “hello” if @myvar == 3’
-e:1: warning: instance variable @myvar not initialized
Just put “#!/usr/local/bin/ruby -w” at the start of all your scripts. As
Matz has mused before, it should have been compulsory (with an option to
turn it off)
Regards,
Brian.
···
On Thu, Jul 17, 2003 at 12:31:38AM +0900, Ben Giddings wrote:
Ok, but compare:
“Test 473 failed: expecting 17, got 18”
with
“warning: on line 765 of myfile.rb: @myvar may not have been initialized”
with anAwfulLongIdentifierThatYouWontLiktToTypeOften do
puts length
concat “bar”
puts length
puts self
end
but
why would anybody choose such a long identifier? After all, it’s a
local whose name can be taken freely. Arguing that it’s necessary to
prevent name collisions is IMHO mistaken: a method should normally not
have so many variables that long names are needed.
If you’re losing clearness inside the ‘with’ block, why not make a
better trade-off on variable assignment (“declaration”)?
you can always do
a = anAwfulLongIdentifierThatYouWontLiktToTypeOften
puts a.length
…
The only drawback is having to invent a new name. There’s no
performance impact, very unlike ‘with’.
···
On Wed, Jul 16, 2003 at 11:56:56PM +0900, Hal E. Fulton wrote:
Actually, VB complements the ‘with’ block with a unary . operator, which
is IMO the cleanest way to scope both local and object variables and
methods. At least, when I thought of the instance_eval/with trick, I
gave up on it because I couldn’t think of a way to simulate unary .s
Now there’s a thought. The unary . is not so
bad in my opinion. We already have the unary ::
in Ruby (::X means Object::X).
All I ask it that the request adds functionality to the
language and not sugar. ‘with’, ‘x++’, ‘elseif’, ‘new’ and
the rest are just plain sugar.
Ehh, sometimes I like sugar. YMMV. Ruby has a
lot already, though, and there is probably
such a thing as too much.
Agreed and agreed. I just think it might be worth noting that
including ‘?’ and ‘!’ in the allowable characters for method
names does not innately add more functionality than languages
which do not offer this, but it’s top quality syntactic sugar
that significantly increases the possibility of readable,
intuitive code.
Sugar has its uses, but binges are what cause cavities.
Aren’t you glad Matz is in charge of Ruby rather than a
committee?
Agreed.
Tim Hammerquist
···
–
I have never let my schooling interfere with my education.
– Mark Twain
The fundamental reason, I think,
is that a Fixnum object (upon which such an operator would operate)
should never be mutable.
Yes.
The x+=1 operator emphasizes that a new Fixnum
object is being assigned to the applicable variable.
No. (To me, anyway).
I can’t say I associate “new object being created” with “+=”. Now I know,
deep down, that it’s syntactic equivalence to “= … + …”, and THAT
emphasizes “new object”, but on a more gutteral level, “+=” means “new
object creation” no more than “++” would.
Maybe that’s me though.
I couldn’t help myself any longer, I had to implement the ++ operator
Sadly, we have to load the file with ++ calls explicitly, since a file
is parsed before anything is executed, so the appearance of ++ would
generate parse errors before we could catch them and replace them with
‘+=1’. So, I wrote a new load method:
def loadpp(l)
s = ‘’
prevb = nil
f = File.new(l,‘r’)
f.each_byte do |b|
if (b == 43 && b == prevb) # 43 is ascii ‘+’
s += '+= 1 ’
b = nil # throw away the ‘++’
else
s += prevb.chr unless prevb.nil?
end
prevb = b
end
s += prevb.chr unless prevb.nil?
eval(s)
end
Now, any file loaded with loadpp may contain the ++ operator, and it
will be replaced with ‘+= 1’. Have fun with it if you like
Yes, you covered the /how/, and the /why/ would seem to be
so you don’t have to preceed the methods in Kernel with … Perhaps
there are other reasons too.
Anyway, as pointed out by others, sugar is present, and it is good.
To much would be bad.
A little sugar isn’t so bad, after all, this isn’t RubyAtkins
An example of good sugar: All the methods in Kernel don’t have to
be preceeded by Kernel…
Hmm, is that sugar? I thought it was because the
top level is in the scope of Object, and Object
mixes in Kernel. Maybe I’m overlooking something.
It seems to me that that could be done at any point, without ‘breaking’
anything (your code will still run; it’ll just spit out warnings). What
are the cons?
Just put “#!/usr/local/bin/ruby -w” at the start of all your scripts. As
Matz has mused before, it should have been compulsory (with an option to
turn it off)
