Curious about functional programming
The Glauber
found much material on it on the Web (which means i'm probably looking
in the wrong place). There are a number of purely functional
programming languages, then there's Lisp-ish languages and everything
else.
My superficial observation is that Lisp users seem to be more tolerant
of side-effects in their programs than Scheme users.
I think you can do functional programming in imperative languages too,
and some of the things that are considered good coding in object-
oriented programming (short methods, "getter" and "setter" methods to
access members, etc) are a step towards functional programming.
Is F.P. an idea that's still considered important? Is it important for
Lisp programmers in "the real world"?
Curious...
glauber
--
Glauber Ribeiro
thegl...@my-deja.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com http://www.deja.com/
Before you buy.
Johan Kullstam
> I'm intrigued by the idea of functional programming, but i haven't
> found much material on it on the Web (which means i'm probably looking
> in the wrong place). There are a number of purely functional
> programming languages, then there's Lisp-ish languages and everything
> else.
>
> My superficial observation is that Lisp users seem to be more tolerant
> of side-effects in their programs than Scheme users.
yes. common-lisp emphasizes getting things done as opposed to
strictly maintaining language purity. personally, i think common-lisp
does a pretty good job on both counts.
> I think you can do functional programming in imperative languages too,
> and some of the things that are considered good coding in object-
> oriented programming (short methods, "getter" and "setter" methods to
> access members, etc) are a step towards functional programming.
yes, but the popular imperative languages tend not to have functions
as first class objects, nor do they make passing functions easy. the
lack of one-shot function "constants"^1 (lambda) make it difficult.
i remember particularly painful C++ episode in which i tried to take
member function of two variables, fill in a constant for one of the
arguments and pass it to a function expecting to recieve a function of
one argument. it's trivial in lisp; it's a pain in the ass kludge in
C++. the C++ guys i went to for advice looked at me as if i had two
heads for even wanting such a thing. when i told them lisp can do it,
i suddenly felt i had sprouted a third head.
setter functions have side effects and not pure functions. that
doesn't mean they aren't useful. i find lisp's setf to be
particularly elegant as it frames setting under the notation of
getting. that's good for humans and wonderful for macros. i don't
know if it's "functional" though.
> Is F.P. an idea that's still considered important? Is it important for
> Lisp programmers in "the real world"?
a pure function is easier to deal with since it won't spew side
effects all over creation. it's all about not surprising the
programmer with unintended and complex consequences. obvious side
effects with limited scope are perfectly OK imho.^2
> Curious...
>
> glauber
> --
> Glauber Ribeiro
> thegl...@my-deja.com
> "Opinions stated are my own and not representative of Experian"
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
[1] #'(lambda (x) (* x x)) is a function just like 1.0 is a floating
point number.
[2] things like setq on a local variable or printing to a file have
obvious side effects (changing a variable, lengthening a file, resp.).
--
J o h a n K u l l s t a m
[kull...@ne.mediaone.net]
Don't Fear the Penguin!
Barry Margolin
Johan Kullstam <kull...@ne.mediaone.net> wrote:
>The Glauber <thegl...@my-deja.com> writes:
>> Is F.P. an idea that's still considered important? Is it important for
>> Lisp programmers in "the real world"?
>
>a pure function is easier to deal with since it won't spew side
>effects all over creation. it's all about not surprising the
>programmer with unintended and complex consequences. obvious side
>effects with limited scope are perfectly OK imho.^2
One of the main benefits of "pure FP" is in program optimization,
particularly in parallel processing architectures. Programs without side
effects are easy for other programs to reason about and transform. Lazy
evaluation can be done, and computations can be done in parallel, all
without changing the results of the program. So people doing research on
programming language implementation like FP because it avoids the hard
problems.
However, IMHO, most real world programmers have a harder time designing
pure functional programs. I believe our minds tend to think about
step-by-step plans more easily than functional decomposition (our
hunter/gatherer forebears didn't think "Eat the animal that I cooked that I
killed", they thought "kill the animal, then cook it, then eat it", and we
inherited their planning thought processes). So programming practicioners,
as opposed to academics, tend to prefer imperative programming styles.
As Johan pointed out, Common Lisp provides many functional features, so you
can use that style when it fits your needs, but overall program design
tends to be mostly imperative.
--
Barry Margolin, bar...@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Kent M Pitman
No conflict with anything Barry said here--jsut wanted to add some thoughts
to underscore some of his remarks for those few who remain both unconvinced
but still open to argument on the matter...
> In article <m2g0p3f...@euler.axel.nom>,
> Johan Kullstam <kull...@ne.mediaone.net> wrote:
> >The Glauber <thegl...@my-deja.com> writes:
> >> Is F.P. an idea that's still considered important? Is it important for
> >> Lisp programmers in "the real world"?
>
> One of the main benefits of "pure FP" is in program optimization, [...]
>
> However, IMHO, most real world programmers have a harder time designing
> pure functional programs. I believe our minds tend to think about
> step-by-step plans more easily than functional decomposition
Personally, I would say it's because things in the world DO have state and
because people develop brain hardware that directly mirrors those things
about which they reason most often. If most things in the world were
state-free, I think people would reason well about state-free things.
Certainly when discussing optimization, as you suggest, which is really about
the abstract meta-process of reasoning about a process WITHOUT reasoning
about its domain data and reasoning only about abstract identities and
transformations of known characteristic (since it's conventionally done by
programs that don't understand the domain task), there are properties of
state-free things that makes "mindless" (I'll call it) reasoning easier.
But "mindful" things--that is, things that are really about a domain and how
it works as reasoned by a trained expert--are often about systems with state
and trying to "model" them without isomorphism but instead by making a
trustable proof that transforming it to a state-free decomposition is hard
because you ahve to do not only the state-free result but also the
transformation. It's easier just to use the brain's natural hardware for
doing statistical prediction, structural modeling, simulation, and other
techniques that are directly available in wetware.
> (our
> hunter/gatherer forebears didn't think "Eat the animal that I cooked that I
> killed", they thought "kill the animal, then cook it, then eat it", and we
> inherited their planning thought processes). So programming practicioners,
> as opposed to academics, tend to prefer imperative programming styles.
Yes, I agree with this analysis completely. I've made similar comments about
the value of recursion in teaching children. Does anyone know someone who has
taught a kid to climb stairs by saying "climb the first stair, then climb
the stairs"? I think we all say "here are a bunch of stairs. learn how to
climb one. now do it to all of them."
> As Johan pointed out, Common Lisp provides many functional features, so you
> can use that style when it fits your needs, but overall program design
> tends to be mostly imperative.
Precisely. Some of the world is functional, and CL models that with proper
isomorphism to functions. I hate working in languages where first class
functions are not available for this. However, most of the world has state
and CL models that as well. It's exactly the ability to integrate
these stylistically clashing abstractions which makes CL so able to model
a world which is likewise full full of uncoordinated abstractions, artifacts,
etc. It's hardly surprising either, since CL's roots are in early AI work
trying to mirror thought on the very hardest of representational problems.
CL has spent less time worrying about the elegance of a "hello world" program
and more on worrying about the "how world" or "why world"...
Joe Marshall
> I believe our minds tend to think about step-by-step plans more
> easily than functional decomposition (our hunter/gatherer forebears
> didn't think "Eat the animal that I cooked that I killed", they
> thought "kill the animal, then cook it, then eat it", and we
> inherited their planning thought processes).
I disagree. I think that functional decomposition is both quite easy
to grasp and that people use it more than they are aware. We think
`that wall that is made of bricks and mortar' rather than `that wall
that is
1. Place brick on ground.
2. put mortar on it
3. Place brick next to it.
4. etc....'
I think that the `step-by-step' approach to programming may have as
much to do with the way we are taught about programming (and following
directions) as with inhereted thought processes.
Fernando D. Mato Mira
> My superficial observation is that Lisp users seem to be more tolerant
> of side-effects in their programs than Scheme users.
But Common Lisp is more functional:
http://series.sourceforge.net/
--
Fernando D. Mato Mira Phone : +41 (78) 778 FDMM
E-mail : matomira AT acm DOT org
David Hanley
As a short answer, i often use functional ideas without doing
pure functional programming--even in languages such
as java. This often helps me reason about complex code, as
I don't have to worry about shared objects getting mutated
by some way. Yes, this will run slower for some applications,
but that's where judicious mutation and extra care on
a specific path gets you 90% of the performance you could
achieve with a hairy version of the code which makes no
copies, but is much harder to understand.
dave
Duane Rettig
> On 21 Jul 2000 14:45:12 -0400, Joe Marshall <jmar...@alum.mit.edu> wrote:
>
> >I disagree. I think that functional decomposition is both quite easy
> >to grasp and that people use it more than they are aware. We think
> >`that wall that is made of bricks and mortar' rather than `that wall
> >that is
> > 1. Place brick on ground.
> > 2. put mortar on it
> > 3. Place brick next to it.
> > 4. etc....'
>
> Seems more like object-oriented. A brick is an abstract object which seems
> almost concrete. A concrete block is equally abstract but really concrete.
> Both are quite hard, but a brick is actually easy to grasp, and can even be
> thrown as an exception, but not safely. How easy is it to grasp functional
> decomposition?
I always grasp bricks easily and safely, but only when using gloves.
But some bricks are made out of clay.
Why are we talking about bricks and concrete in a lisp newsgroup?
:-) :-)
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
e 4 5 5 @ y a h o o . c o m
Xah
> One of the main benefits of "pure FP" is in program optimization,
> effects are easy for other programs to reason about and transform. Lazy
> evaluation can be done, and computations can be done in parallel, all
> without changing the results of the program. So people doing research on
> programming language implementation like FP because it avoids the hard
> problems.
Likewise: one of the main benefits of "imperative programing" is in easy
compiler implementation. And blab blab blab. So people who do real world
programing prefer the imperatives of begging style because it avoids the
labor of thinking clearly.
> However, IMHO, most real world programmers have a harder time designing
> pure functional programs.
However, IMHO, real world Luddites have a hard time understanding automation
& progress also.
> I believe our minds tend to think about
> step-by-step plans more easily than functional decomposition (our
> hunter/gatherer forebears didn't think "Eat the animal that I cooked that I
> killed", they thought "kill the animal, then cook it, then eat it", and we
> inherited their planning thought processes).
Vacuous opinion touched up with dumb presentation jacked up with a pent-up
wrangled anal-ogy in the fashion of wishful thinkers.
> So programming practicioners,
> as opposed to academics, tend to prefer imperative programming styles.
Therefore Luddites & rubes, as opposed to the educated, tend to prefer
staying put.
> As Johan pointed out, Common Lisp provides many functional features, so you
> can use that style when it fits your needs, but overall program design
> tends to be mostly imperative.
in the same vein: as i pointed out, Common Lisp provide some functional
features, so you can use that style when you are capable of clear thinking,
but overall program design tends to be mostly dysfunctional.
--
At the end era of any revolution, there's a bag of effete conservatives who
drag the society. Lisp was a revolution precisely because it's functional.
Now we have the likes of Barry Margolin singing the songs of the
imperatives.
Pure and non-strict (tech term) functional languages will be THE languages
of the future, as a matter of time. How soon it will happen depends on the
brightness of our information age. Obviously, the likes of Margolin is not
helping.
Xah
x...@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
Erik Naggum
| My superficial observation is that Lisp users seem to be more
| tolerant of side-effects in their programs than Scheme users.
Side-effects in programming is a side-effect of programming with
stateful objects. In its purest form, and certain Schemers want
nothing less, Scheme eschewes statefulness and hence objects that
have state information. This is one of the reasons it is often
impossible to talk to Schemers and Scheme is useless for more than
embedded languages that do all the side-effects behind the scenes.
| I think you can do functional programming in imperative languages too,
| and some of the things that are considered good coding in object-
| oriented programming (short methods, "getter" and "setter" methods to
| access members, etc) are a step towards functional programming.
I consider object-oriented programming antithetical to functional
programming. What do you do with an object that changes state or,
more broadly, maintains some information about itself that may be
modified by "methods" on it? In functional programming, you would
return a new object. In object-oriented programming, other users of
the same object would see the change. Object-oriented programming
relies on object identity. Functional programming relies on objects
not being referenced by anyone else.
| Is F.P. an idea that's still considered important? Is it important
| for Lisp programmers in "the real world"?
As with all theoretical approaches to the real world, you always get
something really important out of every theory that has been built
from observations of the real world, but when the theory starts to
depend more on the egos of the creators than on reality, however one
defines and relates to it, it quickly loses its appeal to any others
than its believers/investors. I view functional programming as an
attempt to solve certain hard problems -- not those of application,
infrastructure, modeling, human requirements, etc, but in the design
of languages -- a consequence of which is that certain programming
paradigms emerge and prove themselves worthy of examination and the
occasional use, but 100% pure functional style is simply useless: If
you have no side-effects, you have no effects on the real world,
which has the same identity before and after your side-effect-free
program. Taken to its extreme, side-effect-free programming would
mean you had to create a new universe with every computation.
Now that we've established that there has to be _some_ side-effects,
the question is no longer whether they are good or bad, but _which_
are good or bad. The functional programming languages I have used
and studied have not let me make that decision myself, but rather
have tried to force me into accepting somebody else's choices. I
don't think this is a particularly useful approach to programming
paradigms, and I don't want to work against the languages I use.
#:Erik
--
If this is not what you expected, please alter your expectations.
Xah
> No conflict with anything Barry said here--jsut wanted to add some thoughts
> to underscore some of his remarks for those few who remain both unconvinced
> but still open to argument on the matter...
No conflict with anything Kent said here -- i just wanted to add some
thoughts to underscore some of his remarks for those few who are clouded by
the lure of the imperatives but are still capable of critical thinking.
Kent begs:
> Personally, I would say it's because things in the world DO have state and
> because people develop brain hardware that directly mirrors those things
> about which they reason most often.
Impersonally, i would say Kent have no idea what he is talking about.
First off, it's meaningless mumble jumble. On a meta or intuitive level,
it's also plagued by non sequiturs.
>If most things in the world were state-free
what the fuck does this really mean?
> I think people would reason well about state-free things.
how this follows? and what the fuck is "_reason well_ about state-free
things"?
When not being technical, mumble jumble appears to be Kent's forte.
> Certainly when discussing optimization, as you suggest, which is really about
> the abstract meta-process of reasoning about a process WITHOUT reasoning
> about its domain data and reasoning only about abstract identities and
> transformations of known characteristic (since it's conventionally done by
> programs that don't understand the domain task), there are properties of
> state-free things that makes "mindless" (I'll call it) reasoning easier.
> But "mindful" things--that is, things that are really about a domain and how
> it works as reasoned by a trained expert--are often about systems with state
> and trying to "model" them without isomorphism but instead by making a
> trustable proof that transforming it to a state-free decomposition is hard
> because you ahve to do not only the state-free result but also the
> transformation. It's easier just to use the brain's natural hardware for
> doing statistical prediction, structural modeling, simulation, and other
> techniques that are directly available in wetware.
Wetware my ass.
For those "stateful" things as you say, then it should be modeled by
automata, monads (excuse me for my ignorance for this one), neuro-networks,
genetic programing, fuzzy-logic, pure objects and so on that has a rigid
mathematical foundation. Most of which can be embodied in functional
programing.
That's the best reply i can gather for Kent's vague verbalization.
Barry Margolin <bar...@genuity.net> writes:
>> (our
>> hunter/gatherer forebears didn't think "Eat the animal that I cooked that I
>> killed", they thought "kill the animal, then cook it, then eat it", and we
>> inherited their planning thought processes). So programming practicioners,
>> as opposed to academics, tend to prefer imperative programming styles.
Kent Pitman apologizes:
> Yes, I agree with this analysis completely. I've made similar comments about
> the value of recursion in teaching children. Does anyone know someone who has
> taught a kid to climb stairs by saying "climb the first stair, then climb
> the stairs"? I think we all say "here are a bunch of stairs. learn how to
> climb one. now do it to all of them."
Huh? Excuse me for my lack of imagination, but could you be a bit precise?
Are you now, paralleling analogies with mappings from the functional
paradigm to the methodology domain for the injection of your opinion??? By
ways of empathy, i think you know what i mean too.
Barry Margolin <bar...@genuity.net> sings:
>> As Johan pointed out, Common Lisp provides many functional features, so you
>> can use that style when it fits your needs, but overall program design
>> tends to be mostly imperative.
Kent Pitman echoes:
> Precisely. Some of the world is functional, and CL models that with proper
> isomorphism to functions.
What the FUCK does
"CL models that with proper isomorphism to functions"
^^^^^^ ^^^^^^^^^^^
mean? Here Kent Pitman is fucking fuck all fucked up about using jargons to
impinge those lesser educated.
> I hate working in languages where first class
> functions are not available for this. However, most of the world has state
> and CL models that as well. It's exactly the ability to integrate
> these stylistically clashing abstractions which makes CL so able to model
> a world which is likewise full full of uncoordinated abstractions, artifacts,
> etc. It's hardly surprising either, since CL's roots are in early AI work
> trying to mirror thought on the very hardest of representational problems.
> CL has spent less time worrying about the elegance of a "hello world" program
> and more on worrying about the "how world" or "why world"...
I get tired of correcting sloppy iffy writings like these that's not even
belles-lettres nor sophistry. Kent, maybe your technical career wrapped up,
maybe you should focus on fiction writing full time.
Xah
x...@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
Christopher Browne
>* The Glauber <thegl...@my-deja.com>
>| My superficial observation is that Lisp users seem to be more
>| tolerant of side-effects in their programs than Scheme users.
>
> Side-effects in programming is a side-effect of programming with
> stateful objects. In its purest form, and certain Schemers want
> nothing less, Scheme eschewes statefulness and hence objects that
> have state information. This is one of the reasons it is often
> impossible to talk to Schemers and Scheme is useless for more than
> embedded languages that do all the side-effects behind the scenes.
I thought that most of the "purist" functional programming people had
headed off to work with Haskell and ML. After all, making Scheme truely
"stateless" would mandate removing set! from the language. But I suppose
you keep up with those "certain Schemers" more than I do.
>| I think you can do functional programming in imperative languages too,
>| and some of the things that are considered good coding in object-
>| oriented programming (short methods, "getter" and "setter" methods to
>| access members, etc) are a step towards functional programming.
>
> I consider object-oriented programming antithetical to functional
> programming. What do you do with an object that changes state or,
> more broadly, maintains some information about itself that may be
> modified by "methods" on it? In functional programming, you would
> return a new object. In object-oriented programming, other users of
> the same object would see the change. Object-oriented programming
> relies on object identity. Functional programming relies on objects
> not being referenced by anyone else.
Agreed; I suspect that most of those that suggest that OO is in any way
related to FP Just Didn't Get It when they did their two week module on
functional programming.
That being said, the world isn't all about having Just One Programming
Paradigm.
- Perl represents the "scripting languages with all the paradigms
thrown in."
- C++ is _NOT_ an "object oriented language," but rather a "language that
supports objected oriented and other useful programming paradigms."
(Which is approximately the way Stroustrup describes C++.)
- Common Lisp supports quite the bunch of paradigms.
- The FP language that seems to have gotten the most widely deployed for
"useful stuff" is OCAML, a version of ML augmented with object oriented
capabilities. They've actually created an Emacs clone in OCAML.
>| Is F.P. an idea that's still considered important? Is it important
>| for Lisp programmers in "the real world"?
>
> As with all theoretical approaches to the real world, you always get
> something really important out of every theory that has been built
> from observations of the real world, but when the theory starts to
> depend more on the egos of the creators than on reality, however one
> defines and relates to it, it quickly loses its appeal to any others
> than its believers/investors. I view functional programming as an
> attempt to solve certain hard problems -- not those of application,
> infrastructure, modeling, human requirements, etc, but in the design
> of languages -- a consequence of which is that certain programming
> paradigms emerge and prove themselves worthy of examination and the
> occasional use, but 100% pure functional style is simply useless: If
> you have no side-effects, you have no effects on the real world,
> which has the same identity before and after your side-effect-free
> program. Taken to its extreme, side-effect-free programming would
> mean you had to create a new universe with every computation.
You have 30 seconds: Define the universe. Give at least 3 examples...
:-)
--
cbbr...@ntlug.org - <http://www.ntlug.org/~cbbrowne/>
"The day Microsoft makes something that doesn't suck is probably the
day they start making vacuum cleaners" - Ernst Jan Plugge
Joe Marshall
The rate at which bricks or concrete decompose is a function of their
environment. Brick which are statically bound in mortar tend to have
longer lifetimes than those which are dynamically bound (with
strapping? Don't forget to unwind it!). Certainly the garbage
collectors have an easier time transporting individual bricks. But a
wall tends to be a barrier for garbage collectors, so they usually
just sweep up around it.
Both bricks and concrete blocks provide a uniform interface and hide
the details of their implementation. With the appropriate use of
protection forms, they can be safely thrown or caught, and even a
non-exceptional person can handle either.
This leads us to a possible link between the lambda calculus (note the
etymology of calculus! More than co-incidence?) and freemasonry...
Pierre R. Mai
> For those "stateful" things as you say, then it should be modeled by
> automata, monads (excuse me for my ignorance for this one), neuro-networks,
> genetic programing, fuzzy-logic, pure objects and so on that has a rigid
> mathematical foundation. Most of which can be embodied in functional
> programing.
Imperative programming languages have just as rigid a mathematical
_foundation_. It just happens that reasoning about imperative programs
is harder.
Other than that I can only wonder why you post in c.l.l, if you
consider pure lazy functional languages to be the programming
languages of the future, then surely all Lisps and those abominable
retards that continue to use them will be neither entertaining nor
interesting... But why stop when it's so much fun...
Regs, Pierre.
--
Pierre Mai <pm...@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Rob Warnock
+---------------
| This leads us to a possible link between the lambda calculus (note the
| etymology of calculus! More than co-incidence?) and freemasonry...
**ROTFLMAO!!**
-Rob
-----
Rob Warnock, 41L-955 rp...@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
Xah
>> For those "stateful" things as you say, then it should be modeled by
>> automata, monads (excuse me for my ignorance for this one), neuro-networks,
>> genetic programing, fuzzy-logic, pure objects and so on that has a rigid
>> mathematical foundation. Most of which can be embodied in functional
>> programing.
pm...@acm.org (Pierre R. Mai) Jul 2000 01:19:58 +0200 wrote:
> Imperative programming languages have just as rigid a mathematical
> _foundation_. It just happens that reasoning about imperative programs
> is harder.
Yeah? and? is this a background info or was it a refutation? If latter, how
does it work?
was our snazzy & comfy context about functional vs imperative programing?
I wrote my paragraphS in check of Kent's poetic syllogization. What is your
point?
> Other than that I can only wonder why you post in c.l.l, if you
> consider pure lazy functional languages to be the programming
> languages of the future,
> then surely all Lisps and those abominable
> retards that continue to use them will be neither entertaining nor
> interesting...
please guys. For serious arguments or opinion giving: one at a time, and
connect the logic. Make your "if then" work. ... (... define your
disagreement, give support, think clearly and distinctly, and don't muddy it
with _ infused_ and _meaningless_ taunts (it'll muddy both cogency of main
dish AND sourness of the desert) )
I post on c.l.l. for mostly the same reason people posts in newsgroups,
except that i'm not here to pickup Common Lisp technicalities. But to the
point: i cannot tolerate charismatic untruths, especially glaringly dropped
by dignitaries. Such untruths beg me for a trashing.
The previous two posts by Barry Margolin & Kent M. Pitman are really good
paradigm. Good as paragon of stupid writings. Full fledged in all aspects.
Are you about to contribute to this genre?
>... But why stop when it's so much fun...
indeed my buddy,
in good deed,
Lieven Marchand
> - The FP language that seems to have gotten the most widely deployed for
> "useful stuff" is OCAML, a version of ML augmented with object oriented
> capabilities. They've actually created an Emacs clone in OCAML.
OCaml also added real variables ("references") and gave up referential
transparency to do it and guarantees order of execution without stuff
like monads. I think the most reasonable way to look at OCaml is just
like CL as a language with a functional subset, but not as a
functional language.
--
Lieven Marchand <m...@bewoner.dma.be>
Lambda calculus - Call us a mad club
Kent M Pitman
I'm not here trying to convince you of something; I'm curious how you model
the world, computation, and the relationship between them:
- What do you think is going on in someone's head when they
"think about" something? That is, do you think it's an excerise
in "functional process" (e.g., side-effect-free decomposition or
some such) or "imperative process" (manipulation of the stateful
stuff you seem to abhor so) or how would you characterize it?
- Notwithstanding your answer, do you give any credence to the notion of
mental isomorphism? That is, do you suppose there is value in having
the "shape" of mental conceptions match the "shape" of reality (e.g.,
to minimize the computational cost of marshalling and unmarshalling
brain data and/or reality data, depending on which way you're going)
or is that simply an irrelevancy? Likewise, do you see any value in
reasoning in a way that is consistent with the mechanism? For example,
you could model a coke machine using "statistics" or "functional
expressions", but it seems to me there is more value to modeling it as
a state machine since it is, in fact, such a thing. If you choose to
model something in a way that it in fact doesn't work (as pre-Kepler
folk used to model the rotation of the planets in their spirograph-like
curly-orbit way), don't you risk overcomplicate the simple? And so
doesn't it come down to how people think? Not how you wish them to think
but how they in fact think? (Can you cite experiments to show that you
have a clear and uncontroverted theory of how they think such that you
are sure you are not advocating dissonance between our mental models
and our devices for aiding in computation?) Sometimes, obviously, the
technique for the computation may be well-understood and accepted; but
where it is not, debuggability comes (it seems to me) best when people
have some way of destructuring the problem into intelligible components;
isomorphism between the real world and the computation isn't the only
way to do it, but it doesn't seem to me that one should discount it as
a ridiculous way, either, in the case where programmers want to do it.
Martin Cracauer
>Is F.P. an idea that's still considered important? Is it important for
>Lisp programmers in "the real world"?
Adding to what other said, a large part of the F.P. community uses
their language research to make use of strong type systems, targetting
compile-time saveness without the work depression that comes with them
in most traditional OO languages. Obviously, that is even more remote
from what the usual Lisp programmer does than the aspect of being
side-effect free.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
Frode Vatvedt Fjeld
> Is F.P. an idea that's still considered important? Is it important
> for Lisp programmers in "the real world"?
I think it's a very important concept that should always be considered
by anyone doing any kind of programming.
Maybe CL should have included the ability to declare a function as
"functional" (side-effect-free, that is).
--
Frode Vatvedt Fjeld
Hannah Schroeter
In article <3978C6DE...@iname.com>,
Fernando D. Mato Mira <mato...@iname.com> wrote:
>The Glauber wrote:
>> My superficial observation is that Lisp users seem to be more tolerant
>> of side-effects in their programs than Scheme users.
>But Common Lisp is more functional:
>http://series.sourceforge.net/
This reminds me very much of Haskell's lazy lists in combination with the
deforestation optimization(s).
Regards, Hannah.
The Glauber
please play nicely or get out of the playpen...
glauber
The Glauber
What do you mean by using functional ideas?
I, for example, try to make methods or functions self-contained, try to
avoid global variables, try to encapsulate state in classes. Is this
what you're writing about?
glauber
--
Glauber Ribeiro
thegl...@my-deja.com http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"
The Glauber
Thanks, this was a great post; i'm keeping it for future reference.
> #:Erik
> --
> If this is not what you expected, please alter your expectations.
OK
Dorai Sitaram
>> found much material on it on the Web (which means i'm probably looking
>> in the wrong place). There are a number of purely functional
>> programming languages, then there's Lisp-ish languages and everything
>> else.
>>
>> of side-effects in their programs than Scheme users.
>
>strictly maintaining language purity. personally, i think common-lisp
To first talk about the languages as things in
themselves: Scheme and CL are identical in their
approach to side-effects (modulo only spelling). They
both allow changing the bindings of variables, and
they both allow mutating the contents of compound
data. (Some languages like ML allow side-effects of
the second type only, so one has to mimic assignable
variables by defining a pro-forma compound datum
called the reference. References require special
syntax for mere access, which Scheme and CL
variables don't.) You'd be shortchanging yourself if
you used side-effects as a litmus to choose one of
Scheme or CL over the other.
To next talk about usage: I disagree with the
speculation that Scheme usage is more leery of
side-effects, even if the language allows them. Both
Scheme and CL have a non-imperative core, and users in
both languages make forays out of this _as the
situation demands_. Of course no one is going to use
side-effects (or _anything_) gratuitously, not even in
the C world, where assignment is used because it is
the only way to solve a problem (another way of
looking at this is that C's non-imperative core is not
powerful enough). In Scheme and Common Lisp, it isn't
that side-effects are curtailed, but that alternatives
exist in the form of really powerful procedural
constructs, and naturally they also find use. The
full power of side-effects is nevertheless still
there.
No influential Scheme group is side-effect-shy, but
even so, the Scheme community I followed (Rice,
Indiana) is extremely active in the imperative aspect
of Scheme, fending off as it did the prevailing myth
at the time that you cannot have mathematically
reasonable languages that also had imperative
features. It has done extensive work charting out the
imperative landscape of Scheme, mapping it into two
categories, i.e., State and Control. Some of the most
persuasive elucidation that a purely functional
approach (however higher-order) is weaker than its
combination with imperative features comes from this
community. Even the most idle surfing of the
Scheme offerings on the Rice web site will put to rest
any concerns you may have that side-effects receive
but cursory treatment in the Scheme world.
If you find Scheme useful and you like it, explore
it. Same goes for CL. Avoid getting trapped in pat
binarisms. I wish you success and fun in your
explorations!
--d
Shiv
It requires a certain mindset to be a good CL programmer (as opposed
to a good C programmer). Similarly, to ge a good "purely functional
non-strict" language (eg. Clean) programmer it requires a different
mindset. For many people the lack of side-effects is intolerable
(rightly so, as evidenced by the reactions in this thread). Usually
one is forced into passing the state around, and this can become
intolerable if designed inappropriately. The monadic-style is to hide
the state, say in an abstract datatype (or just by discipline), and
provide operators that will sequence actions and pass the state around
under the covers. {Aside: for a beautiful use of monadic-style in Caml
see the sources for fftw in www.fftw.org}. The monadic style is
popular in ML (and its variants), Haskell, etc.. The Clean
(www.cs.kun.nl/~clean) approach is a little bit more palatable. It has
the notion of uniqueness types whereby you can declare that some
object will not be shared by anything else when a function is
invoked. Since side-effects are only a problem when sharing is
present, this effectively overcomes it, and you get destructive
updates in a functional manner. So you can get arrays to behave like
arrays. However, this is does not make CL+CLOS! But, good Clean (or
Haskell) programmers have done pretty well. For example Clean has its
entire IDE written in Clean! A stateful task done well.
So before shooting all the children of Lisp (after all that is what
ML, Haskell, Clean, etc. are) it might be worth your effort to take a
closer look. If you want to take a look at only one, may I suggest
Clean? As somebody else already mentioned, these languages really
emphasize strong typing with type inferencing as one of their strong
points besides functional style and/or laziness. They also have some
neat features like list and array comprehensions. Of course, many of
these features could possibly be added to CL via macros and
stuff. Have fun!!
--shiv--
Xah
> - What do you think is going on in someone's head when they
> "think about" something? That is, do you think it's an excerise
> in "functional process" (e.g., side-effect-free decomposition or
> some such) or "imperative process" (manipulation of the stateful
> stuff you seem to abhor so) or how would you characterize it?
this is a silly question. Do you think deity exist? Do you think they are
sexy?
These type of questions belong to metaphysics, classical philosophy, and
classical psychology. They are passé in our info age, except that Freudian
theories are still used by shrinks to comfort people and shrinking their
wallets.
What's _thinking_ anyway? How do you know that my existence isn't just your
fancy? (after all, it is in your head.) For these questions, better dig
neuroscience and information science for answers.
Furthermore, "functional" and "imperative" describe computation
methodologies that we invented. Why do you assume that these notions are
applicable (or maps) to how our brain processes? Are you supposing that
human thinking has been completely understood or codified? You are forcing a
simile. (or "isomorphism" as you say)
(btw, _isomorphism_ is a mathematical term bearing a rigorous definition in
an axiomatic context. A lookup in dictionaries indicated that it is used in
technical contexts only. (math, biology, chemistry.) Your usage of '_proper_
isomorphism' to endeavor a sense of mathematical mapping between two totally
ill-defined and disparate things seems to me stultifying.)
Most of you have thought of the innocent question "how big is the universe",
and so have our ancestors. In hindsight, it seems foolish that our ancestors
pondered such a question without having taken a course in calculus and
learned the ins and outs of bounded and finiteness concepts. In fact, it's
quite ridiculous if modern notions of dimensionality are not present in the
questioner's mind. But actually it's truly ludicrous if we are ignorant of
shapes of space (topology) & non-Euclidean geometries. Frankly, it is a
fucking stupid question in additional light of space-time continuum of
Relativity. The point here is: what you think as sensible questions are not
always good questions.
I would suggest that anyone who are interested in philosophy in general to
follow Bertrand Russell's logical positivism school of thought, and ask not
big-time metaphysical questions or lore but study logic & linguistics &
mathematics: put your foot on solid ground.
having read so many language wars and literatures, i find it trite. The best
language, is the one with the most good unyielding mathematical properties.
The more interesting question is, the mathematical study of different
ideology of such property sets, and possible ISOMORPHISM between them.
In newsgroups, few are educated enough to be aware of such a level of
thought. They argue sugar syntaxes, they argue C++ vs Java, they argue my GC
vs your GC, they argue high-level vs low level, they argue trivial
psychology, they argue sizes, they argue petty arguments blithely and often
blindly too.
> - Notwithstanding your answer, do you give any credence to the notion of
> mental isomorphism? That is, do you suppose there is value in having
> the "shape" of mental conceptions match the "shape" of reality (e.g.,
> to minimize the computational cost of marshalling and unmarshalling
> brain data and/or reality data, depending on which way you're going)
> or is that simply an irrelevancy?
I deem it irrelevant because such an observation is not a scientific
observation; it has little value in aiding science.
> Likewise, do you see any value in
> reasoning in a way that is consistent with the mechanism?
> For example,
> you could model a coke machine using "statistics" or "functional
> expressions", but it seems to me there is more value to modeling it as
> a state machine since it is, in fact, such a thing.
(ok, so drinking machines are sate machines. Therefore the so called "human
thinking" jams into an excluded middle of functional/imperative?)
> If you choose to
> model something in a way that it in fact doesn't work (as pre-Kepler
> folk used to model the rotation of the planets in their spirograph-like
> curly-orbit way), don't you risk overcomplicate the simple?
Here we are talking about planetary motion, which is a matter of eye-balling
paths very well-defined and easily verified under science. You were talking
about modeling of human thought -- a not well-defined thingy -- and
insisting it "maps" to some ill-defined computational model. (Ockham's razor
would cut you to pieces.)
> And so
> doesn't it come down to how people think? Not how you wish them to think
> but how they in fact think? (Can you cite experiments to show that you
> have a clear and uncontroverted theory of how they think such that you
> are sure you are not advocating dissonance between our mental models
> and our devices for aiding in computation?)
How people think?
No, i don't care how people think, but how they should think according to
knowledge. I understand the iffiness of purpose of life, i understand that
theory needs corrections, but it is science & theories that we should base
our argument or decisions on, not metaphysics, culture, fad, or what you or
me think "how people thinks".
You know well how Theories of Relativity changed thinking? Do you know how
the existence of irrational numbers changed thinking? Do you know how
non-Euclidean geometry changed thinking? Do you know how Godel's theorem
changed thinking? Do you know how Penrose Tiles changed thinking? (and so on
and on and on.)
It's not "how people think" that matters, but "what do we know about how
people think" and "what's the best way to think according to our
understanding?". What is the (scientific) value of saying "human thinks more
like imperative programing than functional decomposition"? I'm totally
flummoxed on how such mapping maps, and fear such observation can only
impede progress. As technology pushes us willy-nilly towards a pure
information age, untruths and ignorance will become the primary woe among
all vices and calamities. Cultivate one untruth, and you'd cause a damage
more devastating than mass murder.
> Sometimes, obviously, the
> technique for the computation may be well-understood and accepted; but
> where it is not, debuggability comes (it seems to me) best when people
> have some way of destructuring the problem into intelligible components;
> isomorphism between the real world and the computation isn't the only
> way to do it, but it doesn't seem to me that one should discount it as
> a ridiculous way, either, in the case where programmers want to do it.
I understand your humanitarian approach to things. Of course, mathematics
has intrinsic limitations and is of little power in the context of all
crannies of human daily affairs. I cannot use formalism to decide whether i
should kiss a girl, nor maximize my income by solving an equation. However,
science is the ONLY way of real progress. (almost "by definition".) You are
not doing computer _science_ if you stray too far from scientific
approaches. (for what's worth: what i'm doing here is the science AND art of
critical criticizing.)
What is your issue anyway? It is fine if you like Common Lisp better than
Scheme, but not fine to litter untruths such as "human nature this or that".
It is not really imperative programing that i attack in this thread, but
your skunking "humanitarian" droppings.
PS "progress" is defined as betterment of human state in general that i wish
neophyte thinkers won't moot a nitpicking.
Xah
x...@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
Erik Naggum
| Maybe CL should have included the ability to declare a function as
| "functional" (side-effect-free, that is).
Most Lisp compilers include such a mechanism, but the guarantee is
even harder to maintain and guarantee than typing, and it should not
affect correctness, so nothing is lost by considering this as part
of the great optimization problem.
Robert Monfera
> I suspect that most of those that suggest that OO is in any
> way related to FP Just Didn't Get It when they did their two
> week module on functional programming.
Polymorphism and inheritance are more important aspects of OO than
object identity (encapsulation being further down). These two concepts
blend perfectly with FP for those completing their two week module on
functional programming. With CLOS, it is highly possible to write
functions that return objects, which get garbage collected after a
one-time use.
Of course, there are people for whom OO is not OO without their pet
feature (e.g., those who say CLOS is not OO because it lacks
encapsulation).
Maybe you wanted to say that object identity does not mix with FP, or
that you consider object identity the sole defining feature of OO,
polymorphism being a mere accident. If it's the latter, maybe it's just
the side effect of your preference of imperative programming over both
FP and polymorphism.
Robert
Robert Monfera
> These type of questions belong to metaphysics, classical philosophy,
> and classical psychology. They are passé in our info age
Ever heard of cognitive science and cognitive psychology in our info
age? Had you studied it a little, you would have understood that the
brain does not necessarily solve logically isomorph problems the same
way. Your naive fixa idea gets old fast.
Robert
Kent M Pitman
> Kent M Pitman <pit...@world.std.com> 24 Jul 2000 03:53:43 GMT wrote:
> > - What do you think is going on in someone's head when they
> > "think about" something? That is, do you think it's an excerise
> > in "functional process" (e.g., side-effect-free decomposition or
> > some such) or "imperative process" (manipulation of the stateful
> > stuff you seem to abhor so) or how would you characterize it?
>
> this is a silly question.
If I were implementing CORBA and talking about the efficiency of marshalling
and unmarshalling data between two processors that shared no address space,
it would make a big difference to know whether they used the same
representational systems because it would affect the computational overhead
significantly--would I have to transform each data item or could I pass
stuff essentially "straight through". I think the issue is no less
relevant to mental-to-computer links. And just because you can't reliably
measure how computations is represented doesn't mean it's not relevant.
Far from a silly question, I'd allege, it seems to me a central question.
Just my opinion, though. Somehow I anticipate that your mileage will vary.
Xah
it is unfortunate that i usually find your (newsgroup) writings to be
antithesis of the logical. (same goes for Peter Gabriel's Pattern of
Software trash) I wonder if it's merely a manifestation of stylistic clash,
or some fundamental world-view incongruity in us, or simply your writings
don't shine.
Kent M Pitman <pit...@world.std.com> 25 Jul 2000 07:14:01 GMT wrote:
> If I were implementing CORBA and talking about the efficiency of marshalling
> and unmarshalling data between two processors that shared no address space,
> it would make a big difference to know whether they used the same
> representational systems because it would affect the computational overhead
> significantly--would I have to transform each data item or could I pass
> stuff essentially "straight through".
Fine example of a computing task that i could imagine.
> I think the issue is no less
> relevant to mental-to-computer links.
Where is your support for this opinion? It doesn't really connect to the
previous example or address my criticism.
> And just because you can't reliably
> measure how computations is represented doesn't mean it's not relevant.
Yeah, but just because you can cite a "just because" doesn't mean it's
relevant. I want to see buttresses of your fancy edifice.
> Far from a silly question, I'd allege, it seems to me a central question.
A central pitfall, perhaps. Mumble jumble i insist.
> Just my opinion, though. Somehow I anticipate that your mileage will vary.
peace, brother!!
Xah
x...@xahlee.org
http://www.xahlee.org/PageTwo_dir/more.html
Tim Bradshaw
> Why are we talking about bricks and concrete in a lisp newsgroup?
After long experiment it was found preferable to talking about why
Lisp is slower than C++...
--tim
Erik Naggum
| it is unfortunate that i usually find your (newsgroup) writings to
| be antithesis of the logical. (same goes for Peter Gabriel's Pattern
| of Software trash) I wonder if it's merely a manifestation of
| stylistic clash, or some fundamental world-view incongruity in us,
| or simply your writings don't shine.
Or it could simply be a consequence of the fact that you're the only
sane person in the whole entire universe.
Reini Urban
>Why are we talking about bricks and concrete in a lisp newsgroup?
indeed. it's summer and some really should be talking about icecream and
its various flavors. time is not ready for architecture yet.
--
Zur Einschätzung der aktuellen Situation in Ö
http://www.tuwien.ac.at/diskurs/
Reini Urban
>* Xah <x...@xahlee.org>
>| it is unfortunate that i usually find your (newsgroup) writings to
>| be antithesis of the logical. (same goes for Peter Gabriel's Pattern
>| of Software trash) I wonder if it's merely a manifestation of
>| stylistic clash, or some fundamental world-view incongruity in us,
>| or simply your writings don't shine.
>
> Or it could simply be a consequence of the fact that you're the only
> sane person in the whole entire universe.
now this *IS* logical to me.
(though I still don't understand ~three postmodern words per
xah-sentence)
Rainer Joswig
<sh...@balrog.ece.ucsb.edu> wrote:
> Clean? As somebody else already mentioned, these languages really
> emphasize strong typing with type inferencing as one of their strong
> points besides functional style and/or laziness. They also have some
> neat features like list and array comprehensions. Of course, many of
> these features could possibly be added to CL via macros and
> stuff. Have fun!!
As you might imagine, most of these "features" are available
for CL or for subsets of CL. Type inferencing, list
comprehensions, etc have been added several times to CL.
Remember, Common Lisp is a language laboratory.
--
Rainer Joswig, BU Partner,
ISION Internet AG, Steinhöft 9, 20459 Hamburg, Germany
Tel: +49 40 3070 2950, Fax: +49 40 3070 2999
Email: mailto:rainer...@ision.net WWW: http://www.ision.net/
Rainer Joswig
> It requires a certain mindset to be a good CL programmer (as opposed
> to a good C programmer).
No, you don't need a certain "mindset". Common Lisp supports
one hundred different mindsets.
Giving up mental blockades helps, though.
Wolfhard Buß
> As you might imagine, most of these "features" are available
> for CL or for subsets of CL. Type inferencing, list
> comprehensions, etc have been added several times to CL.
Any references?
-wb
William Deakin
> (though I still don't understand ~three postmodern words per
What is a postmodern word?
;)will
Rainer Joswig
Buß) wrote:
Type inferencing/checking:
- CMU CL
- SEQUEL
- ACL2
- http://www.dcs.qmw.ac.uk/SEL-HPC/Articles/GeneratedHtml/functional.imptype.html
- The Nimble Type Inferencer for Common Lisp-84
http://citeseer.nj.nec.com/cachedpage/87589/1
For list comprehension things, the CMU Lisp archive
should lead to success or look for old comp.lang.lisp
postings.
Examples:
(defun qsort (ax)
(and ax
(let ((a (car ax))
(x (cdr ax)))
(append (qsort [y (y <- x) (< y a)])
(list a)
(qsort [y (y <- x) (>= y a)])))))
(miranda perms (x)
() => '(())
(_ . _) => [(cons a p)
(a <- x)
(p <- (perms (remove a x :count 1)))])
Reini Urban
I cannot tell you exactly now what it is, because I don't understand it,
as I said, I can only show you what I mean. First I try it with some
examples picked from random sentences:
xah sentence #1:
"it is unfortunate that i usually find your (newsgroup) writings to be
antithesis of the logical."
xah sentence #2:
"(same goes for Peter Gabriel's Pattern of Software trash) I wonder if
it's merely a manifestation of stylistic clash, or some fundamental
world-view incongruity in us, or simply your writings don't shine."
xah sentence #3:
"this is a silly question. Do you think deity exist? Do you think they
are sexy?"
pm words in #1: "antithesis of the logical"
pm words in #2: "Pattern of Software trash", "world-view incongruity"
pm words in #3: deity, exist, sexy
proofs of concept:
http://www.elsewhere.org/cgi-bin/postmodern/
To some extent also:
http://www-cs-faculty.stanford.edu/~zelenski/rsg/grammars/
ideology:
(Unfortunately I have my own postmodernism ramblings only in german,
so)
A positivistic approach to postmodernism in computer languages:
http://www.wall.org/~larry/pm.html
rationale:
I see words taken from new fields and put into an old and closed
context. This would not be harmful per se. The problem is that I don't
understand the reason to use such words in this context. Is just the
word that makes no sense or is the whole sentence?
My guess -and that is why I said "postmodern"- that the author wants
to hide the fact that he doesn't understand any meaning of our words or
sentences, so he tooks "random" but interesting or may-fit words,
applies them to our trash of sentences (in his view) to criticize our
methods to communicate. This is a interesting deconstructive method but
unfortunately only interesting to folks who don't understand the
comp.lang.lisp level of communication, and worse for me, completely non
understandable from his point of view because I don't know the original
context where he took these words from. The criticized words and
sentences make perfect sense for me, and the irritations are
non-constructive.
Xah
Reini Urban wrote:
> (though I still don't understand ~three postmodern words per
William Deakin <w.de...@pindar.com> 26 Jul 2000 07:53:27 GMT wrote:
> What is a postmodern word?
C'mon people, there are dictionaries on the web. Look up and savor every
word. What's your rush?
my American Heritage dictionary (1995) says:
postmodern or post-modern adj. 1. Of or relating to art, architecture, or
literature that reacts against earlier modernist principles, as by
reintroducing traditional or classical elements of style or by carrying
modernist styles or practices to extremes: łthe post-modern mode of tapering
the tops of buildings˛ Jane Holtz Kay
Not until i looked up this word now, i find sense in Larry Wall's outcry:
"Perl is a postmodern language".
Larry Wall is at the minimum an _artful_ criminal. One could disregard his
damages to the computing world, and enjoy his writings.
Kent Pitman, you still haven't answered my question about what you think of
Perl. (could you indulge ME and answer that?) Was Perl, in your opinion, a
language based on fine principles?
Xah
x...@xahlee.org
http://www.xahlee.org/PageTwo_dir/more.html
"Disclaiming claim: I'm insane."
William Deakin
Xah wrote:
> William Deakin <w.de...@pindar.com> 26 Jul 2000 07:53:27 GMT wrote:
> > What is a postmodern word?
>
> C'mon people, there are dictionaries on the web. Look up and savor every
> word.
postmodern word was (as opposed to a modernist, neo-gothic or romantist
word, say).
> Not until i looked up this word now, i find sense in Larry Wall's outcry:
> "Perl is a postmodern language".
>
> Larry Wall is at the minimum an _artful_ criminal. One could disregard his
> damages to the computing world, and enjoy his writings.
Yup.
:)will