[#3741] Re: Why it's quiet -- standard distribution issues — Aleksi Niemel<aleksi.niemela@...>
I think it's the feature of the mailing list archive to create a threads of
[#3756] RE: XMP on comments — Aleksi Niemel<aleksi.niemela@...>
> require "xmp"
[#3766] modulo and remainder — Dave Thomas <Dave@...>
[#3776] Kernel.rand — Aleksi Niemel<aleksi.niemela@...>
How about defining:
[#3781] Widening out discussions — Dave Thomas <Dave@...>
[#3795] Re: Array.uniq! returning nil — Aleksi Niemel<aleksi.niemela@...>
> As matz said in [ruby-talk:3785] and Dave said in [ruby-talk:1229],
Hi, Aleksi,
[#3823] Re: Array.pick — Aleksi Niemel<aleksi.niemela@...>
> > Just a general comment--a brief statement of purpose and using
[#3827] JRuby? — Aleksi Niemel<aleksi.niemela@...>
Is there or will there be Ruby equivalent of JPython?
[#3882] Re: Array.uniq! returning nil — Aleksi Niemel<aleksi.niemela@...>
> |look too strange, confusing, or cryptic. Maybe just @, $, %, &.
Hi,
[#3918] A question about variable names... — Dave Thomas <Dave@...>
[#3935] If your company uses Pallets, Skids, Boxes, Lumber, etc. — pallets2@...
[#3956] Tk PhotoImage options — andy@... (Andrew Hunt)
Hi all,
[#3971] Thread and File do not work together — "Michael Neumann" <neumann@...>
following example do not work correctly with my ruby
[#3986] Re: Principle of least effort -- another Ruby virtue. — Andrew Hunt <andy@...>
> Principle of Least Effort.
Hi,
[#4005] Re: Pluggable functions and blocks — Aleksi Niemel<aleksi.niemela@...>
Aleksi makes a question:
[#4008] Ruby installation instructions for Windows — Aleksi Niemel<aleksi.niemela@...>
I had to write these instructions for my friends. I thought it might be nice
[#4043] What are you using Ruby for? — Dave Thomas <Dave@...>
On 15 Jul 2000 22:08:50 -0500,
Hi,
[#4057] Re: What are you using Ruby for? — Aleksi Niemel<aleksi.niemela@...>
Johann:
[#4082] Re: What are you using Ruby for? — Aleksi Niemel<aleksi.niemela@...>
[#4091] 'each' and 'in' — hal9000@...
I just recently realized why the default
[#4107] Re: 'each' and 'in' -- special char problem? — schneik@...
[#4114] Method signature - a question for the group — Dave Thomas <Dave@...>
[#4139] Facilitating Ruby self-propagation with the rig-it autopolymorph application. — Conrad Schneiker <schneik@...>
Hi,
[#4158] Getting Tk to work on Windows — "Michael Neumann" <neumann@...>
Hi....
[#4178] Partly converted English Ruby/Tk widget demo working. — Conrad Schneiker <schneik@...>
Hi,
[#4234] @ variables not updated within method? — Hugh Sasse Staff Elec Eng <hgs@...>
Hugh Sasse Staff Elec Eng <hgs@dmu.ac.uk> writes:
On 27 Jul 2000, Dave Thomas wrote:
[#4267] Ruby.next, Perl6, Python 3000, Tcl++, etc. -- Any opportunities for common implementation code? — "Conrad Schneiker" <schneiker@...>
Hi,
"Conrad Schneiker" wrote:
[ruby-talk:04096] Re: What are you using Ruby for?
> Aleksi Niemel writes:
> > Johann:
...
> This is one thing that I never quite understood about the "pure
> object-oriented languages"---they seem to dislike functions.
> Functions are very real things, quite useful in fact, but their a pain
> to manipulate, at least in Eiffel and Sather.
Hmmm ... I wouldn't say they dislike functions ... I think that
functions are not really necessary if I can have methods and closures!
They seem less powerful, IMHO, than the combination of these both ...
> As an example of what I do in python, I have a program which
> implements several functions over a dataset, then lets the user pick
> which functions to plot from the command line. There are also
> multiple forms of each function, which are (in general) variable
> transformations.
>
> The code looks like:
>
> def make_g_from_f(f):
> def temp(x, y, f=f): # ugly python lack of closures
> return f(x, y)*scale(x, y)
> return temp
>
> def f1(x, y):
> return <something>
> register_function("f1", f1, "Compute something")
>
> g1 = make_g_from_f(f1) # useful python 1st-class functions
> register_function("g1", g1, "Compute something scaled by scale")
The closed (without thinking) I come at the first glance could be:
def make_g_from_proc(f)
return proc { |x, y| return f.call(x,y)*scale(x,y) }
end
def f1(x, y)
return <something>
end
register_proc("f1", method(:f1), "compute something")
g1 = make_g_from_proc(method(:f1))
register_proc("g1", g1, "compute something scaled by scale")
This tries to resemble as much Python's solution as possible. The only
big difference is that you have to pass a Proc instance to
make_g_from_proc ... So passing a method would need to get the method
first and convert it into a Proc instance!
If I would use closures on all places where I would use a function in
Python, then I would even not have to convert a method to an Proc
instance ... something like:
f1 = proc { |x, y| return <something> }
register_proc("f1", f1, "compute someting")
g1 = make_g_from_proc(f1)
register_proc("g1", g1, "compute something scaled by scale")
...
> As I understand Ruby, I would have to make all of these functions into
> global Proc objects and use $-names to reference them, if I want f1
> and g1 to be callable using the same conventions. That seems like it
> would get very ugly very fast.
If you insisting of same call convention and global accessible names,
perhaps! But no, wait a moment. There is a solution, not very elegant
but ...
def f1
return proc { |x, y| return <something> }
end
f1.call(1,2)
register_proc "f1", f1, "compute something"
g1 = make_g_from_proc f1
register_proc "g1", g1, "compute something scaled by scale"
Now it looks equal and you have to use the same calling
convention. But I admit this is not too pretty ... Especially as
calling it via f1.call will do one indirection indeed!
But I would try to solve this in a more OO way ... Using closures
resembling functions! Store them in a certain module/class that
indicates that these closures are thought to work on certain data for
computation ...
...
\cle