In your opinion....

[Daniel Lewis]

" But if you really want to understand how it works, you
need to understand the monad, which is quite an esoteric mathematical
notio " - Christophe Grandsire

I thought I had heard of Monads before, I found this:
" Leibniz's theory does not posit physical space; rather, physical
objects are constructs of the collective experiences of monads. This
way of putting it is misleading, however; monads do not interact with
each other (are "windowless"), but rather are imbued at creation with
all their future experiences in a system of pre-established harmony.
The arrangements of the monads make up the faith and structure of this
world, which to Leibniz was "the best of all possible worlds". " -
Wikipedia

I've read about Leibniz before.

Wikipedia also says:
"
* in non-standard analysis, a monad consists of all those numbers
infinitesimally close to a given number;
* in category theory, a monad, also known as triple, is a type of
functor important in the theory of adjoint functors. This term has a
different root than the ones described above; it was formed by
combining "monoid" and "triad". See monad (category theory).
* In pure functional programming languages such as Haskell, monads
are used as data types that encapsulate the functional I/O-activity,
in such a manner that the side-effects of I/O are not allowed to
spread out of the part of the program that is not functional
(imperative). See monads in functional programming.
"
I am still intrigued to find out how this would work in Ruby... maybe
something to do before I start my dissertation in April (2006). Has
anyone used Ruby in a "functional" way before?

My experience of Ruby so far:
* I have been using it for about 2 months now, I have made two
commercial applications:
(1) An additional component to a C++/Qt program to connect to a MySQL
database and collect data and turn it into a CSV file. It uses the
MySQL/Ruby module.
(2) A configuration file maker for (1): writes (and reads) XML files
to be read by (1) as configurations. It uses REXML and WxRuby.
* I have played about with using Ruby to connect to sockets. I have
also tried to use Ruby/tk but couldn't quite grasp it properly.

Ruby has been really good for what I have used it for so far. But will
it be able to withstand the development I do in it for my
dissertation???

Thanks for all your answers... please continue to discuss, its really
interesting.

 

[Austin Ziegler]

Ruby is good at attracting bores. Notice how many people have replied
to your message with non-answers, perhaps supposed to be amusing, but
really just irritating and unfunny. Or worse, the presumptuous : "go
and do your homework". Makes me feel an unchristian desire to kill.

I actually think that most people have heard this questions -- or at
least variants of it -- for a long time and are, to be honest, tired of
answering it. The RealWorldRuby page is an *excellent* indication of
what Ruby *is* good for.

[... Nonsensical FUD deleted ...]

-austin

 

[Daniel Lewis]

I actually think that most people have heard this questions -- or at

least variants of it -- for a long time and are, to be honest, tired of
answering it. The RealWorldRuby page is an *excellent* indication of
what Ruby *is* good for.

Austin Ziegler * (e-mail address removed)
* Alternate: (e-mail address removed)

I originally asked to find out peoples personal experience... to find
out interactively. Not to do some research on the Internet about what
Ruby is good for. I wanted to know opinions. Yes, you may have heard
similar questions before, but Ruby is continuously being updated and
new types of development/design occur. Its important to keep up to
date.

 

[Rob Rypka]

------=_Part_2963_14883514.1128088712508
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

For example: although some would push Ruby for big projects there are
reasons to be circumspect about such a decision. Not being a Ruby expert = I
cannot elaborate too much, except to say that there are some
industrial-strength-unfriendly-and-too-powerful-perhaps features in the
language, like C++ but much more elegant possibilities for self
destruction.

I definately prefer elegant possibilities for self destruction of Ruby to
the inelegant possibilities for self destruction in other languages.

"The way I see it, if you're gonna build a time machine into a car, why not
do it with some style?"

 

[Austin Ziegler]

I originally asked to find out peoples personal experience... to find
out interactively. Not to do some research on the Internet about what
Ruby is good for. I wanted to know opinions. Yes, you may have heard
similar questions before, but Ruby is continuously being updated and
new types of development/design occur. Its important to keep up to
date.

Two things:

1. My statement was not meant to reflect on you, the OP. It was,
however, intended to suggest that if you sometimes seem to get
flippant responses to such questions, there's good reason

2. To the best of my knowledge, the RealWorldRuby page is updated often.

-austin

 

[Ryan Leavengood]

Coming back to your question : Ruby is nice, but don't get bamboozled by = the
ruby crowd. Someone with a clear head needs to come along and critique th= e
language more objectively than I have seen so far. hOwever I'm not saying
its a bad langauge; far from it,

I really enjoy programming in Ruby, in fact I would say it was my
favorite language. But it is not perfect, and I'll try to describe
some of the flaws I see in it. To give some background I've been
involved with the Ruby community since 2001, so I think I have a good
perspective:

- It is slow. Or to be more exact, compared to some other languages,
Ruby is slow in certain problem domains. Recursion is quite slow for
example. Part of the problem is the fact that the current Ruby
interpreter works by parsing the code into an abstract syntax tree and
then executing that tree directly. The normal standard for
interpreters these days is to compile the code into an intermediate
byte-code and then executing that, which is usually much faster than
the current Ruby method. Fortunately we have a very smart fellow named
SASADA Koichi working on a Ruby byte-code interpreter called YARV (see
http://www.atdot.net/yarv/), so this flaw won't be around for much
longer. Of course the reality is that Ruby, by its very nature, can
never be as fast as a static compiled language like C or C++. Plus as
others have said there are certain problem domains where you would
have to use those kind of languages instead of Ruby (operating system
kernels, device drivers, etc.)

- Ruby is almost too flexible. This is subjective, but the powerful
ability to modify base classes of the system brings a certain
responsibility that some people may not consider. This doesn't apply
too much to little throwaway scripts that we all tend to write, but
there are several examples of Ruby libraries doing stuff here that has
bitten people. These are probably some of the hardest bugs to find,
since few people think that the core classes could have been changed
under their noses. Fortunately most Ruby library developers are aware
of this and they follow certain etiquette rules to ensure these kind
of problems don't come up.

- For large projects the flexibility of Ruby source code organization
could cause problems (in that you aren't forced to put one class per
file for example, like Java), but again this isn't that big of a flaw
because it just requires a small amount of discipline in being
organized with your code.

- The state of Ruby libraries still leaves a bit to be desired. This
has been a persistent problem even since I started with Ruby in 2001,
in fact it inspired me to create the original RubyGems prototype which
has since been supplanted by the RubyGems system we have today. While
this has certainly been a big improvement, not everyone makes use of
the gem system, so there is still some fragmentation. Also RubyGems
still has a bit of a "tacked on" feeling, and this won't go away until
its flaws are fixed and it is fully integrated into a Ruby release. In
addition there are tons of "dead libraries" that haven't been touched
for months or years, yet still provide useful functionality. There are
some efforts to dust off these libraries and bring them up-to-date
though, so hopefully we will see some improvement here.

- Ruby documentation also leaves a bit to be desired. Thanks to the
great Pickaxe book and several others, the Ruby core classes are
pretty well documented, but there are still certainly areas for
improvement there. But I find that way too many libraries (especially
many that actually ship with Ruby) have little or no documentation. I
can't tell you how many times I've just decided to read the source
code of some library to figure out how to use it because no decent
documentation was available. Again there are efforts to solve this
problem as well, but I think the solution needs to be more of a change
in Ruby culture to promote documenting libraries one develops, instead
of leaving that job to someone else. A big part of this could be the
language barrier, since many cool Ruby libraries are developed by
people who may not be confident in their English ability. In that case
some good example code would certainly be better than nothing.

- There is no standard Ruby GUI. Maybe this is a moot point with how
things are going with the Web these days (and Ruby has that realm
covered with Nitro, Rails, Wee, etc), but desktop operating systems
and applications aren't going to disappear overnight, so a good and
somewhat standard Ruby GUI would be nice. Right now there are
certainly many options when one has to create a Ruby GUI (too many in
fact), but each has particular flaws or is lacking maturity in
comparison to the same GUI bindings in Python or another language.
This is a very difficult problem though, and even Java has had a lot
of struggles here (despite tons of money and time from Sun and many
other companies.)

This email is already too long, so I'm not going to answer the
original question of this thread, but hopefully the above will be
enlightening.

Ryan

 

[Karl von Laudermann]

You'll find out Haskell is quite a different beast. It has interesting
features, but it doesn't have much in common with imperative languages
like Ruby. Its IO model is übercool though (completely functional, which
is quite a feat, and basically making IO actions into objects rather
than actions. But if you really want to understand how it works, you
need to understand the monad, which is quite an esoteric mathematical
notion - and I'm someone who used to eat distributions for breakfast, so
abstract mathematical notions normally don't frighten me -).

I certainly don't understand the monad. I read some introductory
material re: Haskell just a couple of weeks ago, out of curiosity about
the language. My understanding of the monad concept and Haskell's use
thereof is basically this:

- Haskell is a purely functional language
- Purely functional languages cannot have side effects
- A language that can't do I/O is useless, so we need a way to put side
effects into a purely functional language
Therefore:
- We'll put I/O subroutines into Haskell, *but* we'll call them
"monads", and that magically fixes the problem somehow

I'm sure that my understanding is wrong, but that's what I came away
with.

 

[Paolo Capriotti]

I certainly don't understand the monad. I read some introductory
material re: Haskell just a couple of weeks ago, out of curiosity about
the language. My understanding of the monad concept and Haskell's use
thereof is basically this:

- Haskell is a purely functional language
- Purely functional languages cannot have side effects
- A language that can't do I/O is useless, so we need a way to put side
effects into a purely functional language
Therefore:
- We'll put I/O subroutines into Haskell, *but* we'll call them
"monads", and that magically fixes the problem somehow

I'm sure that my understanding is wrong, but that's what I came away
with.

That's not quite right, imho. An IO monad encapsulates a sort of "IO
operation", and IO routines are not monads themselves. Instead, they
_return_ IO monads.
In spite of monads, I think that Haskell code can still be considered
without side effects. Something like
main =3D do c <- getChar
putChar c
should be thought as a manipulation of abstract "IO operations". It
produces side effects only because the resulting monad is finally
evaluated (i.e. executed), and that cannot be done inside the Haskell
domain.

Anyway, monads are not just for IO. There are plenty of monadic
classes in the ghc library which have nothing to do with IO. A list is
a monad, for example, as well as a parser.

I'm still considering the monad subject from the point of view of Ruby
programming. It may seem that monads belong to the pure functional
world only, and Ruby does not need them, but...
when we write ary.map{|i| i+1}, aren't we using the fact that Array is
a functor (in the mathematical sense)? To some extent, inject can be
considered as a way to exploit the monadic properties of the Array
functor.

However, can the monad concept be defined in Ruby in some generality?

Paolo Capriotti

 

[Brian Mitchell]

I certainly don't understand the monad. I read some introductory
material re: Haskell just a couple of weeks ago, out of curiosity about
the language. My understanding of the monad concept and Haskell's use
thereof is basically this:

- Haskell is a purely functional language
- Purely functional languages cannot have side effects
- A language that can't do I/O is useless, so we need a way to put side
effects into a purely functional language
Therefore:
- We'll put I/O subroutines into Haskell, *but* we'll call them
"monads", and that magically fixes the problem somehow

I'm sure that my understanding is wrong, but that's what I came away
with.

Monads are something that seem to be made over complicated. This is
usually caused by the fact that monads can be used to do so many
different things. Here [1] is an excellent introduction to monads for
those already familiar with very basic Haskell. Basic Haskell skills,
for those interested, can be learned from a large collection of
material, much of which is listed on the haskell.org learning page
[2].

To try to answer the original question:

I think it is up to the programmer or the team. I've seen amazing
things done in just about every language. What made these particular
things a success? The effort that the project was given. It is key to
remember that you are the one who will be lifting each finger to
compose each symbol used in your program.

Now, that might sound far fetched, but it isn't. I've seen many
projects fail, some of my own in fact, all because the energies to use
a particular tool (that may or may not have suited the problem)
diminished. I think Ruby's high flexibility lends to the ability to
maintain the original mental picture had when starting the project.

What about things that require absolute speed, parallelism, or
unavailable library support? Take what I just said into your focus.
Now ask yourself, would I get burnt out on this project using Ruby?
All of those things ruby can't do _actually_ can be done. It is just
something that might inhibit your enthusiasm as Ruby will slow you
down. It will require extra effort whether it be in binding a library,
speeding up the interpreter, or building a special framework.

In the end a completed but not perfected project is better than
something half done and perfect to that point. Maybe by the time you
complete the project, you will have found that things can be fixed or
that things aren't how you original thought them to be. Someone else
might have even solved your problem for you by then which also happens
in the Ruby community more often than not.

All I said really boils down to: Choose the tools that will keep *you*
going. The project will stay around as long as you do.

Brian.

[1] http://www.nomaware.com/monads/html/
[2] http://www.haskell.org/learning.html

 

[gabriele renzi]

Karl von Laudermann ha scritto:

I certainly don't understand the monad. I read some introductory
material re: Haskell just a couple of weeks ago, out of curiosity about
the language. My understanding of the monad concept and Haskell's use
thereof is basically this:

- Haskell is a purely functional language
- Purely functional languages cannot have side effects
- A language that can't do I/O is useless, so we need a way to put side
effects into a purely functional language
Therefore:
- We'll put I/O subroutines into Haskell, *but* we'll call them
"monads", and that magically fixes the problem somehow

I'm sure that my understanding is wrong, but that's what I came away
with.

# warning: this is just my understanding of monads as an haskell noob
# and it may be completely wrong

First, IIRC Haskell had IO even before the "monadic revolution", it was
just even harder to understand

What I had understand about monads is not that they allow you to express
a single point where side effect will happen, and to order them.
Thus any side effect is not really hidden, it is just structured in a
way that it play nicely with the pure functional part of the code.

Think for example of the IO monad: it allows you to state that you
should, say, print "hello" before "world".
The rest of the program is still happy, functional and lazy, since he
does'nt really care about the console output.

OTOH, when you want to read a string, you can't handle it in the pure
functional side of the code, since it won't be referentially transparent.
Thus you happily write your functional processing stuff, then
incidentally you ask a monad to use that functional stuff on something
that will come from the user.

I think of it as somewhat similar to continuation passing style.
You don't ever "return" from a function in CPS, you just say to the next
continuation "hey, here's my value, do stuff with it".
With monads it is the same, you just say to the monad "hey do this
stuff, and take care of the rest of the program".

At least, I think

 

[Christophe Grandsire]

I certainly don't understand the monad. I read some introductory
material re: Haskell just a couple of weeks ago, out of curiosity about
the language. My understanding of the monad concept and Haskell's use
thereof is basically this:

- Haskell is a purely functional language
- Purely functional languages cannot have side effects
- A language that can't do I/O is useless, so we need a way to put side
effects into a purely functional language
Therefore:
- We'll put I/O subroutines into Haskell, *but* we'll call them
"monads", and that magically fixes the problem somehow

That's not quite correct. Monads are not an ad-hoc concept. They are a
mathematical concept that existed *before* Haskell was even invented.
They have their source in category theory, which is as remote from
programming as any mathematical concept can be .

There have already been good replies, but I thought I might add my two
cents here. Note that it's how I understand monads. It may not be
mathematically correct, but it seems to fit their behaviour.

The thing about monads, and the IO monad in particular, is that they
aren't functions on objects: they are datatypes, or rather parametric
datatypes, i.e. functions that work *on types*. IO, for instance, is a
function that takes a type a, and returns a new type called "IO a". So
you can for instance take a String object, apply an IO operation to it,
and that will return a new object of type "IO String". And note that
this operation doesn't have a side-effect. It's purely functional. It's
rather that when the IO String object will be evaluated, the evaluation
will result in printing the string on the output. That is not a
side-effect, because evaluating a variable isn't an operation, but the
effect of executing a program.

In other words, a variable of type "IO something" encapsulates an IO
action, and the IO subroutines don't have side effects by themselves,
but rather return IO actions as their result. And it's the IO action
itself, when evaluated by the Haskell interpreter/runtime (because it
needs the value of that variable to carry on its computation, like it
could need the value contained in a variable of type Integer) that will
result in some interaction with the outside world. This way, the sides
effects are contained in variables, which can only be of an IO type.

But there's more to it. Being a pure, functional and lazy language,
Haskell doesn't have an order of execution. But IO actions need
sometimes to be ordered. Luckily, by their very mathematical
definitions, monads have to follow some axioms, which define operations
on those monads. One of those operations allows to define a
concatenation operator, which in the case of IO takes two IO actions and
returns a single IO action, which when evaluated will result in the two
IO actions to be evaluated in order. This way, you can ensure that IO
operations happen in the correct order, and to hide the mathematical
aspect of this operator called >> Haskell provides convenient syntactic
sugar (in the form of a do... end block) to write concatenations of IO
actions in a way close to imperative language.

But monads aren't used only with IO. Another monad is the parametric
List, which if I'm not completely mistaken encapsulates linked lists. In
this case, the concatenation operator that was used with IO objects to
evaluate them orderly can be used with Lists to concatenate two Lists
into one.

Monads are quite an esoteric feature, and my explanations probably don't
do them justice. But you can be sure they aren't just an ad-hoc
construction to pretend you don't have side effects in IO. They are a
deep mathematical concept that by chance happened to have the right
operations to be used in Haskell IO.

As for applying something like monads to Ruby... Well, I don't know
whether this would be really necessary. The reasons why monads are
useful in Haskell (encapsulation of side effects, orderly evaluation,
collections, etc...) can be handled pretty well as they are. Moreover,
to implement them in the way Haskell does, the monad would probably have
to be defined as an operation transforming a class into another class
(in the case of IO, a class would be transformed into another class
which would have the peculiarity that when an object of that class is
evaluated by the Ruby interpreter, it results in some input or output
interaction). It would be an interesting exercise (hey, I might look
into it just for fun), but I'm afraid it would be rather academic, but
fun .
--
Christophe Grandsire.

http://rainbow.conlang.free.fr

You need a straight mind to invent a twisted conlang.

 

[Christophe Grandsire]

That's not quite right, imho. An IO monad encapsulates a sort of "IO
operation", and IO routines are not monads themselves. Instead, they
_return_ IO monads.
In spite of monads, I think that Haskell code can still be considered
without side effects. Something like
main = do c <- getChar
putChar c
should be thought as a manipulation of abstract "IO operations". It
produces side effects only because the resulting monad is finally
evaluated (i.e. executed), and that cannot be done inside the Haskell
domain.

Exactly.

Anyway, monads are not just for IO. There are plenty of monadic
classes in the ghc library which have nothing to do with IO. A list is
a monad, for example, as well as a parser.

I'm still considering the monad subject from the point of view of Ruby
programming. It may seem that monads belong to the pure functional
world only, and Ruby does not need them, but...
when we write ary.map{|i| i+1}, aren't we using the fact that Array is
a functor (in the mathematical sense)? To some extent, inject can be
considered as a way to exploit the monadic properties of the Array
functor.

In some sense. However, I think monads can really be implemented in a
language that uses a type system like the one used in Haskell, where one
can have operations *on types* (that's basically what monads, with their
type constructors, are). This can probably be done in Ruby through
operations on classes, but that doesn't really feel like the Ruby Way
(although it may be fun to implement ).

However, can the monad concept be defined in Ruby in some generality?

Thanks to Ruby's dynamicity, it is definitely possible. I'd have a hand
at it if I had some time (which I haven't) and if I felt I had a good
enough understanding of monads (which I don't). And then I'd probably
make a fool of myself anyway .
--
Christophe Grandsire.

http://rainbow.conlang.free.fr

You need a straight mind to invent a twisted conlang.

 

[Christophe Grandsire]

Monads are something that seem to be made over complicated. This is
usually caused by the fact that monads can be used to do so many
different things. Here [1] is an excellent introduction to monads for
those already familiar with very basic Haskell. Basic Haskell skills,
for those interested, can be learned from a large collection of
material, much of which is listed on the haskell.org learning page
[2].

Thanks for link 1. Since I've read about Haskell and monads, I've been
looking for a good tutorial to improve my understanding of them. It
looks like a great one (and it uses Maybe, one of my favourite Haskell
types, simple but great ).

[1] http://www.nomaware.com/monads/html/
[2] http://www.haskell.org/learning.html

--
Christophe Grandsire.

http://rainbow.conlang.free.fr

You need a straight mind to invent a twisted conlang.

 

[Brian Mitchell]

That's not quite correct. Monads are not an ad-hoc concept. They are a
mathematical concept that existed *before* Haskell was even invented.
They have their source in category theory, which is as remote from
programming as any mathematical concept can be .

There have already been good replies, but I thought I might add my two
cents here. Note that it's how I understand monads. It may not be
mathematically correct, but it seems to fit their behaviour.

The thing about monads, and the IO monad in particular, is that they
aren't functions on objects: they are datatypes, or rather parametric
datatypes, i.e. functions that work *on types*. IO, for instance, is a
function that takes a type a, and returns a new type called "IO a". So
you can for instance take a String object, apply an IO operation to it,
and that will return a new object of type "IO String". And note that
this operation doesn't have a side-effect. It's purely functional. It's
rather that when the IO String object will be evaluated, the evaluation
will result in printing the string on the output. That is not a
side-effect, because evaluating a variable isn't an operation, but the
effect of executing a program.

In other words, a variable of type "IO something" encapsulates an IO
action, and the IO subroutines don't have side effects by themselves,
but rather return IO actions as their result. And it's the IO action
itself, when evaluated by the Haskell interpreter/runtime (because it
needs the value of that variable to carry on its computation, like it
could need the value contained in a variable of type Integer) that will
result in some interaction with the outside world. This way, the sides
effects are contained in variables, which can only be of an IO type.

But there's more to it. Being a pure, functional and lazy language,
Haskell doesn't have an order of execution. But IO actions need
sometimes to be ordered. Luckily, by their very mathematical
definitions, monads have to follow some axioms, which define operations
on those monads. One of those operations allows to define a
concatenation operator, which in the case of IO takes two IO actions and
returns a single IO action, which when evaluated will result in the two
IO actions to be evaluated in order. This way, you can ensure that IO
operations happen in the correct order, and to hide the mathematical
aspect of this operator called >> Haskell provides convenient syntactic
sugar (in the form of a do... end block) to write concatenations of IO
actions in a way close to imperative language.

But monads aren't used only with IO. Another monad is the parametric
List, which if I'm not completely mistaken encapsulates linked lists. In
this case, the concatenation operator that was used with IO objects to
evaluate them orderly can be used with Lists to concatenate two Lists
into one.

Monads are quite an esoteric feature, and my explanations probably don't
do them justice. But you can be sure they aren't just an ad-hoc
construction to pretend you don't have side effects in IO. They are a
deep mathematical concept that by chance happened to have the right
operations to be used in Haskell IO.

As for applying something like monads to Ruby... Well, I don't know
whether this would be really necessary. The reasons why monads are
useful in Haskell (encapsulation of side effects, orderly evaluation,
collections, etc...) can be handled pretty well as they are. Moreover,
to implement them in the way Haskell does, the monad would probably have
to be defined as an operation transforming a class into another class
(in the case of IO, a class would be transformed into another class
which would have the peculiarity that when an object of that class is
evaluated by the Ruby interpreter, it results in some input or output
interaction). It would be an interesting exercise (hey, I might look
into it just for fun), but I'm afraid it would be rather academic, but
fun .
--
Christophe Grandsire.

http://rainbow.conlang.free.fr

You need a straight mind to invent a twisted conlang.

I've toyed with the concept myself before. Perhaps a good place to
start would be Maybe...

data Maybe a =3D Just a | Nothing

Simple enough right?

Brian.

 

[Devin Mullins]

Think for example of the IO monad: it allows you to state that you
should, say, print "hello" before "world".
The rest of the program is still happy, functional and lazy, since he
does'nt really care about the console output.

The word "lazy", and the impression I was forming about monads from
reading these posts, inspired this simple doodad. Is this useful? Is it
already implemented in some other Ruby library out there?

class Lazy
(instance_methods - %w{__send__ __id__}).each {|meth| undef_method meth }
def initialize(blk)
@blk = blk
end
def method_missing(*a,&b)
@inst = @blk.call unless defined? @inst
@inst.send(*a,&b)
end
end

def lazy(&blk)
Lazy.new blk
end

a = lazy { puts "evaled!"; $some_expensive_db_operation or 5 }
puts "Hello!"
p a
p a
__END__

Output:
Hello!
evaled!
5
5

Devin

 

[Robert Klemme]

The word "lazy", and the impression I was forming about monads from
reading these posts, inspired this simple doodad. Is this useful? Is
it already implemented in some other Ruby library out there?

class Lazy
(instance_methods - %w{__send__ __id__}).each {|meth| undef_method
meth } def initialize(blk)
@blk = blk
end
def method_missing(*a,&b)
@inst = @blk.call unless defined? @inst
@inst.send(*a,&b)
end
end

def lazy(&blk)
Lazy.new blk
end

Delegate comes to mind. Not really shorter...

require 'delegate'
class Lazy < Delegator
alias :init :initialize

def initialize(&b)
super(nil)
@bl = b
end

def __getobj__
if @bl
@obj = @bl.call()
init(@obj)
@bl = nil
end
@obj
end
end
def lazy(&b)Lazy.new(&b)end

Only advantage seems that one can reuse lib code for delegation and
initialization.

Kind regards

robert

 

[Daniel Lewis]

Delegate comes to mind. Not really shorter...

require 'delegate'
class Lazy < Delegator
alias :init :initialize

def initialize(&b)
super(nil)
@bl =3D b
end

def __getobj__
if @bl
@obj =3D @bl.call()
init(@obj)
@bl =3D nil
end
@obj
end
end
def lazy(&b)Lazy.new(&b)end

Only advantage seems that one can reuse lib code for delegation and
initialization.

Kind regards

robert

oooh my thread has split

I'm going to be noting all this down, Lazy Evaluation is a subject in
Functional Programming and AI.

Thanks,

Daniel.

 

[Lyndon Samson]

------=_Part_5803_18382614.1128172137098
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

 

[Robert Klemme]

oooh my thread has split

Better your thread
than your head.

I'm going to be noting all this down, Lazy Evaluation is a subject in
Functional Programming and AI.

.... although it's by far not restricted to that.

Btw, recently I discovered (better: started using) an interesting idiom that
exploits the fact that both Proc and Hash implement #[].

FUN = config_memoized ?
Hash.new do |h,k|
# complex calculate val
h[k] = val
end :
lambda do |k|
# complex calculate val
end

# later

x = FUN[y]

Nothing really fancy I guess but it's nice how seemingly these integrate.
(Now, is this another thread split?)

Kind regards

robert

 

[gabriele renzi]

Robert Klemme ha scritto:

oooh my thread has split

Better your thread
than your head.

I'm going to be noting all this down, Lazy Evaluation is a subject in
Functional Programming and AI.

... although it's by far not restricted to that.

Btw, recently I discovered (better: started using) an interesting idiom
that exploits the fact that both Proc and Hash implement #[].

FUN = config_memoized ?
Hash.new do |h,k|
# complex calculate val
h[k] = val
end :
lambda do |k|
# complex calculate val
end

# later

x = FUN[y]

Nothing really fancy I guess but it's nice how seemingly these
integrate. (Now, is this another thread split?)

could'nt you just use the default_proc in a Hash?
irb(main):001:0> fun= Hash.new do |h,k|
irb(main):002:1* p 'calculations'
irb(main):003:1> h[k]= rand
irb(main):004:1> end
=> {}
irb(main):005:0> fun[10]
"calculations"
=> 0.364681017817929
irb(main):006:0> fun[10]
=> 0.364681017817929

ok it is inverting the concept, I know but it seem to get the same
result