Forum: Ruby Assigning a block to a variable in Ruby

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
4ba3ae13a83b4535bcb96489785ace53?d=identicon&s=25 unknown (Guest)
on 2005-12-15 18:00
(Received via mailing list)
I am new to Ruby and curious as to how you emulate the following
Javascript snippet
(example in Windows, hence the call to Echo)

var a = function(p) {WScript.Echo(p)}

bar(a);

function bar(z)
	{
	z(1);
	WScript.Echo(z);
	}

which would of course create an anonymous function, assign it to
variable a, pass this as a parameter to function bar() and then
evaluate the function with parameter 1, then attempt to print the
function itself (which Javascript will do, printing the text of the
block)

I found Ruby quite intuitive until I tried

a = {some block}

and found that this of course doesn't work as in this context {} refers
to a hash.

Ok, that's fine, but the 'yield' statement seems very funky and Perlish
to me. Effectively a block passed to a routine exists as a 'hidden'
argument so that

foo(100) {someblock}

in Ruby passes one parameter explicitly (as we would see from foo's
defined argument list) and a 'hidden' block which 'yield' inside the
body of foo() would evaluate.

(though, oddly, yield {someblock} is also not valid Ruby).

This seems horribly inelegant for a language touted as being The Next
Great Thing.

It is also unclear, how, then, I pass down a block as an argument and
then in turn pass it again to a child routine.

I can see how a parameter to a block works - this is clearly borrowed
from Smalltalk - but Javascript doesn't enforce separation of dynamic
code in the way Ruby appears to.

At present Javascript's syntax looks much cleaner. Am I missing
something?

Also, I presume Ruby is a forward-referencing language only, unlike
Javascript, where I can declare a function after code which calls it.
Ruby didn't seem to like that much.
36958dd94ca666a38483df282a5214d5?d=identicon&s=25 Peter Ertl (Guest)
on 2005-12-15 18:06
(Received via mailing list)
Maybe you are looking for something like that?

> p = lambda {|num| puts num }

> p.call(123)
123
E2a9d30a2487a924165aaaa016b54f87?d=identicon&s=25 C Erler (Guest)
on 2005-12-15 18:06
(Received via mailing list)
On 15/12/05, ajmayo@my-deja.com <ajmayo@my-deja.com> wrote:
>         z(1);
>
>
> then in turn pass it again to a child routine.
> Ruby didn't seem to like that much.
>
>
>

Blocks that are objects are called procs, in Ruby (class Proc).  To
make one the way you want to, you simply put proc in front of it :

my_block = proc { |vars| stuff_to_do }

To use proc variables as blocks for methods, put &my_block, which lets
Ruby know your proc isn't a normal parameter, it's the block :

array.each &my_block
E2a9d30a2487a924165aaaa016b54f87?d=identicon&s=25 C Erler (Guest)
on 2005-12-15 18:18
(Received via mailing list)
On 15/12/05, ajmayo@my-deja.com <ajmayo@my-deja.com> wrote:
> Also, I presume Ruby is a forward-referencing language only, unlike
> Javascript, where I can declare a function after code which calls it.
> Ruby didn't seem to like that much.

Ruby will usually wait until code is actually run to check if
something is defined.  So, if Ruby says that something doesn't exist
in your code, the code is being run right then (like when you do stuff
inside class x ... end, all of it is run right away).  So, you can do
things like have two classes that each make an object of the other
class, all without needing things like prototypes in C :

class A
  def make_it
    @b = B.new
  end
end

class B
  def make_it
    @a = A.new
  end
end

This is because those class names are just global variables
(technically, constants that can be changed) that have a classes
assigned to them.  Thus, you can do weird things like assign classes
to variables :

a = Hash
h = a.new

This allows you to do things like pass classes into methods so that
those methods can do whatever they want with the classes.

Hope this helps.
E2a9d30a2487a924165aaaa016b54f87?d=identicon&s=25 C Erler (Guest)
on 2005-12-15 18:27
(Received via mailing list)
Sorry, missed this part :

On 15/12/05, ajmayo@my-deja.com <ajmayo@my-deja.com> wrote:
> It is also unclear, how, then, I pass down a block as an argument and
> then in turn pass it again to a child routine.

There are two ways to do this: the block variable way and the normal
parameter way.

If you want to pass it as a block (it has to be the last parameter) :

def method other_parameters, &the_block
  use_the_block_as_a_regular_parameter_for_this_method(the_block)
  use_the_block_as_a_block_for_this_method(&the_block)
end

method param { |vars| block }

If you want to pass it as a normal parameter (it doesn't have to be
the last parameter) :

def method other_parameters, the_parameter
  use_the_block_as_a_regular_parameter_for_this_method(the_parameter)
  use_the_block_as_a_block_for_this_method(&the_parameter)
end

my_proc = proc { |vars| block }
method param, my_proc

So, basically, & is the thing that makes a parameter the block (when
you're defining the method and when you're calling it).
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2005-12-15 18:34
(Received via mailing list)
On Dec 15, 2005, at 11:57 AM, ajmayo@my-deja.com wrote:

> Also, I presume Ruby is a forward-referencing language only, unlike
> Javascript, where I can declare a function after code which calls it.
> Ruby didn't seem to like that much.

How did you run into problems with this?

irb(main):024:0> def a(x)
irb(main):025:1>     g(x)
irb(main):026:1> end
=> nil
irb(main):027:0> def g(x)
irb(main):028:1>    puts x
irb(main):029:1> end
=> nil
irb(main):030:0> a(5)
5
=> nil

As regards your other question

def bar(z)
     puts z
end

a = lambda { |x| puts x }

bar(a)



Alternatively to pass a block to a function without yield...

def bar(&block)
        block.call
end

bar { puts "hi!" } #=> prints hi
4ba3ae13a83b4535bcb96489785ace53?d=identicon&s=25 unknown (Guest)
on 2005-12-15 18:43
(Received via mailing list)
Amazing!. Couldn't be more than 10 mins since I posted and 3 replies!.

Thanks very much....

In that time, before I saw these posts, I came up with the following

def foo(p)
p.call(100)
end

a = Proc.new {|b| puts b}
foo(a)

but now I see that presumably proc (in lowercase) is presumably a
static class method and will work equally well.

i.e as you say

a = proc {|b| puts b}

Oddly, there is an inconsistency here

q = String("abc")

q = String.new("abc")

are both legal but

q = string("abc")

is not, which you would extrapolate by extension from the Proc/proc
analogy. (because

a=Proc {....}

is not legal.

In fact, perusing the documentation, I can't see how I would have
figured out the alternative mechanism using proc in lowercase - where
is this documented?

why I am keen to understand this is because languages like Perl are
infuriating because things like filehandles have special 'magic'
properties which get lost if you, for example, try to store them in a
hash, etc. This sort of thing destroys the illusion of completeness
that a truly great scripting language must provide, IMHO.

I see some hints of LISP here, too, with lambda!. A wonderful brew of
language features!
2cf6d8e639314abd751f83a72e9a2ac5?d=identicon&s=25 Martin DeMello (Guest)
on 2005-12-15 18:49
(Received via mailing list)
ajmayo@my-deja.com wrote:
> evaluate the function with parameter 1, then attempt to print the
> function itself (which Javascript will do, printing the text of the
> block)

Ruby does not do this.

martin
4ba3ae13a83b4535bcb96489785ace53?d=identicon&s=25 unknown (Guest)
on 2005-12-15 18:52
(Received via mailing list)
WRT forward references. My code was just

foo(100)

def foo(p)
puts p
end


this will not work unless the call to foo is placed after the function
definition.

Whereas in Javascript that would compile.

I can see that functions can forward reference, so I guess the logical
reason for this is, as you say, that Ruby wants to be able to resolve
as it executes, therefore

p = proc {foo(100)}

def foo(p)
puts p
end

p.call


will also compile, although foo() is a forward reference, because we
don't attempt to execute the call to foo until after Ruby has parsed
the function
36958dd94ca666a38483df282a5214d5?d=identicon&s=25 Peter Ertl (Guest)
on 2005-12-15 18:58
(Received via mailing list)
> Whereas in Javascript that would compile.

there is no such thing as compilation in javascript or ruby...

wikipedia:
A compiler is a computer program that translates a series of statements
written in one computer language (called the source code) into a
resulting
output in another computer language (often called the object or target
language).
04bd97396a23bebf19887fd041e15123?d=identicon&s=25 Esteban Manchado =?iso-8859-1?Q?Vel=E1zquez?= (Guest)
on 2005-12-15 19:01
(Received via mailing list)
Hi,

On Fri, Dec 16, 2005 at 01:57:41AM +0900, ajmayo@my-deja.com wrote:
> 	z(1);
>
> a = {some block}
>
> and found that this of course doesn't work as in this context {} refers
> to a hash.

    You can use:

    a = lambda {some block}

> Ok, that's fine, but the 'yield' statement seems very funky and Perlish
> to me.

    Sorry, I don't see the connection :-?

> Effectively a block passed to a routine exists as a 'hidden'
> argument so that
>
> foo(100) {someblock}
>
> in Ruby passes one parameter explicitly (as we would see from foo's
> defined argument list) and a 'hidden' block which 'yield' inside the
> body of foo() would evaluate.
>
> (though, oddly, yield {someblock} is also not valid Ruby).

    yield is to _call_ a given block. You do things like:

def foo(bar)
    yield "foo, #{bar}!"
end

foo("world") do |i|
    puts i
end

> This seems horribly inelegant for a language touted as being The Next
> Great Thing.
>
> It is also unclear, how, then, I pass down a block as an argument and
> then in turn pass it again to a child routine.

    Easy:

def some_method
    yield "some value"
end

def foo(bar, &blk)
    some_method(&blk)
end

foo(1) do |i|
    puts i
end

I.e. every time you put an ampersand before a parameter when defining
some
method, you get the block as a Proc object. Every time you put an
ampersand
before a parameter when calling some method, the Proc object is received
as a regular block by the callee.

    Take a look at the first edition of Pickaxe. It's publicly available
at
http://www.ruby-doc.org/docs/ProgrammingRuby/.

> I can see how a parameter to a block works - this is clearly borrowed
> from Smalltalk - but Javascript doesn't enforce separation of dynamic
> code in the way Ruby appears to.
>
> At present Javascript's syntax looks much cleaner. Am I missing
> something?

    Hope the above clears up some confusion.

> Also, I presume Ruby is a forward-referencing language only, unlike
> Javascript, where I can declare a function after code which calls it.
> Ruby didn't seem to like that much.

    So, why not just use Javascript? :-)
36958dd94ca666a38483df282a5214d5?d=identicon&s=25 Peter Ertl (Guest)
on 2005-12-15 19:16
(Received via mailing list)
what eternal goal do you want to achieve
with your strange code snippet anyway?

if you want to pass functions as arguments then
lambda / proc does just what you want...
Fafbe7fc27ab8e96a7cb732de5039a87?d=identicon&s=25 unknown (Guest)
on 2005-12-15 19:34
(Received via mailing list)
I'm writing a simple script that talks to a device on a PC serial port.
I
need to be able to set the port settings (baud, bits, parity) but I have
not found a way to do this.  How can I do this?

This script will run in a DOS window on Windows, but I might need to use
it with Linux later.
E2a9d30a2487a924165aaaa016b54f87?d=identicon&s=25 C Erler (Guest)
on 2005-12-15 21:14
(Received via mailing list)
On 15/12/05, ajmayo@my-deja.com <ajmayo@my-deja.com> wrote:
> In fact, perusing the documentation, I can't see how I would have
> figured out the alternative mechanism using proc in lowercase - where
> is this documented?

It's a Kernel (which has a bunch of generally useful methods, like
puts) method.  Strangely, the core API doesn't seem to have Kernel,
but the Pickaxe does at
http://www.ruby-doc.org./docs/ProgrammingRuby/html... .
 The other big "magic" module is called Module (which has a bunch of
metaprogramming methods for altering classes).
Ddbfebb47432f6599da361df6a135c7c?d=identicon&s=25 Adam Shelly (Guest)
on 2005-12-15 22:45
(Received via mailing list)
On 12/15/05, dperkins@frii.com <dperkins@frii.com> wrote:
> I'm writing a simple script that talks to a device on a PC serial port.  I
> need to be able to set the port settings (baud, bits, parity) but I have
> not found a way to do this.  How can I do this?

I don't know if you can do it directly from ruby, but you can use a
system command.
On windows

irb(main):005:0> system "MODE COM3 BAUD=1200"

Status for device COM3:
-----------------------
    Baud:            1200
    Parity:          Even
    Data Bits:       7
    Stop Bits:       1
    Timeout:         OFF
    XON/XOFF:        OFF
    CTS handshaking: OFF
    DSR handshaking: OFF
    DSR sensitivity: OFF
    DTR circuit:     ON
    RTS circuit:     ON

=> true

C:\>help mode
Configures system devices.

Serial port:       MODE COMm[:] [BAUD=b] [PARITY=p] [DATA=d] [STOP=s]
                                [to=on|off] [xon=on|off] [odsr=on|off]
                                [octs=on|off] [dtr=on|off|hs]
                                [rts=on|off|hs|tg] [idsr=on|off]

...


> This script will run in a DOS window on Windows, but I might need to use
> it with Linux later.
>
I'll let a linux guru tell you the correct command there.

-Adam
0d298cda3121e5cacaa2465437769025?d=identicon&s=25 Levin Alexander (Guest)
on 2005-12-15 23:00
(Received via mailing list)
On 12/15/05, dperkins@frii.com <dperkins@frii.com> wrote:
> I'm writing a simple script that talks to a device on a PC serial port.  I
> need to be able to set the port settings (baud, bits, parity) but I have
> not found a way to do this.  How can I do this?
>
> This script will run in a DOS window on Windows, but I might need to use
> it with Linux later.

On Linux you can use stty:

  `stty -echo raw ospeed 38400 ispeed 38400 < /dev/ttyS0`

You may also want to look at
<http://raa.ruby-lang.org/project/ruby-serialport/>

Viele Grü�e,
Levin
Ec2a9a9da5c8a5f14a0fe2361ae4e08a?d=identicon&s=25 Mark J.Reed (Guest)
on 2005-12-15 23:34
(Received via mailing list)
ajmayo@my-deja.com writes:
>Oddly, there is an inconsistency here

>q = String("abc")

>q = String.new("abc")

>are both legal but

>q = string("abc")

>is not, which you would extrapolate by extension from the Proc/proc
>analogy. (because

>a=Proc {....}

>is not legal.

That's because there's no automatic correlation between the class Proc
and the
method proc.  Lowercase proc is just a static method of the Kernel
module that
returns a Proc: it's there as a convenience, because "proc" is less
typing than
"Proc.new".

There's no corresponding "string" method because you don't need it.
If the only way to get a String were to type String.new, there would
undoubtedly be a Kernel.string as well, but since you can just do this:

q = "abc"

it's not required.  You may not like Perl, but one thing Ruby has
taken from it is the idea that you can overdo orthogonality.
Ec2a9a9da5c8a5f14a0fe2361ae4e08a?d=identicon&s=25 Mark J.Reed (Guest)
on 2005-12-15 23:40
(Received via mailing list)
Martin DeMello <martindemello@yahoo.com> writes:
>ajmayo@my-deja.com wrote:
>> evaluate the function with parameter 1, then attempt to print the
>> function itself (which Javascript will do, printing the text of the
>> block)

>Ruby does not do this.

More specifically: in Ruby, unlike Python and JavaScript, methods are
*not*
variables with closure values.  You can persuade Ruby to turn a method
into a
closure value, but that's not how they live, and methods do not occupy
variable
namespace.  So defining a method 'foo' does not have any affect on the
variable
'foo', or vice versa:

irb(main):001:0> def foo; 1 end # define a method
=> nil
irb(main):002:0> foo            # calls the method
=> 1
irb(main):003:0> foo=2          # create a variable
=> 2
irb(main):004:0> foo            # now this finds the variable
=> 2
irb(main):005:0> foo()          # but the method is still there, too
=> 1
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2005-12-15 23:43
(Received via mailing list)
Hi --

On Fri, 16 Dec 2005, Mark J.Reed wrote:

>
> "Proc.new".
Except... they're not quite identical, and actually as of RubyConf
2003 (I think) Matz agreed that 'proc' would be deprecated in favor of
'lambda', because having something called proc and something called
Proc.new that weren't the same was confusing.

It's still there but hopefully will be phased out soon.


David

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!
912c61d9da47754de7039f4271334a9f?d=identicon&s=25 unknown (Guest)
on 2005-12-15 23:46
(Received via mailing list)
Quoting ajmayo@my-deja.com:

> I am new to Ruby and curious as to how you emulate the following
> Javascript snippet
> (example in Windows, hence the call to Echo)
>
> var a = function(p) {WScript.Echo(p)}

Ruby:

 a = lambda { |p| WScript.Echo(p) }

(assuming Ruby had an appropriate WScript.Echo)

You'd need to call that like:

 a.call("something")

instead of

 a("something")

though.

> It is also unclear, how, then, I pass down a block as an argument
> and then in turn pass it again to a child routine.

If you prefix the last argument in a method definition or call with
&, then it'll be used to pass/receive a block.

 def f(arg, &block)
   g(arg, &block)
 end

 # call it:
 f(1) { ... }

You can employ a lambda (as illustrated above) as a block using this
& notation too.

-mental
2cf6d8e639314abd751f83a72e9a2ac5?d=identicon&s=25 Martin DeMello (Guest)
on 2005-12-16 00:10
(Received via mailing list)
Mark J. Reed <mreed@thereeds.org> wrote:
> method into a closure value, but that's not how they live, and methods
> do not occupy variable namespace.  So defining a method 'foo' does not
> have any affect on the variable
> 'foo', or vice versa:

Actually, what I meant was that ruby does not store the source code of
the method anywhere, so it cannot be introspected.

martin
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2005-12-16 03:14
(Received via mailing list)
On Dec 15, 2005, at 5:41 PM, dblack@wobblini.net wrote:
> Except... they're not quite identical, and actually as of RubyConf
> 2003 (I think) Matz agreed that 'proc' would be deprecated in favor of
> 'lambda', because having something called proc and something called
> Proc.new that weren't the same was confusing.

This is an area that has been a bit fuzzy for me.

Is it fair to say that the only difference between
	Proc.new {#some code}
and
	lambda {#some code}

is the behavior when 'return' is explicitly called in the block?
Are there any other differences?

Am I correct in saying that when a formal argument list explicitly
captures a block:
	def foo(&block);end
that Ruby converts the actual block to a Proc instance via
Proc.new as opposed to Kernel#lambda?

And finally, is there a way to create a lambda-like object via
a class method of Proc or is that behavior only available via
Kernel#lambda?  I seems unusual that Kernel#lambda returns an
instance of Proc but that there is no way to get Proc itself
to generate that type of an object.
F3b7109c91841c7106784d229418f5dd?d=identicon&s=25 Justin Collins (Guest)
on 2005-12-16 04:48
(Received via mailing list)
C Erler wrote:
> On 15/12/05, ajmayo@my-deja.com <ajmayo@my-deja.com> wrote:
>
>> In fact, perusing the documentation, I can't see how I would have
>> figured out the alternative mechanism using proc in lowercase - where
>> is this documented?
>>
>
> It's a Kernel (which has a bunch of generally useful methods, like
> puts) method.  Strangely, the core API doesn't seem to have Kernel,
>

This is a known issue with 1.8.3. The docs for Kernel are missing...

-Justin
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2005-12-16 14:20
(Received via mailing list)
Hi --

On Fri, 16 Dec 2005, gwtmp01@mac.com wrote:

>
> On Dec 15, 2005, at 5:41 PM, dblack@wobblini.net wrote:
>> Except... they're not quite identical, and actually as of RubyConf
>> 2003 (I think) Matz agreed that 'proc' would be deprecated in favor of
>> 'lambda', because having something called proc and something called
>> Proc.new that weren't the same was confusing.
>
> This is an area that has been a bit fuzzy for me.

And for many of us :-)

> Is it fair to say that the only difference between
> 	Proc.new {#some code}
> and
> 	lambda {#some code}
>
> is the behavior when 'return' is explicitly called in the block?
> Are there any other differences?

I think the matter of arity strictness is still different.  Frankly I
could never remember the details, and I know that I am by no means
alone in this.  Basically, lambdas will give you an error if you send
them the wrong number of arguments.  Unless they take only one
argument, in which case you'll get a warning.  If the lambda takes no
arguments, then it doesn't care, unless the no-arguments is specified
with || (instead of just nothing), in which case you have to send
exactly zero arguments.

Procs are different.  They give you the warning sometimes, but I don't
think they ever raise an exception because of wrong number of
arguments.  (I really wish that warning would disappear.)

And so on.  I'm not making fun of it, though it may sound that way.  I
find it genuinely confusing, and it's a bit notorious for this.  If
anyone wishes to come along and claim that it's simple and easy to
remember, please provide instructions for remembering it :-)

> Am I correct in saying that when a formal argument list explicitly
> captures a block:
> 	def foo(&block);end
> that Ruby converts the actual block to a Proc instance via
> Proc.new as opposed to Kernel#lambda?

There's actually no Kernel#lambda (lambda is a keyword, not a method),
but yes, it becomes a Proc.  Although... if you do this:

   meth &lambda { ... }

it remains a lambda in the method (or so it appears from what irb is
telling me).

> And finally, is there a way to create a lambda-like object via
> a class method of Proc or is that behavior only available via
> Kernel#lambda?  I seems unusual that Kernel#lambda returns an
> instance of Proc but that there is no way to get Proc itself
> to generate that type of an object.

Well, lambda is a kind of specialization of Proc -- almost in the
spirit of being a subclass.  So Proc has no knowledge of that
specialization.  I agree that it should be of a different class.  I've
been seeing people (including myself) having a hard time keeping all
of this straight for years.  Not that the users have to be coddled :-)
but I think there's evidence that it is indeed confusing.


David

--
David A. Black
dblack@wobblini.net

"Ruby for Rails: Ruby techniques for Rails developers",
coming April 2006 (http://www.manning.com/books/black)
4ba3ae13a83b4535bcb96489785ace53?d=identicon&s=25 unknown (Guest)
on 2005-12-16 15:23
(Received via mailing list)
Technically, Ruby is really an 'incremental compiler'. That there is no
final code generation step actually doesn't change this.

Normally we make the following distinctions

An INTERPRETER reads source code and processes each symbol in the code
each time it encounters the symbol. This is very inefficient, of
course. Thus a loop with an inner expression will require that the
inner expression be parsed and transformed into an evaluation stack
each time it is encountered. Early versions of BASIC were pure
interpreters, and performance was consequently far removed from native
code.

An INCREMENTAL COMPILER (most scripting languages fall into this
category) transforms source into an internal structure with a symbol
table and expression stacks etc as it reads the source. Subsequently
this structure is modified, but not discarded, if the source is changed
or additional source code is fed into the system. (The first popular
example of an incremental compiler was Microsoft QuickBasic, as far as
I can recall. At the time, this was a miracle to behold). The internal
representation can then be 'executed', usually by what is in effect a
virtual machine within the system.

A TRUE COMPILER normally operates as a batch process. All the tasks
that an incremental compiler performs are done once on the whole source
tree. Subsequently, the code generator emits code either for the native
hardware architecture or for a virtual machine. Source code changes
require that the entire batch process be repeated.

There are also 'just in time' compilers for virtual machines which can,
at runtime, evaluate 'hotspots' in the code which would benefit from
further compilation - more technically, translation - into native
machine code.

It is because modern scripting languages are incremental compilers and
not merely interpreters that their performance is so good. If they were
pure interpreters they would be hundreds of times slower.

Possibly Wikipedia could benefit from some clarification in its
explanation.
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2005-12-16 16:45
(Received via mailing list)
On Dec 16, 2005, at 8:17 AM, dblack@wobblini.net wrote:
> So Proc has no knowledge of that
> specialization.  I agree that it should be of a different class.  I've
> been seeing people (including myself) having a hard time keeping all
> of this straight for years.  Not that the users have to be coddled :-)
> but I think there's evidence that it is indeed confusing.

Thanks for the clarifications Dave.  I wonder if some sort of
unification
of all these rules/behaviors is possible.  I'm not sure exactly what I
mean by that, maybe it is just some better documentation, maybe it is
something else...

> There's actually no Kernel#lambda (lambda is a keyword, not a method),

I assume this is so the parser can make special arrangements while
constructing the AST rather then waiting until the code is actually
executed.  I think matz has mentioned changing eval from a method to a
keyword for this reason, no?
40823088cec28c3224ff4c46ced1beda?d=identicon&s=25 magnus (Guest)
on 2005-12-16 18:24
(Received via mailing list)
Then... possibly you should add such clarifications if yours are in
fact clear?

I can't speak to your accuracy, I'm just saying... it's a wiki... *ahem*
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2005-12-16 19:49
(Received via mailing list)
On Dec 16, 2005, at 12:22 PM, magnus wrote:

> Then... possibly you should add such clarifications if yours are in
> fact clear?
>
> I can't speak to your accuracy, I'm just saying... it's a wiki...
> *ahem*

I assume you mean Ruby garden (http://www.rubygarden.org/ruby)?
That would be a great place to add clarifications to all this stuff but
it isn't the 'official' documentation so that doesn't completely address
the issue.

My comfort level isn't high enough yet to author something myself but
maybe soon...
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2005-12-16 21:59
(Received via mailing list)
On Sat, Dec 17, 2005 at 03:47:10AM +0900, gwtmp01@mac.com wrote:
> That would be a great place to add clarifications to all this stuff but
> it isn't the 'official' documentation so that doesn't completely address
> the issue.

Actually, I think that was in reference to this:

"Possibly Wikipedia could benefit from some clarification in its
explanation."

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.
149379873fe2cb70e550c6bff8fedd0c?d=identicon&s=25 Jeffrey Schwab (Guest)
on 2005-12-17 05:05
(Received via mailing list)
ajmayo@my-deja.com wrote:
> interpreters, and performance was consequently far removed from native
> virtual machine within the system.
> machine code.
>
> It is because modern scripting languages are incremental compilers and
> not merely interpreters that their performance is so good. If they were
> pure interpreters they would be hundreds of times slower.
>
> Possibly Wikipedia could benefit from some clarification in its
> explanation.
>

Don't forget "dynamic translation," a la Smalltalk.  Code is compiled
for a virtual machine, but all VM instructions (not just hot spots) are
translated into native instructions the first time they are encountered.
This topic is locked and can not be replied to.