New block notation (was: Re: ruby-dev summary 26468-26661)

threshold < lisp and threshold > perl

:wink:

-a

ยทยทยท

On Fri, 5 Aug 2005, David A. Black wrote:

Hi --

On Fri, 5 Aug 2005, Florian Frank wrote:

If the ->() syntax stays, we should get used to cartoon character
swearing jokes like Perlers had to. :wink:

That's a good reason for it not to stay. I wish there were some way
to predict. As I've said, I fear the same thing (too much
punctuation), but it's so hard to know where the threshold is.

--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
My religion is very simple. My religion is kindness.
--Tenzin Gyatso

===============================================================================

daz wrote:

Yes. The second is the show-stopper:

                          ^^^^^^^^^^^^

I wonder what the English language will become after a couple decades
more of misuse by computer scientists...

Webster's New World:

    1 a song or sequence in a musical theater production, show, etc. so
      exciting or impressive that applause from the audience interrupts
      the performance
    2 anything so exciting, impressive, showy, etc. that it
      attracts much attention

The Free On-line Dictionary of Computing:

    A hardware or (especially) software {bug} that makes an
    implementation effectively unusable; one that absolutely has to be
    fixed before development can go on. Opposite in connotation from
    its original theatrical use, which refers to something stunningly
    *good*.

It's saddening, isn't it?,
        nikolai

ยทยทยท

--
Nikolai Weibull: now available free of charge at http://bitwi.se/\!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

Hi,

ยทยทยท

In message "Re: new block notation (was: Re: ruby-dev summary 26468-26661)" on Fri, 5 Aug 2005 17:00:04 +0900, Jeff Wood <jeff.darklight@gmail.com> writes:

I haven't heard any comment from you on the with do and the def with style

hash.each with a,b do
#blah
end

I am not going to add a new reserved word for the problem which is not
that important. I will not change the block syntax. I don't want to
break any compatibility for this issue.

              matz.

Hi,

ยทยทยท

In message "Re: new block notation (was: Re: ruby-dev summary 26468-26661)" on Fri, 5 Aug 2005 22:25:28 +0900, Gavin Kistner <gavin@refinery.com> writes:

Will lambdas be interchangeable with methods? Or do you envision the
future of Ruby as still having at least three distinct functional items:
  * Blocks
  * Lambdas (whatever the syntax)
  * Methods

(And by distinct, I mean more than just different syntax for defining
them; that internally they will be different, non-interchangeable
objects.)

They are all different for good reasons, but I do want to keep them
all quack like ducks. They all can be invoked by "call". They all
can tell numbers of their arguments by using "arity". They all can be
supplied as block arguments prefixing '&'.

              matz.

Hi,

Why not go with lambda(arg-list) { body } or fun(arg-list) { body }
or def(arg-list) { body } then? I think that the syntax would point
out that this is more than a method that turns a block into an object
and I think that it would be a simple solution.

Introducing a new reserved word possibly break existing code. Besides
that, there's no good candidate for a new keyword: lambda is too
awkward, def is not sufficient since we don't define anything here,
and I expect the name fun is used everywhere as local variable names.

"->" might appear weird at first. But it doesn't break any code.
Pure addition to the current syntax. And it's short enough to
encourage functional programming. The last one is my optimistic
estimation. There's an opposite possibility that it would be used
only to obfuscate code.

              matz.

ยทยทยท

In message "Re: new block notation (was: Re: ruby-dev summary 26468-26661)" on Sat, 6 Aug 2005 00:26:17 +0900, Florian GroรŸ <florgro@gmail.com> writes:

Hi --

ยทยทยท

On Sat, 6 Aug 2005, Daniel Brockman wrote:

"David A. Black" <dblack@wobblini.net> writes:

I'm still not seeing how

   [:]

or

   [=>]

conveys the notion of 'emptiness' better than

   {}

The reason people are suggesting the [:] syntax is to avoid
the confusion with blocks. Since {} doesn't avoid the
confusion with blocks, [:] is in this sense better.

I may be taking the discussion in a circle, but... what confusion with
blocks? (I'm confused about the confusion :slight_smile:

David

--
David A. Black
dblack@wobblini.net

Hi --

ยทยทยท

On Fri, 5 Aug 2005, Ara.T.Howard wrote:

On Fri, 5 Aug 2005, David A. Black wrote:

Hi --

On Fri, 5 Aug 2005, Florian Frank wrote:

If the ->() syntax stays, we should get used to cartoon character
swearing jokes like Perlers had to. :wink:

That's a good reason for it not to stay. I wish there were some way
to predict. As I've said, I fear the same thing (too much
punctuation), but it's so hard to know where the threshold is.

threshold < lisp and threshold > perl

More punctuation than Perl? We'll have to agree to disagree.... :slight_smile:

David

--
David A. Black
dblack@wobblini.net

gawd i need coffee ;-(

   lisp < threshold and threshold < perl

eeks.

-a

ยทยทยท

On Fri, 5 Aug 2005, Ara.T.Howard wrote:

On Fri, 5 Aug 2005, David A. Black wrote:

Hi --

On Fri, 5 Aug 2005, Florian Frank wrote:

If the ->() syntax stays, we should get used to cartoon character
swearing jokes like Perlers had to. :wink:

That's a good reason for it not to stay. I wish there were some way
to predict. As I've said, I fear the same thing (too much
punctuation), but it's so hard to know where the threshold is.

threshold < lisp and threshold > perl

:wink:

--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
My religion is very simple. My religion is kindness.
--Tenzin Gyatso

===============================================================================

Nikolai Weibull wrote:

daz wrote:

> Yes. The second is the show-stopper:
                          ^^^^^^^^^^^^

I wonder what the English language will become after a couple decades
more of misuse by computer scientists...

I'm not sure if you're requesting an apology or an excuse or both or neither :wink:

If it helps, I'm not a CS and, being English, I abuse the language regularly.

It's saddening, isn't it?,
        nikolai

It would be if the intended meaning couldn't be inferred from the context.

daz

Nikolai Weibull wrote:

Yes. The second is the show-stopper:

                          ^^^^^^^^^^^^

I wonder what the English language will become after a couple decades
more of misuse by computer scientists...

Languages change a lot. Sometimes language change can't be avoided even if you don't agree with it. Same for Ruby, I guess.

Excellent on the quacking front. Does the following summary describing the intended future? (I suspect it has holes...I'd like to fill in the right details, so that I can understand fully the intended future, and explain the rationale to my friends.)

ยทยทยท

On Aug 6, 2005, at 1:57 AM, Yukihiro Matsumoto wrote:

They are all different for good reasons, but I do want to keep them
all quack like ducks. They all can be invoked by "call". They all
can tell numbers of their arguments by using "arity". They all can be
supplied as block arguments prefixing '&'.

-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_

Ruby2 will have distinct objects for Methods, Blocks, and anonymous, first-class functions ("Lambdas").

Each of the three will have a different syntax for defining them.

All three are sections of code that take arguments and return one or more values (aka functions).

All three support specifying default values for some or all arguments.

All three support can report the number of defined arguments ("arity").

All three can be passed to each other as a 'block', which may be invoked using #yield inside the code.

It is possible to invoke all three in an arbitrary scope (where 'self' and instance variables refer to a specific, runtime-chosen instance of any class) by passing them as a block to a special #instance_eval type method. (?Not true for 1.8...true for 2?)

It is possible to get a reference to a method and assign it to a variable.

A method reference is tied to a specific instance. 'self' and instance variables refer to that instance. It is possible to invoke a method reference in the scope of the instance to which it is tied without supplying the instance as a receiver.

It is possible to bind a method reference to a new instance. (?By unbinding it and rebinding the UnboundMethod to the new instance?)

Passing too many or too few arguments to a method will result in a runtime error.

Methods are not closures.

It is possible to get a reference to a Lambda and assign it to a variable.

Lambdas are not associated with any specific instance. 'self' and instance variables inside a lambda refer to the scope in which it was defined. (?Except when passed to #instance_eval?)

A reference to a lambda can be invoked. (?What scope?)

Passing too many or too few arguments to a lambda will result in a runtime error.

Lambdas are closures.

It is possible to get a reference to a block and assign it to a variable.

Blocks are associated with the instance that is the receiver of the method to which they are passed. 'self' and instance variables refer to that instance.

A reference to a block can be invoked. (#yield supplies the current scope? What about #call?)

Passing too many or too few arguments to a block will result in a runtime error.

Blocks are closures.

-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_

If the above is correct, then the future differences will simply be:
1) Methods are not closures; Lambdas and Blocks are.
2) Methods and Lambdas require specific arguments; Blocks do not.
3) Methods are associated with an instance; Lambdas and blocks are not.
4) All three have different syntaxes.

Hi --

ยทยทยท

On Sat, 6 Aug 2005, Yukihiro Matsumoto wrote:

Hi,

In message "Re: new block notation (was: Re: ruby-dev summary 26468-26661)" > on Sat, 6 Aug 2005 00:26:17 +0900, Florian GroรŸ <florgro@gmail.com> writes:

>Why not go with lambda(arg-list) { body } or fun(arg-list) { body }
>or def(arg-list) { body } then? I think that the syntax would point
>out that this is more than a method that turns a block into an object
>and I think that it would be a simple solution.

Introducing a new reserved word possibly break existing code. Besides
that, there's no good candidate for a new keyword: lambda is too
awkward, def is not sufficient since we don't define anything here,
and I expect the name fun is used everywhere as local variable names.

If proc and Proc.new behave the same, you could un-deprecate proc.

David

--
David A. Black
dblack@wobblini.net

"David A. Black" <dblack@wobblini.net> writes:

Hi --

"David A. Black" <dblack@wobblini.net> writes:

I'm still not seeing how

   [:]

or

   [=>]

conveys the notion of 'emptiness' better than

   {}

The reason people are suggesting the [:] syntax is to avoid
the confusion with blocks. Since {} doesn't avoid the
confusion with blocks, [:] is in this sense better.

I may be taking the discussion in a circle, but... what confusion
with blocks? (I'm confused about the confusion :slight_smile:

I shouldn't have said confusion, but ambiguity, or conflict.

In 1.9, {} is a hash while {||} is a proc. If the {} syntax
were freed up to be used exclusively by blocks/procs, we
could have {} and {||} be procs, while [:] would be a hash.

I guess the confusion is this:

   {} # hash
   {||} # proc
   foo {} # block
   foo({}) # hash
   foo {||} # block
   foo({||}) # proc

Compare that to the arguably saner

   {} # proc
   {||} # proc
   foo {} # block
   foo({}) # proc
   foo {||} # block
   foo({||}) # proc
   [:] # hash
   foo [:] # hash
   foo([:]) # hash

ยทยทยท

On Sat, 6 Aug 2005, Daniel Brockman wrote:

--
Daniel Brockman <daniel@brockman.se>

Yukihiro Matsumoto wrote:

>Why not go with lambda(arg-list) { body } or fun(arg-list) { body } >or def(arg-list) { body } then? I think that the syntax would point >out that this is more than a method that turns a block into an object >and I think that it would be a simple solution.

Introducing a new reserved word possibly break existing code. Besides
that, there's no good candidate for a new keyword: lambda is too
awkward, def is not sufficient since we don't define anything here,
and I expect the name fun is used everywhere as local variable names.

Should be okay as long as it isn't used as a method name. The 1.9 () on local variables change was undone after all, right?

Having fun as a method name sounds bad. Same as having method1, method2 etc.. It could have been used as an accessor, though, but I think self.fun would be save to do as well.

I'm not sure I agree with lambda being too awkward. It would be awkward if we didn't also have blocks.

And JavaScript uses function and C# delegate both of which are more awkward than lambda.

Of course there is also Perl's sub.

def might not totally fit (it doesn't bind anything to a name), but it might still be the best choice if no new semi-keywords should be introduced. There's also undef, of course, but that is a more evil choice. :slight_smile:

"->" might appear weird at first. But it doesn't break any code.
Pure addition to the current syntax. And it's short enough to
encourage functional programming. The last one is my optimistic
estimation. There's an opposite possibility that it would be used
only to obfuscate code.

I know that Huffman encoding is better, but I think it does not take into account that human beings are better at remembering words than symbols. OTOH symbols usually stick out more visually, but I don't think I consider that a good thing in the case of lambdas.

(->(a, b) { a + b }).call
{1: ->(a, b) { puts "Hello World" }}
foo(bar: ->(a, b) { a * b }, qux: ->(str) { str.reverse })
funs = [->(a, b) { a - b }, ->(a, b) { a + b}]
funs = [
   ->(a, b) { a - b },
   ->(a, b) { a + b }
]
def adder(a)
   return ->(b) { a + b }
end
adder = ->(a) do
   ->(b) { a + b }
end
search_fun = ->(x: 0, y: 0, width: @width, height: @height, type:
   Types.All, limit: @objects.size, skip: 0, destructive: false,
   &block) do
   block ||= ->(object) { true }
   found =
   pos = 0

   @objects.reject! do |object|
     if object.x.between?(x, x + width) and
       object.y.between?(y, y + height) and
       type & object.type != 0 and
       block.call(object)
     then
       pos += 1
       if pos >= skip and pos < limit + skip
         found << object

         destructive
       end
     end
   end

   found
end

fun(a, b) { a + b }.call
{1: fun(a, b) { puts "Hello World" }}
foo(bar: fun(a, b) { a * b }, qux: fun(str) { str.reverse })
funs = [fun(a, b) { a - b }, fun(a, b) { a + b }]
funs = [
   fun(a, b) { a - b },
   fun(a, b) { a + b }
]
def adder(a)
   return fun(b) { a + b }
end
adder = fun(a) do
   fun(b) { a + b }
end
search_fun = fun(x: 0, y: 0, width: @width, height: @height, type:
   Types.All, limit: @objects.size, skip: 0, destructive: false,
   &block) do
   block ||= fun(object) { true }
   found =
   pos = 0

   @objects.reject! do |object|
     if object.x.between?(x, x + width) and
       object.y.between?(y, y + height) and
       type & object.type != 0 and
       block.call(object)
     then
       pos += 1
       break if pos >= limit + skip
       if pos >= skip then
         found << object

         destructive
       end
     end
   end

   found
end

Just my +1 cents for Florian here. def or even lambda both sound
great to me and feel natural to current Ruby -- the arrow thing is
just plain weird and alien to the language or concepts IMHO.

Cheers,
Navin.

ยทยทยท

Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

In message "Re: new block notation (was: Re: ruby-dev summary 26468-26661)" > on Sat, 6 Aug 2005 00:26:17 +0900, Florian GroรŸ <florgro@gmail.com> writes:

>Why not go with lambda(arg-list) { body } or fun(arg-list) { body }
>or def(arg-list) { body } then? I think that the syntax would point
>out that this is more than a method that turns a block into an object
>and I think that it would be a simple solution.

Introducing a new reserved word possibly break existing code. Besides
that, there's no good candidate for a new keyword: lambda is too
awkward, def is not sufficient since we don't define anything here,
and I expect the name fun is used everywhere as local variable names.

"->" might appear weird at first. But it doesn't break any code.

daz wrote:

Nikolai Weibull wrote:

> daz wrote:

> > Yes. The second is the show-stopper:
> ^^^^^^^^^^^^
>
> I wonder what the English language will become after a couple
> decades more of misuse by computer scientists...

I'm not sure if you're requesting an apology or an excuse or both or
neither :wink:

Oh, neither, sorry. I just felt like pointing out how vimfully people
using computers will "change" the English language. I'm certainly not
placing blame.

> It's saddening, isn't it?,

It would be if the intended meaning couldn't be inferred from the
context.

Sadly (hihi), that's not always the case,
        nikolai

ยทยทยท

--
Nikolai Weibull: now available free of charge at http://bitwi.se/\!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

Florian GroรŸ wrote:

Nikolai Weibull wrote:

> > Yes. The second is the show-stopper:
> ^^^^^^^^^^^^
>
> I wonder what the English language will become after a couple decades
> more of misuse by computer scientists...

Languages change a lot. Sometimes language change can't be avoided even
if you don't agree with it. Same for Ruby, I guess.

Yes, nice analogy ;-). However, there's a difference between change and
plain misuse; operator overloading in C++ comes to mind,
        nikolai

ยทยทยท

--
Nikolai Weibull: now available free of charge at http://bitwi.se/\!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

Gavin,

Blocks are closures.

What meaning do you assign to the term `closure'?

ยทยทยท

--
Daniel Brockman <daniel@brockman.se>

2) Methods and Lambdas require specific arguments; Blocks do not.

That's the ONLY difference between lambdas and blocks? I'm not even
sure what that means. I assume you mean that the "binding" of a block
is to the receiver, whereas for a lambda to the context in which it is
defined?

Please correct me if any of this is in error.

If it is correct, I don't see how that's a signifficant difference to
constitute them being seperate things. How are they seperate things
anyway --I never say Block.new.

T.

Hi --

ยทยทยท

On Sun, 7 Aug 2005, Daniel Brockman wrote:

"David A. Black" <dblack@wobblini.net> writes:

I may be taking the discussion in a circle, but... what confusion
with blocks? (I'm confused about the confusion :slight_smile:

I shouldn't have said confusion, but ambiguity, or conflict.

In 1.9, {} is a hash while {||} is a proc.

I'm not seeing that:

$ /usr/local/lib/ruby-cvs/bin/ruby -ve '{||}'
ruby 1.9.0 (2005-08-06) [i686-linux]
-e:1: parse error

David

--
David A. Black
dblack@wobblini.net