Paul Graham recommends Ruby

[tony summerfelt]

TCL definitely doesn't qualify as a "cool dynamic language".

i dunno, i think:

pack [button .b -text "quit" -command{exit}]

is pretty cool.

if i need a quickie gui tool for anything (or platform) i turn to
tcl/tk time and again. of course it's the 'tk' part that makes tcl
really useful.
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org

 

[Daniel Amelang]

Anyone tossed around the idea of changing hash's syntax so that {}
will unambiguisly belong to blocks?

I know it's rather extreme, but it would solve the problem with having
to put the empty pipes in our blocks, which is...ok, just not great.
{|| puts "hello"} Ugh.

Let's see... how do these look?

hash = <name:bill, age:25>
hash = (name:bill, age:25) # I don't really like this one
hash = [name:bill, age:25] # this infringes on Array's syntax

Oh well, just a thought.

Dan

 

[Nikolai Weibull]

* Daniel Amelang (Mar 20, 2005 21:10):

hash = [name:bill, age:25] # this infringes on Array's syntax

Well, that could work, as it will be obvious that its a hash due to the
keys,
nikolai

 

[David A. Black]

Hi --

* Daniel Amelang (Mar 20, 2005 21:10):

hash = [name:bill, age:25] # this infringes on Array's syntax

Well, that could work, as it will be obvious that its a hash due to the
keys,

What would this be:

[]

?

I think if {} were to be given over entirely to blocks and procs then
it would be time to use Hash.new and Hash.[] exclusively.


David

 

[Nikolai Weibull]

* David A. Black (Mar 20, 2005 22:20):

hash = [name:bill, age:25] # this infringes on Array's syntax

Well, that could work, as it will be obvious that its a hash due to
the keys,

What would this be:

[]

An empty hash/list? A proxy that defines its behavior depending on
furter use? I'm being silly,
nikolai

 

[Martin DeMello]

Actually there's a kind of double reasoning process involved here.
x[] is a method designed *not* to look like a method -- but it *is* a
method, can be redefined, etc. Therefore, () attached to a variable,
while also not looking like a method, looks like it should be one of
those things that don't look like methods but actually are. So it's
really within the framework of this kind of Ruby idiom that what I'm
saying applies.

If () ever gets to the stage where it works on literals as well as
variables, having the syntax be () and the method be #call will be
precisely analogous to the syntax for...in calling the method #each. So
at least there's some sort of precedent, and () looks far more rubyish
than for...in does.

martin

 

[Hal Fulton]

Actually there's a kind of double reasoning process involved here.
x[] is a method designed *not* to look like a method -- but it *is* a
method, can be redefined, etc. Therefore, () attached to a variable,
while also not looking like a method, looks like it should be one of
those things that don't look like methods but actually are. So it's
really within the framework of this kind of Ruby idiom that what I'm
saying applies.

If () ever gets to the stage where it works on literals as well as
variables, having the syntax be () and the method be #call will be
precisely analogous to the syntax for...in calling the method #each. So
at least there's some sort of precedent, and () looks far more rubyish
than for...in does.

IIRC David doesn't like for/in either. Though I do.

I have to admit his recent posts have made me see his point far
better than I did before. But I am still happy that Matz is making
the decision, not anyone else.

And, of course, I am not saying Matz is infallible. But I do say he
is smarter than I am (though he would not say so himself).


Hal

 

[David A. Black]

Hi --

Actually there's a kind of double reasoning process involved here.
x[] is a method designed *not* to look like a method -- but it *is* a
method, can be redefined, etc. Therefore, () attached to a variable,
while also not looking like a method, looks like it should be one of
those things that don't look like methods but actually are. So it's
really within the framework of this kind of Ruby idiom that what I'm
saying applies.

If () ever gets to the stage where it works on literals as well as
variables,

It doesn't work on either right now, though, just on method
identifiers.

having the syntax be () and the method be #call will be
precisely analogous to the syntax for...in calling the method #each. So
at least there's some sort of precedent, and () looks far more rubyish
than for...in does.

I admit that for...in analogies don't do a whole lot for me -- it's
not my favorite But I don't think the case is exactly the same.
It's not so much the call/() thing as the method/lambda thing that I
find incongruous -- that is, putting () after a variable that refers
to a lambda and have the variable sort of morph into the equivalent of
a method name. Or something like that.


David

 

[Daniel Amelang]

I entirely prefer getting rid of the {} empty hash constructor
(leaving us only Hash.new) than the adding block syntax with empty
pipes {|| puts 'eek'}. If the {} hash constructor is the *only* thing
between us and making {} refer to blocks and blocks only, I think it's
worth the loss.

Alternatively, you could make [:] the empty hash constructor. Quite a
shortcut for an associative array, if I do say so myself

Dan

 

[Nikolai Weibull]

* Daniel Amelang (Mar 21, 2005 00:30):

Alternatively, you could make [:] the empty hash constructor. Quite a
shortcut for an associative array, if I do say so myself

Heh, that was a quite nice solution actually,
nikolai

 

[Douglas Livingstone]

* Daniel Amelang (Mar 21, 2005 00:30):

Alternatively, you could make [:] the empty hash constructor. Quite a
shortcut for an associative array, if I do say so myself

Heh, that was a quite nice solution actually,
nikolai

As symbols are often used as keys, how about describing a hash as a
'symbolised array', like so:

:[:key => 'value', :foo => 'bar']

or an empty one:
:[]

Douglas

 

[Daniel Amelang]

I'm a little confused about the advantage of your suggestion:

:[:key => 'value', :foo => 'bar']

over this:

[key:value, foo:bar] (the key:value syntax is already part of ruby 1.9)

I'd be interested in the explaination of your preference.

About the empty hash idea, the :[] syntax represents a symbol (try
this '"[]".to_sym), so it might not be such a good idea.

Then again, I am no matz

Dan

 

[Martin DeMello]

hash = <name:bill, age:25>
hash = (name:bill, age:25) # I don't really like this one
hash = [name:bill, age:25] # this infringes on Array's syntax

[: name:bill, age:25 ]

or not. too few brackety things around

martin

 

[Martin DeMello]

For example, {|| } (lambda without lambda). For me, the question is
not whether it's possible to understand it (which it is). Rather,
the question is: if Ruby had been designed from the ground up with a
literal function constructor, would it have been {|| } ? If so, then
fine. If not, then {|| } would be an add-on that is not properly
integrated into the language.

That's an excellent way of looking at it.

martin

 

[gabriele renzi]

David A. Black ha scritto:

I admit that for...in analogies don't do a whole lot for me -- it's
not my favorite But I don't think the case is exactly the same.
It's not so much the call/() thing as the method/lambda thing that I
find incongruous -- that is, putting () after a variable that refers
to a lambda and have the variable sort of morph into the equivalent of
a method name. Or something like that.

notice that it is not a lambda thing.. is something done for callable
objects:
=> "yuk yukl"

I think of it as to_str, a way to duck type a callable.

 

[Mathieu Bouchard]

I'm not sure anything's new in that CVS feature except:
my_lambda = {|| puts "I am a lambda"}
where the || (with or without a param list) tells you that it's a
lambda rather than a hash.
I'm not a fan of this; I prefer using the lambda keyword.

Why not alias lambda/proc to L ? it would be just one more character to
type than the new syntax when there are arguments, and one _less_
character when there are none. And no syntax changes.

precedent: there's already a method called p.

_____________________________________________________________________
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju

 

[Florian Frank]

For example, {|| } (lambda without lambda). For me, the question is
not whether it's possible to understand it (which it is). Rather,
the question is: if Ruby had been designed from the ground up with a
literal function constructor, would it have been {|| } ? If so, then
fine. If not, then {|| } would be an add-on that is not properly
integrated into the language.

I think "f = {|| }" is analogous to "def f() end", and I really like it.
(To say the truth, this syntax for lambda is part of the language of my
dreams. It would be even nicer, if the shortcut "f = {}" would be
possible as well, but the empty Hash constructor collides with that
syntax. Like others have said before, I'd rather substitute the hash
constructor (but only in Ruby 2.0) with another syntax to get the "{}".
It's associated in C-languages with "code to be executed" anyway, so it
would meet newbie's expectations AND it would make Ruby more
self-consistent.

BTW: Is a syntax planned to define default values for blocks? It would
be good to be able to define a method
def f(x = 1) 2 * x end
with a block like
define_methodf) { |x=1| 2 * x }
I think blocks and methods should be as similar as possible, and this
would help a lot. (Or what about keyword arguments for Ruby 2.0?)

The implementation of call without "call" is another thing: it seems to
be rather hackish at the moment. Expressions like f()() for f = {|| {||
1} } aren't possible, while f()[] is. Perhaps it would be better, to
leave this unchanged, and rely only on the #[] method instead. It would
be easier to explain, that f() is a call to the bound method f of self,
while f[] is a call to the #[] method of object f, which could be a
Proc. f could be bound to an object/class with define_methodf, &f) and
then called from this object's context as f or f().

Ah, and now it's possible to have SyntaxErrors in 1.9, if you first ask
for them:

a = uter
f = {|;a| a = :inner } # local variable name conflict

Is this useful? I don't see, in which case it would be.

 

[Csaba Henk]

The implementation of call without "call" is another thing: it seems to
be rather hackish at the moment. Expressions like f()() for f = {|| {||
1} } aren't possible, while f()[] is. Perhaps it would be better, to
leave this unchanged, and rely only on the #[] method instead. It would
be easier to explain, that f() is a call to the bound method f of self,
while f[] is a call to the #[] method of object f, which could be a
Proc. f could be bound to an object/class with define_methodf, &f) and
then called from this object's context as f or f().

What I don't get: why is the restriction that the "(*) falls back to
#call" thingy works ony for locals? Locals are just the most problematic
case!

5(), {|x| x+x}(), $aaa(), @b()

would unambigously mean a hidden call to #call (I mean, without knowing
of the context). Unlike

abc()

which can now mean both self.abc and abc.call, depending on context.

So, given that this sugaring of #call is introduced, if I made any
restrictions, the first case which I would exculde is applying this
construct to locals!

But, rather, I wouldn't restrict then anything. As I see, upon
evaluating some construct, ruby didn't care about the syntactical form,
only the return value of the given chunk of code. That is,

5 + case i
when String; i.to_i
when Numeric; i
else 0
end

works just as fine as

5 + 4

or as

5 + i

A kind of duck typing: if it quacks back a foo, then that foo can be
used as validly as a literal foo. (Aka "statements also have return
values").

Now it's pretty violated by this locals-restricted new syntax, and I
don't see the tradeoff behind. What purpose is served by this
restriction?

Csaba

 

[David A. Black]

Hi --

I think "f = {|| }" is analogous to "def f() end", and I really like it. (To
say the truth, this syntax for lambda is part of the language of my dreams.
It would be even nicer, if the shortcut "f = {}" would be possible as
well, but the empty Hash constructor collides with that syntax. Like others
have said before, I'd rather substitute the hash constructor (but only in
Ruby 2.0) with another syntax to get the "{}". It's associated in C-languages
with "code to be executed" anyway, so it would meet newbie's expectations AND
it would make Ruby more self-consistent.

I don't think making Ruby resemble other languages makes it
*self*-consistent, but rather more consistent with languages other
than itself. I'm also not a big believer in meeting nubies'
expectations. Especially for Ruby 2.0... it's definitely past the
point of needing to "make <other language> programmers feel at home."
They will, if they like Ruby, and meanwhile it's important for Ruby
programmers to feel at home

BTW: Is a syntax planned to define default values for blocks? It would be
good to be able to define a method
def f(x = 1) 2 * x end
with a block like
define_methodf) { |x=1| 2 * x }
I think blocks and methods should be as similar as possible, and this would
help a lot. (Or what about keyword arguments for Ruby 2.0?)

There's a strong case to be made for unification of blocks, lambdas,
Procs, and methods. I'm not sure where Matz stands on that at the
moment.


David

 

[David A. Black]

Hi --

David A. Black ha scritto:


notice that it is not a lambda thing.. is something done for callable
objects:

=> "yuk yukl"

I think of it as to_str, a way to duck type a callable.

But this notion of "a callable" collapses things which really aren't
the same.

If I can do this:

a = Object.new; def a.call(x); end
def b(x); end

a(10)
b(10)

but I can't do this:

c = [a,b]

because one of these is an object reference and the other is a method
identifier, then the parallel is only partial and, in my view, causes
more problems than it solves.

If lambdas and methods were completely unified, and really flowed into
each other, that would be different. But this is a kind of selective
magic that obscures a difference between them without redesigning the
difference away.


David