Brian Candler wrote:
> On Thu, Nov 27, 2008 at 03:32:18AM +0900, Francoys wrote:
>   
>> declaring variables inside a method that are accessibles to all the
>> nested methods.
>>     
>
> You can do this with closures:
>
>   f = lambda { |a|
>     x = 0
>     g = lambda { |b|
>       x += b
>     }
>     a.each { |e| g[e] }
>     x
>   }
>   puts f[[1,2,3]]
>
> Or else you have objects and instance variables.
>
>   
>> If someone have a 'rubyly correct' way's to solve my problem. I'm am
>> open. But keep in mind this: Prolog is a slow langage, so every
>> performance gain count !
>>     
>
> Then I might question whether Ruby is the correct implementation platform
> for Prolog, except perhaps as a learning exercise (in which case performance
> isn't important)
>
>   
>> As who see, i am facing a real life situation where nested methods seem
>> very useful and the more elegant solution.
>>     
>
> Note that when you write
>
>   def foo
>     ... body
>   end
>
> then it's the *execution* of "def foo ... end" which creates and defines the
> method foo on the object. But the body is not executed until the time when
> foo is called.
>
> Maybe a def which occurs inside a method body (or block) would have to
> become an alias for
>
>    foo = lambda { 
>      ...
>    }
>
> instead. Unfortunately, this particular foo would be called using foo.call
> or foo[], not foo().
>
> Regards,
>
> Brian.
>
>
>   
Brian: It's have everything to do with variable and nothing about function


-------------------------------------------------------------------------
technic 1 (bad)

a_list = # a big link list
b_list = # another big link list
c_list = # result of operation on a_list and b_link

def foo1(x,y,z)
   .....
end

def foo2(x,y,z)
   ......
end

def foo3(x,y,z)
   .....
end

# le content of a_lst, b_lst, c_lst are will be modify by foo1, foo2, foo3
foo(x,y,z)
   a_lst, b_lst, c_lst = foo1(x,y,z)
   a_lst, b_lst, c_lst = foo2(a_lst, b_lst, c_lst)
   a_lst, b_lst, c_lst = foo3(a_lst, b_lst, c_lst)
   return a_lst, b_lst, c_lst
end

p( foo(a_list, b_list, c_list))
# in this case scenario: 6 lists ares needed !
-------------------------------------------------------------------------
technic 2 (faster and better because it's create less list, but i do not
like globals variables)

$a_list = # a big link list
$b_list = # another big link list
$c_list = # result of operation on a_list and b_link

def foo1()
  op1($a_list,$b_list,$c_list)
end

def foo2()
   op2($a_list,$b_list,$c_list)
end

def foo3()
   op2($a_list,$b_list,$c_list)
end

foo()
   foo1()
   foo2()
   foo3()
end

foo()
p $a_list, $b_list, $c_list

# in this case scenario: 3 lists ares needed !
-------------------------------------------------------------------------
technic 3 (faster, and smarter because lists cease to exist with the end
of execution of p )

foo()
   a_list = # a big link list
   b_list = # another big link list
   c_list = # result of operation on a_list and b_link

   def foo1()
     op1(a_list,b_list,c_list)
    end

    def foo2()
       op2(a_list,b_list,c_list)
    end

    def foo3()
      op2(a_list,b_list,c_list)
    end

foo1()
foo2()
return foo3()
end

p foo()

-----------------------------------------------------------------------------------

An prolog's interpreter done with an interpretor. I would probably
questioned the sanity of the programmer, myself.
But it is a Prolog engine ( a WAM class) that could be used as an
interpretor.
   
As you know, Prolog is a zombie language ( not really dead, not really
alive ...)
The basics types of Prolog are : Int , Char and Prolog list.

Replace theses types with Ruby objects and Prolog list and you have a
very different mix in the blender with lot a potential, a kind of
Prolog++ with domain and classes.

All the existing implementation never seem to have the rights primitives.
If you give to the programmer the possibility to extent with theres owns
primitives in Ruby,
you got something lot more flexible.

Why a WAM class? For the same reason of the Continuation class exist.
To make great thing with fews lines of code.
And for some types of problems, declarative language are unbeatable.