In your opinion....

K

Kirk Haines

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

That is what is in the example above. However, he has the trinary operator in
his example. Depending on the value of config_memoized, one either gets a
hash with a default block, or a lambda, but in use both of them may appear to
be the same.

a = Hash.new {|h,k| h[k] = (k * 10000007) % 20}
b = lambda {|k| (k * 10000007) % 20}

a[5]
=> 15
b[5]
=> 15


In the original example, it illustrated how, because lambdas implement #[],
one could have either a memoizing or a nonmeoizing FUN[] depending on a
configuration value.

Kind of neat,


Kirk Haines
 
K

Kirk Haines

In the original example, it illustrated how, because lambdas implement #[],
one could have either a memoizing or a nonmeoizing FUN[] depending on a
configuration value.

To followup:

def create_calculator_object(memoize, &b)
memoize ? Hash.new {|h,k| puts "memoizing #{k}"; h[k] = b.call(k)} : b
end

a = create_calculator_object(true) {|k| (k * 10000007) % 20}
b = create_calculator_object(false) {|k| (k * 10000007) % 20}

irb(main):007:0> a[5]
memoizing 5
=> 15
irb(main):008:0> a[5]
=> 15
irb(main):009:0> b[5]
=> 15


Kirk Haines
 
J

Jay Levitt

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 #[].

Could you recommend a good book for us old-timers - who grew up in
procedural languages, never learned more Lisp than we needed to
customize Emacs, and are still getting our heads around the now-half-
obsolete OO GoF patterns - to learn about functional programming and its
idioms? From reading this thread, I would have assumed that FP is
another word for "procedural" but clearly it's much, much more.
 
J

James Britt

Jay said:
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 #[].


Could you recommend a good book for us old-timers - who grew up in
procedural languages, never learned more Lisp than we needed to
customize Emacs, and are still getting our heads around the now-half-
obsolete OO GoF patterns - to learn about functional programming and its
idioms? From reading this thread, I would have assumed that FP is
another word for "procedural" but clearly it's much, much more.


Book:
* http://mitpress.mit.edu/sicp/

Not a book:
http://lambda-the-ultimate.org/node/view/4


James

--

http://www.ruby-doc.org - The Ruby Documentation Site
http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
 
A

Alan Gutierrez

* Jay Levitt said:
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 #[].

Could you recommend a good book for us old-timers - who grew up in
procedural languages, never learned more Lisp than we needed to
customize Emacs, and are still getting our heads around the now-half-
obsolete OO GoF patterns - to learn about functional programming and its
idioms? From reading this thread, I would have assumed that FP is
another word for "procedural" but clearly it's much, much more.

I can't recommend anything really, since I don't FP.

But, I've bookmarked...

http://www.drscheme.org/

For it's tutorials.

http://www.plt-scheme.org/software/drscheme/tour/tour-Z-H-4.html

And there's a classic text called the "The Little Lisper" that
has been revised as the "The Little Schemer", which is less than
100 pages, and purports to get you thinking recursively.
 
J

Jeff Wood

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

Actually, the tour is mostly useless... but, they also have ( all by the PL=
T
folks )
How to Design Programs
http://www.htdp.org/
and
Learn Scheme in FIXNUM days
http://download.plt-scheme.org/doc/299.400/html/t-y-scheme/

* Jay Levitt said:
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 #[].

Could you recommend a good book for us old-timers - who grew up in
procedural languages, never learned more Lisp than we needed to
customize Emacs, and are still getting our heads around the now-half-
obsolete OO GoF patterns - to learn about functional programming and it= s
idioms? From reading this thread, I would have assumed that FP is
another word for "procedural" but clearly it's much, much more.

I can't recommend anything really, since I don't FP.

But, I've bookmarked...

http://www.drscheme.org/

For it's tutorials.

http://www.plt-scheme.org/software/drscheme/tour/tour-Z-H-4.html

And there's a classic text called the "The Little Lisper" that
has been revised as the "The Little Schemer", which is less than
100 pages, and purports to get you thinking recursively.


--
"http://ruby-lang.org -- do you ruby?"

Jeff Wood

------=_Part_117_16363347.1128236244720--
 
E

Edward Faulkner

--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

From reading this thread, I would have assumed that FP is another
word for "procedural" but clearly it's much, much more.

Indeed, functional programming is almost the *opposite* of procedural.
In a procedural program, most lines are executed for their side
effects. In a functional program, most lines are executed for their
value.

The key idea in functional programming is that the functions you
define are functions in the mathematical sense. If you call one twice
with the same arguments, you'll always get the same answer each time.
They have no internal state and no side effects.

In practice most programs need non-functional parts too, but you can
keep those isolated.

By keeping your code functional, you make it easier to test and debug.
It's inherently thread safe, and optimizations like lazy evaluation
and memoization can be introduced transparently by the
compiler/interpreter.

regards,
Ed

--MGYHOYXEY6WxJCY8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDQLQSnhUz11p9MSARAkZTAJ9W/GNqpDS1H8NnqpcfO1I0NxNsjACgqHXi
pggv2uv0omaYY5or+/O/Awk=
=IUwW
-----END PGP SIGNATURE-----

--MGYHOYXEY6WxJCY8--
 
J

Jay Levitt

Indeed, functional programming is almost the *opposite* of procedural.
In a procedural program, most lines are executed for their side
effects. In a functional program, most lines are executed for their
value.

Thanks for summing this up so wonderfully.
 
R

Robert Klemme

Edward Faulkner said:
Indeed, functional programming is almost the *opposite* of procedural.
In a procedural program, most lines are executed for their side
effects. In a functional program, most lines are executed for their
value.

The key idea in functional programming is that the functions you
define are functions in the mathematical sense. If you call one twice
with the same arguments, you'll always get the same answer each time.
They have no internal state and no side effects.

I was going to write something similar. Thanks for confirming that my rusty
CS knowledge on functional programming was not completely outdated!
In practice most programs need non-functional parts too, but you can
keep those isolated.

.... and all functional languages with some significance have non functional
extensions (like side effects, variables etc.).
By keeping your code functional, you make it easier to test and debug.
It's inherently thread safe, and optimizations like lazy evaluation
and memoization can be introduced transparently by the
compiler/interpreter.

IIRC another property of (pure) functional programs is that they are easier
to reason about mathematically and thus to verify (probably because
functions resemble very much mathematical functions).

Kind regards

robert
 
C

Christophe Grandsire

Selon Edward Faulkner said:
Indeed, functional programming is almost the *opposite* of procedural.
In a procedural program, most lines are executed for their side
effects. In a functional program, most lines are executed for their
value.

Incidently, since functions in functional languages (pure ones at least) =
have no
side-effects, order of execution doesn't matter anymore. This also means =
that
there is no such thing as looping anymore. Instead, for looping purposes
functional languages use recursion exclusively. It isn't a problem as rec=
ursion
is more powerful than looping (it is actually mathematically proven that =
loops
are equivalent to a specific kind of recursion called tail recursion).
The key idea in functional programming is that the functions you
define are functions in the mathematical sense. If you call one twice
with the same arguments, you'll always get the same answer each time.
They have no internal state and no side effects.

Indeed, if you look at a program written in Haskell for instance, it real=
ly
looks like a sort of mathematical notation reduced to fit ASCII :) .
In practice most programs need non-functional parts too, but you can
keep those isolated.

The most important case is IO. I personally like the Haskell solution ver=
y much
(although it is theoretically complicated), because it is still provably =
purely
functional, isolating IO side-effects in objects rather than functions.
By keeping your code functional, you make it easier to test and debug.
It's inherently thread safe, and optimizations like lazy evaluation
and memoization can be introduced transparently by the
compiler/interpreter.

The only problem is that functional programming is so far removed from th=
e usual
idea of "giving instructions for the computer to execute" that most peopl=
e can't
seem to grok it. The functional programming metaphor looks to me more lik=
e
"giving rules to the computer and problems to be solved with them".

Some people may be interested in this: http://raa.ruby-lang.org/project/r=
type/ .
This is a Ruby interpreter written in Haskell.
--
Christophe.

http://rainbow.conlang.free.fr

It takes a straight mind to create a twisted conlang.
 
M

Matthias Luedtke

Robert said:
IIRC another property of (pure) functional programs is that they are
easier to reason about mathematically and thus to verify (probably
because functions resemble very much mathematical functions).

That is certainly true! Just think of the functions recursive nature and
how structural induction comes in handy here. Imperative programs often
require harder tools such as e.g. Hoare logic. In theory, at least... ;)

Regards,
Matthias
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top