Alexander Schmolck wrote:
> laotseu <······@removethis.free.fr> writes:
(snip : someone here posted about his fear that the few functionnal
features in Python could be deprecated one day)
>
>>Paul Foley wrote:
>>
>>>On Tue, 15 Apr 2003 23:49:37 +0000, laotseu wrote:
>>>
>>>
>>>>Even for OO programmers, functionnal features in Python are IMHO a
>>>>great plus, and BTW functionnal and OO paradigm does not have to
>>>>conflict (that would be functionnal vs imperative and object vs
>>>>procedural). CLOS is one of the great system objects out here, and
>>>>it's been implemented on top of a functionnal language,
>>>
> ^^^^^^^^^^^^^^^^^^^^
>
> You go and say that in comp.lang.lisp :)
>
> 'as
Ok, cross-posted and fu2 positionned.
Lispers friends, let's have you're opinion on that point : is Common
Lisp a functionnal language ?
<Paul>
Your turn now : *you* go and say in comp.lang.lisp that Common Lisp *is
not* a functionnal language !-)
</Paul>
Laotseu
laotseu <······@removethis.free.fr> writes:
> Ok, cross-posted and fu2 positionned.
[re-cross-posted]
> Lispers friends, let's have you're opinion on that point : is Common
> Lisp a functionnal language ?
Other CL-ers have already correctly answered you. And the answers
assume an understanding of the dimensions of this question. There are
in fact at least a couple of dimensions to your question - it can be taken
as either a question of capability or as a question of focus. The "is",
on the other hand, implies a question of definition (e.g. what _is_ it?)
Definition: CL is a powerful, general-purpose programming language.
Capability: Can CL users program functionally in CL? Absolutely.
Can CL users write non-functional programs? Absolutely.
Focus: Does CL focus on or force a functional programming style? No.
Might some CL users force a functional programming style on
their programs? Yes, of course. Are such users still programming
in CL? Yes. Must other programmers modifying the original code
stick to the same functional model of programming? Not by CL
standards; any such agreement to stay within FP boundaries would
be external to CL (and would probably involve some kind of monetary
transaction :-)
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
laotseu <······@removethis.free.fr> writes:
> Ok, cross-posted and fu2 positionned.
Followup reset. Lisp users already know the answer to this one; if
Python users also want to, it should go to comp.lang.python.
> Lispers friends, let's have you're opinion on that point : is Common
> Lisp a functionnal language ?
Common Lisp is a multiparadigm language. If the question is "Does
Common Lisp support a functional style of programming", the answer is
"yes". If the question is "Does Common Lisp _require_ a functional
style of programming", no, absolutely not.
And to say that CLOS is built "on top of" CL, though historically
accurate, is no longer really correct. CLOS is _part_ of ANSI Common
Lisp.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
laotseu <······@removethis.free.fr> writes:
> Lispers friends, let's have you're opinion on that point : is Common
> Lisp a functionnal language ?
Common Lisp is whatever you want it to be: You can write
functional-style programs in it if you want, but is certainly not a
"pure" functional language. It supports several other paradigms
equally well, and even more important, it will let you integrate
yet-unkown paradigms when you think that they are useful.
There are really ideas to remove the functional stuff from Python? I
wonder why people frequently think that making things impossible will
improve programming languages.
just-because-it's-flexible-doesn't-mean-it's-perl-ly y'rs
Henrik
"Henrik Motakef" <··············@web.de> wrote ...
> laotseu <······@removethis.free.fr> writes:
>
> > Lispers friends, let's have you're opinion on that point : is Common
> > Lisp a functionnal language ?
>
> Common Lisp is whatever you want it to be: You can write
> functional-style programs in it if you want, but is certainly not a
> "pure" functional language. It supports several other paradigms
> equally well, and even more important, it will let you integrate
> yet-unkown paradigms when you think that they are useful.
>
> There are really ideas to remove the functional stuff from Python? I
> wonder why people frequently think that making things impossible will
> improve programming languages.
>
> just-because-it's-flexible-doesn't-mean-it's-perl-ly y'rs
I can see that, but wouldn't you agree that removing redundant features also
removes cruft from the source, and eases the maintenance burden, in turn
reducing the likelihood of implementation bugs? While Guido is known to
regret the inclusion of lambda in Python, I don't think he would want to
take it out on purely ideological grounds. Indeed, the suggestion was not so
much that it would be taken out of the existing language, rather that it
would not be implemented in some "futurePython", normally called Python 3 or
Python 3000.
It would be nice to have One True Python, but that's about as likely as One
True Lisp. The Python world is pragmatic enough to be able to live with "one
*most obvious* way to do it", but if there are two similar features in the
language they have to be maintained in lockstep as the language develops.
just-becuase-it's-there-doesn't-mean-it's-helpful-ly y'rs - steve
--
Steve Holden http://www.holdenweb.com/
How lucky am I? http://www.google.com/search?q=Steve+Holden&btnI=1
Python Web Programming http://pydish.holdenweb.com/pwp/
On Thu, Apr 17, 2003 at 02:49:33PM +0000, Steve Holden wrote:
> I can see that, but wouldn't you agree that removing redundant features also
> removes cruft from the source, and eases the maintenance burden, in turn
> reducing the likelihood of implementation bugs? While Guido is known to
> regret the inclusion of lambda in Python, I don't think he would want to
> take it out on purely ideological grounds. Indeed, the suggestion was not so
> much that it would be taken out of the existing language, rather that it
> would not be implemented in some "futurePython", normally called Python 3 or
> Python 3000.
>
> It would be nice to have One True Python, but that's about as likely as One
> True Lisp. The Python world is pragmatic enough to be able to live with "one
> *most obvious* way to do it", but if there are two similar features in the
> language they have to be maintained in lockstep as the language develops.
What's wrong with Python and CL!!!? They have all these extraneous
features which can accomplish the same thing!!! All you need is the
<insert model of computability here>!!! Anything else is liable to
develop cruft and cause bugs in the single implementation of our ONE
PURE LANGUAGE!!! I can't believe that people might want to model
problems any other way!!!
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
"Matthew Danish" <·······@andrew.cmu.edu> wrote in message
··························@lain.cheme.cmu.edu...
> On Thu, Apr 17, 2003 at 02:49:33PM +0000, Steve Holden wrote:
> > I can see that, but wouldn't you agree that removing redundant features
also
> > removes cruft from the source, and eases the maintenance burden, in turn
> > reducing the likelihood of implementation bugs? While Guido is known to
> > regret the inclusion of lambda in Python, I don't think he would want to
> > take it out on purely ideological grounds. Indeed, the suggestion was
not so
> > much that it would be taken out of the existing language, rather that it
> > would not be implemented in some "futurePython", normally called Python
3 or
> > Python 3000.
> >
> > It would be nice to have One True Python, but that's about as likely as
One
> > True Lisp. The Python world is pragmatic enough to be able to live with
"one
> > *most obvious* way to do it", but if there are two similar features in
the
> > language they have to be maintained in lockstep as the language
develops.
>
> What's wrong with Python and CL!!!? They have all these extraneous
> features which can accomplish the same thing!!! All you need is the
> <insert model of computability here>!!! Anything else is liable to
> develop cruft and cause bugs in the single implementation of our ONE
> PURE LANGUAGE!!! I can't believe that people might want to model
> problems any other way!!!
>
Absolutely. Your pure approach causes me to shed tears of joy. If only
everyone else could see the Truth. In fact, were there endless time, all we
would need would be One True Turing Machine and an Infinite Number of
Monkeys.
Did I mention that you only need nine commands to write any program? ;-)
and-we-could-dispense-with-the-turing-machine-at-a-pinch-ly y'rs - steve
--
Steve Holden http://www.holdenweb.com/
How lucky am I? http://www.google.com/search?q=Steve+Holden&btnI=1
Python Web Programming http://pydish.holdenweb.com/pwp/
Steve Holden wrote:
> "Henrik Motakef" wrote ...
>
> >laotseu writes:
> >
> >
> >>Lispers friends, let's have you're opinion on that point : is Common
> >>Lisp a functionnal language ?
> >
> >Common Lisp is whatever you want it to be: You can write
> >functional-style programs in it if you want, but is certainly not a
> >"pure" functional language. It supports several other paradigms
> >equally well, and even more important, it will let you integrate
> >yet-unkown paradigms when you think that they are useful.
> >
> >There are really ideas to remove the functional stuff from Python? I
> >wonder why people frequently think that making things impossible will
> >improve programming languages.
> >
> >just-because-it's-flexible-doesn't-mean-it's-perl-ly y'rs
>
>
>
> I can see that, but wouldn't you agree that removing redundant
> features also
> removes cruft from the source, and eases the maintenance burden, in turn
> reducing the likelihood of implementation bugs? While Guido is known to
> regret the inclusion of lambda in Python, I don't think he would want to
> take it out on purely ideological grounds. Indeed, the suggestion was
> not so
> much that it would be taken out of the existing language, rather that it
> would not be implemented in some "futurePython", normally called
> Python 3 or
> Python 3000.
>
> It would be nice to have One True Python,
Hav I missed something? I thought that that is exactly what you have now :)
Cheers
--
Marco Antoniotti
"Steve Holden" <·······@holdenweb.com> writes:
> While Guido is known to regret the inclusion of lambda in Python
But he regrets the inclusion of a crippled lambda, rather than the
inclusion of support for anonymous functions (IIRC).
>But he regrets the inclusion of a crippled lambda, rather than the
>inclusion of support for anonymous functions (IIRC).
I was toying around in my own python parser about a year ago,
attempting to implement anonymous functions there. It was a
struggle, and in the end, I felt basically *forced* down the
same path the Python team went, until I included a set of tokens
for explicit scope (hey! this is just a toy environment, don't
look scandalized!).
Anyway, I guess what I'm saying is that I suspect that Guido
didn't have any good alternatives. If someone has some, that
fit well with our beloved block delimited language, SHOW ME
DA MONEY! :-)
C//
From: Mark Jason Dominus
Subject: Re: Why functional Python matters
Date:
Message-ID: <b86lc3$tnd$1@plover.com>
In article <··································@4ax.com>,
Courageous <·······@san.rr.com> wrote:
>
>>But he regrets the inclusion of a crippled lambda, rather than the
>>inclusion of support for anonymous functions (IIRC).
>
>Anyway, I guess what I'm saying is that I suspect that Guido
>didn't have any good alternatives.
I don't believe that's correct. At an early Open Source Conference,
perhaps around 1998 or so, I was present at a conversation between
Guido and Tom Christiansen. Tom asked Guido why Python didn't have
closures, and Guido's reply (and I think this is an exact quote) was
"Closures aren't important."
I remember it because I was so astonished by the obtuseness of the answer.
In article <············@plover.com>,
Mark Jason Dominus <···@plover.com> wrote:
>In article <··································@4ax.com>,
>Courageous <·······@san.rr.com> wrote:
>>Courageous as usual deleted someone else's attribution:
>>>
>>>But he regrets the inclusion of a crippled lambda, rather than the
>>>inclusion of support for anonymous functions (IIRC).
>>
>>Anyway, I guess what I'm saying is that I suspect that Guido
>>didn't have any good alternatives.
>
>I don't believe that's correct. At an early Open Source Conference,
>perhaps around 1998 or so, I was present at a conversation between
>Guido and Tom Christiansen. Tom asked Guido why Python didn't have
>closures, and Guido's reply (and I think this is an exact quote) was
>"Closures aren't important."
>
>I remember it because I was so astonished by the obtuseness of the answer.
Two points:
* I'd be mildly surprised if that were an exact quote. Python 2.1 was
released 4/2001, with support for nested scopes (which allows building
closures of sorts). That's roughly two years for Guido to change his
mind, which is a short timeframe for him. ;-)
* Many of the things for which programmers in other languages use
closures are better done in Python as classes. He's generally
antipathetic to borrowing idioms from other languages that make it easier
to write unpythonic code -- There's Only One Way. Like other leaders in
the Open Source community, Guido is occasionally prone to making
obnoxious comments Just Because.
--
Aahz (····@pythoncraft.com) <*> http://www.pythoncraft.com/
Why is this newsgroup different from all other newsgroups?
···@plover.com (Mark Jason Dominus) wrote in message news:<············@plover.com>...
> I don't believe that's correct. At an early Open Source Conference,
> perhaps around 1998 or so, I was present at a conversation between
> Guido and Tom Christiansen. Tom asked Guido why Python didn't have
> closures, and Guido's reply (and I think this is an exact quote) was
> "Closures aren't important."
>
> I remember it because I was so astonished by the obtuseness of the answer.
Well, it seems the burden of proof is on you. Please explain the
usability advantages of closures vs. Python's current scope system.
Tj
Hmm, must be sleepy because I could have sworn that you wrote that you
asked him this question, not Tom Christiansen.
Tj
··········@yahoo.com (Tj) wrote in message news:<···························@posting.google.com>...
> ···@plover.com (Mark Jason Dominus) wrote in message news:<············@plover.com>...
> > I don't believe that's correct. At an early Open Source Conference,
> > perhaps around 1998 or so, I was present at a conversation between
> > Guido and Tom Christiansen. Tom asked Guido why Python didn't have
> > closures, and Guido's reply (and I think this is an exact quote) was
> > "Closures aren't important."
> >
> > I remember it because I was so astonished by the obtuseness of the answer.
>
> Well, it seems the burden of proof is on you. Please explain the
> usability advantages of closures vs. Python's current scope system.
laotseu wrote:
> Lispers friends, let's have you're opinion on that point : is Common
> Lisp a functionnal language ?
>
> <Paul>
> Your turn now : *you* go and say in comp.lang.lisp that Common Lisp *is
> not* a functionnal language !-)
> </Paul>
>
> Laotseu
>
I'm not an expert, but still...
There are several features of Lisp that are not pure-functional and
treated a little bit different in other functional (or purer :))
languages I'm aware of. For example, global variables (setq, if i'm
correct) are not allowed in purist FL and mostly treated with Monads
that plays an important role in Haskell.
Anton.
Anton Muhin <··········@sendmail.ru> writes:
> laotseu wrote:
> > Lispers friends, let's have you're opinion on that point : is Common
> > Lisp a functionnal language ?
> > <Paul>
> > Your turn now : *you* go and say in comp.lang.lisp that Common Lisp
> > *is not* a functionnal language !-)
> > </Paul>
>
> I'm not an expert, but still...
>
> There are several features of Lisp that are not pure-functional and
> treated a little bit different in other functional (or purer :))
> languages I'm aware of. For example, global variables (setq, if i'm
> correct) are not allowed in purist FL and mostly treated with Monads
> that plays an important role in Haskell.
Nobody ever claimed that Common Lisp was a ``purely functional��
language. But any definition of ``functional language�� that doesn't
include Common Lisp and ML is ... probably more propaganda than
anything else.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
On 17 Apr 2003 14:32:36 +0200, Nils Goesche wrote:
> Anton Muhin <··········@sendmail.ru> writes:
>> laotseu wrote:
>> > Lispers friends, let's have you're opinion on that point : is Common
>> > Lisp a functionnal language ?
>> > <Paul>
>> > Your turn now : *you* go and say in comp.lang.lisp that Common Lisp
>> > *is not* a functionnal language !-)
>> > </Paul>
>>
>> I'm not an expert, but still...
>>
>> There are several features of Lisp that are not pure-functional and
>> treated a little bit different in other functional (or purer :))
>> languages I'm aware of. For example, global variables (setq, if i'm
>> correct) are not allowed in purist FL and mostly treated with Monads
>> that plays an important role in Haskell.
> Nobody ever claimed that Common Lisp was a ``purely functional��
> language. But any definition of ``functional language�� that doesn't
> include Common Lisp and ML is ... probably more propaganda than
> anything else.
Why should it include CL? It might mention Lisp in a historical note,
but to me calling something a "functional language" implies that the
usual programming style is functional (or at least mostly functional),
which is not how Lispers ordinarily write Lisp (unless they've been
over-exposed to Scheme at some point, anyway). So I say no, Lisp is
not "a functional language" (but not because it has SETQ!)
--
There is no reason for any individual to have a computer in their home.
-- Ken Olson, President of DEC
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
Paul Foley <·······@actrix.gen.nz> writes:
> On 17 Apr 2003 14:32:36 +0200, Nils Goesche wrote:
...
> > Nobody ever claimed that Common Lisp was a ``purely functional��
> > language. But any definition of ``functional language�� that doesn't
> > include Common Lisp and ML is ... probably more propaganda than
> > anything else.
>
> Why should it include CL? It might mention Lisp in a historical note,
> but to me calling something a "functional language" implies that the
> usual programming style is functional (or at least mostly functional),
> which is not how Lispers ordinarily write Lisp (unless they've been
> over-exposed to Scheme at some point, anyway). So I say no, Lisp is
> not "a functional language" (but not because it has SETQ!)
CL contains some functional programming tools, but I recall occasions
where we had design conversations in which various people advocated
specific decisions in support of the functional community and others
were quick to say that they were not proponents of functional
programming. In political terms, our constituents certainly included
functional programmers, but our 'political platform' was not controlled
by the FP community. We were in our design, and now are in our
practice, unabashedly a multi-paradigm Lisp that caters to a variety
of needs, none to the exclusion of others. We have functions as first
class objects, for example, but we have keyword arguments.
One might claim that instead of
(find x y :test #'equal :key #'car)
we should have just done
(find-if (lambda (a) (equal (car a) x)) y)
but we felt that the keyword style, while less general, was easier to
read and program.
One might claim that we should have had reliable tail call elimination
but we traded this explicitly for making easy stack debuggability a
conforming practice.
One might claim that CL did not need tagbody/go because they were
available using tall calling, but we had already given up tail calls,
and anyway we felt that the alternate style of go was useful to support
as a primitive style for certain kinds of applications. We didn't see
a reason to force people to express this paradigm in a notation that
pretended something else was going on than simple goto.
One might claim that we should have had only a single namespace, not the
so-called dual namespace system (actually four - variables, functions,
go tags, and block tags). We felt this provided best readability, easiest
efficiency, most compatibility with tradition, and the least need for a
complicated macro system [using a single namespace requires more complicated,
"hygienic" macros which are not needed in a dual namespace system].
One might claim that we should have had "full catch" (later "call/cc")
but we felt it addressed issues our community was not asking us to solve,
and that in many cases had more easy/efficient (if less elegant) solutions
using other mechanisms. For example, co-routining and multi-tasking
may be possible to express with call/cc, but the MP package was more in the
style of how our voting community preferred to address this problem.
Further, some of us [ok, mostly just me, though I have won over others
since then] worried that the interaction between call/cc and unwind-protect
was ill-specified and taht a well-specified unwind-protect was more
important than a well-specified call/cc. Scheme has sacrificed a
well-specified unwind-protect in order to get call/cc.
I am unashamed of the fact that CL has made the design trade-offs. To
become fully FP would have (a) been redundant [Scheme already does the FP
allegiance better on behalf of the greater Lisp/Scheme community] and
(b) pissed off those in our community who did not want to program in
FP style. So we still wouldn't have satisfied Schemers, but probably
would have lost CLers in the process.
CL does provide a great deal of the functional style for those who want
that style for other than religious reasons. For those who will be satisfied
only by religious adherance, it will necessarily fall short because the
langauge was not designed by religious purists.
Kent M Pitman wrote:
> I am unashamed of the fact that CL has made the design trade-offs. To
> become fully FP would have (a) been redundant [Scheme already does the FP
> allegiance better on behalf of the greater Lisp/Scheme community] and
> (b) pissed off those in our community who did not want to program in
> FP style.
Sorry Kent, but this is not how I experience Scheme. I came from
CommonLisp to Python and ended up at Scheme. I do not like Python and
hence I stick up with Scheme. For the first time I have written all my
Scheme programs (with the very good Scheme compiler Bigloo) in a brute
force way: loops, loops, loops and mor or less imperative. This is also
how I write my Scheme programs today, and if I find time I tune or
rewrite my Scheme programs in a functional style; this is more or less,
because I am anxious that I will forget principle things what I know
from Clean.
Regards,
S. Gonzi
Siegfried Gonzi <···············@kfunigraz.ac.at> wrote in message
> CommonLisp to Python and ended up at Scheme. I do not like Python and
What didn't you like about Python?
Mark Carter wrote:
> What didn't you like about Python?
I cannot tell you in detail, because I do not know why, but when time
passed on I became unsatisfied with Python. I have never programmed in
an object-oriented way in Python; nor I am able to read an
object-oriented Python program. I have some C++ knowledge but was never
able to grasp Python's way to do OOP (I am also not able to follow OOP
programming in Common Lisp).
So I used more or less a small subset of Python, but find programming in
Scheme easier and I am not sure but I believe for myself that programs
written in Scheme are easier to read than programs written in Python.
Okay, I would also fail to read a Scheme macro. I had more than 1500
lines of Python code, which I translated to Scheme in the following.
Translation was easy, because most of the time I could translate things
nearly "literally".
And to go on with my rants: I hate the intentation stuff and find Python
as bloated and complicated as lets say C++.
That is my story, but curiously I have adviced a technician here at my
university to use Python for some stuff, I was anxious to suggest Scheme
to him. I am a scientist and programming is a second task for me, so I
have never asked him whether he was/is contented with Python; but I know
from him that he has payed for a Python book.
Why the Python suggestion? I have no clue how deal with people who are
scared when they see parenthesis. I am not a teacher, so I will not turn
into this discussion with people. Life is too short, and I have no
problems, when people do not like parenthesis, they should use what they
want.
S. Gonzi
Paul Foley <·······@actrix.gen.nz> writes:
> On 17 Apr 2003 14:32:36 +0200, Nils Goesche wrote:
>
> > Nobody ever claimed that Common Lisp was a ``purely functional��
> > language. But any definition of ``functional language�� that
> > doesn't include Common Lisp and ML is ... probably more propaganda
> > than anything else.
>
> Why should it include CL? It might mention Lisp in a historical
> note, but to me calling something a "functional language" implies
> that the usual programming style is functional (or at least mostly
> functional), which is not how Lispers ordinarily write Lisp (unless
> they've been over-exposed to Scheme at some point, anyway). So I
> say no, Lisp is not "a functional language" (but not because it has
> SETQ!)
Well, I guess you could look at it that way, but then calling a
language functional is more like making a statement about a language's
users than about the language itself. Nothing forces you to write ML
code in a functional style, either, it just happens that most of ML's
users write functional code, more or less.
Most people, though, seem to think that calling a language functional
is making a statement about the language itself, I think.
Unfortunately, there is a tendency among some CS types to define
functional in such a way that it will enclose only their favorite
language and nothing else -- Haskellers will say ML isn't functional
because it isn't pure and lazy, MLlers will say that Lisp isn't
functional because it isn't statically typed (weird, I know, but there
are people who say that).
A definition that seems sensible to me would be something like: A
language is functional if it somehow contains the lambda calculus. If
you can take lambda calculus formulae and readily translate them into
working code. And you have to be a bit relaxed when using this
requirement; for instance, writing an Y-combinator in ML is very hard
because of the stupid type checker. So let's leave it open whether
the lambda calculus used is typed or not. Also, /some/ formulae will
be harder to translate if our language isn't lazy. Let's not get too
excited about that, either.
I think the result you'll get when using this definition comes pretty
close to what most people think are functional languages and which are
not. And CL just happens to functional, then :-)
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Nils Goesche <······@cartan.de> writes:
> Well, I guess you could look at it that way, but then calling a
> language functional is more like making a statement about a language's
> users than about the language itself. Nothing forces you to write ML
> code in a functional style, either, it just happens that most of ML's
> users write functional code, more or less.
Well, the issue isn't whether there are community members that are in this
or that camp, but whether the guiding control is held by those members.
The official style of CL is not stated explicitly but in practice as a
matter of history I think it's safe to loosely characterize it as
"multi-cultural". We made many decisions whose stated purpose was to
cater to various programming styles that are from time to time seen by
some as being at apparent war with each other. Our aim was, I
believe, to the extent I can characterize history in any kind of fair
way at all, to tolerate individual choice, but not to allow any
particular individual choice to dominate...
I would say that ML has a stronger desire to take a point of view, even
if it doesn't completely force things. It has both a stronger willingness
to accomodate FP and a weaker willingness to tolerate other paradigms,
_even if_ it is not rock solid in the FP camp.
> Most people, though, seem to think that calling a language functional
> is making a statement about the language itself, I think.
In ANSI CL, I added this term:
purports to conform v. makes a good-faith claim of conformance. This
term expresses intention to conform, regardless of whether the goal
of that intention is realized in practice. For example, language
implementations have been known to have bugs, and while an
implementation of this specification with bugs might not be a
conforming implementation, it can still purport to conform. This is
an important distinction in certain specific cases; e.g., see the
variable *features*.
A lot of the glossary is not about me making up terms, but me writing down
the fact of terms we all use. The fact is that if you "purport to have a
functional language", what I think you ar really saying is that you are
prepared to receive bug reports from people who claim that your language
is not functional enough.
As a public process with specific rules about speaking for the group,
no single person can speak for the designers of CL, so I will speak
only for myself:
I, as an individual participant was not prepared to received such bug
reports about the design of CL as might come if CL were advertised as
a functional language, and as such I do not advertise it as a functional
language. When I hear someone say this term like as if it matters to
them with any kind of political or religious zeal, I show them the door
to the Scheme community and say "knock yourself out getting what you want
over there". YMMV.
On 17 Apr 2003 16:27:53 +0200, Nils Goesche <······@cartan.de> wrote:
>A definition that seems sensible to me would be something like: A
>language is functional if it somehow contains the lambda calculus. If
>you can take lambda calculus formulae and readily translate them into
>working code.
That makes nearly every modern language functional.
>And you have to be a bit relaxed when using this
>requirement; for instance, writing an Y-combinator in ML is very hard
>because of the stupid type checker.
No it is easy.
In OCaml,
let rec fix f x=f (fix f) x;;
For an example,
let fact x=fix ( fun q->
(fun n->
if n<2 then 1
else n* (q (n-1)))) x;;
( Variant of the above technique, Y as a fixed point operator works in
SML and Haskell too. )
For a more traditional approach.
type 'a rf = RF of ( 'a rf -> 'a );;
let y f x=
let g (RF h) z=
f( h (RF h) ) z in
(g (RF g)) x;;
Of course the example above looks like:
let fact x= y ( fun q->
(fun n->
if n<2 then 1
else n* (q (n-1)))) x;;
When I did it this way the first time it was a bit difficult
getting the type right. But the reason was that I was new
to the OCaml typing system. It wasn't what the type should look
like, it was just getting the declaration right.
While not an expert, I should say this type of infinite cascading type
and data is typical of a class of ML programs. I believe the little
MLer has an example early on.
This should also be easy for a Lisper/Schemer to grasp as it just
extends on some of their ideas.
--------------------------------------------------
Thaddeus L. Olczyk, PhD
Think twice, code once.
Thaddeus L Olczyk <······@interaccess.com> writes:
> On 17 Apr 2003 16:27:53 +0200, Nils Goesche <······@cartan.de> wrote:
>
> >A definition that seems sensible to me would be something like: A
> >language is functional if it somehow contains the lambda calculus.
> >If you can take lambda calculus formulae and readily translate them
> >into working code.
> That makes nearly every modern language functional.
Certainly not Java or C# ;-) But even if that's true -- then so be it.
If it is true that modern languages tend to be functional, too, then
you could call that progress. Why should we change the definition of
``functional�� every year in order to keep the ratio of functional to
non-functional languages constant over time?
> >And you have to be a bit relaxed when using this requirement; for
> >instance, writing an Y-combinator in ML is very hard because of the
> >stupid type checker.
>
> No it is easy.
>
> In OCaml,
> let rec fix f x=f (fix f) x;;
That's cheating and you know it :-)
> For a more traditional approach.
> type 'a rf = RF of ( 'a rf -> 'a );;
>
> let y f x=
> let g (RF h) z=
> f( h (RF h) ) z in
> (g (RF g)) x;;
>
> Of course the example above looks like:
> let fact x= y ( fun q->
> (fun n->
> if n<2 then 1
> else n* (q (n-1)))) x;;
>
> When I did it this way the first time it was a bit difficult getting
> the type right.
I know: Been there done that ;-\ Took me some time. Certainly /much/
longer than simply translating the lambda calculus formula to Lisp, so
I refuse calling it easy, even if the ML code that finally works is
short.
> But the reason was that I was new to the OCaml typing system. It
> wasn't what the type should look like, it was just getting the
> declaration right.
If it's so easy, why did they even bother putting it into the ML FAQ?
> While not an expert, I should say this type of infinite cascading
> type and data is typical of a class of ML programs. I believe the
> little MLer has an example early on.
>
> This should also be easy for a Lisper/Schemer to grasp as it just
> extends on some of their ideas.
Sure, once you know how to do it, it seems easy and obvious. But that
is true about almost all problems.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
On 17 Apr 2003 17:53:15 +0200, Nils Goesche <······@cartan.de> wrote:
>Thaddeus L Olczyk <······@interaccess.com> writes:
>
>> On 17 Apr 2003 16:27:53 +0200, Nils Goesche <······@cartan.de> wrote:
>>
>> >A definition that seems sensible to me would be something like: A
>> >language is functional if it somehow contains the lambda calculus.
>> >If you can take lambda calculus formulae and readily translate them
>> >into working code.
>
>> That makes nearly every modern language functional.
>
>Certainly not Java or C# ;-)
Yes. Both contain lambda calculus. As does any language
which supports objects.
In ( a sort hand wavy way ),
class Lambda
{
public:
retval exec(arglist){...}
}
Java ( can't say I know enough about C# ) may lack some syntactic
sugar to make it pretty, but it's there.
>But even if that's true -- then so be it.
>If it is true that modern languages tend to be functional, too, then
>you could call that progress. Why should we change the definition of
>``functional�� every year in order to keep the ratio of functional to
>non-functional languages constant over time?
>
While it's true that in math and CS, many definitions evolve over
time ( ones that come to mind right now are function/procedure
[which were distinct, now considered the same thing], fiber bundles,
sheaves, topological space ... ), that's all just bullshit thrown out
to distract people from *your stupidity*.
That's because the definition that you have suggested is not some
formal definition appearing in seminal "Introduction to Functional
Programming" type books or papers. It's *your* definition, and it
sucks. Because it's your definition and not a formal one, there is
no suggestion that I am changing the definition over time. As I said,
it's simply a distraction to hide the fact that your definition
*sucks*.
As for your definition, it sucks because it fails to make any
distinction. Almost everyone would agree that languages like
Haskell, ML, Clean, Scheme and ( sometimes ) Lisp are functional.
And your definition includes those. But your definition would say that
languages like C, Eiffel and Smalltalk ( not to mention C++, Java and
C# ) are functional, which almost no one would agree with.
>> >And you have to be a bit relaxed when using this requirement; for
>> >instance, writing an Y-combinator in ML is very hard because of the
>> >stupid type checker.
>>
>> No it is easy.
>>
>> In OCaml,
>> let rec fix f x=f (fix f) x;;
>
>That's cheating and you know it :-)
>
No. It's not.
It's a standard definition of Y in a combinatorial approach
to computing.
>> For a more traditional approach.
>> type 'a rf = RF of ( 'a rf -> 'a );;
>>
>> let y f x=
>> let g (RF h) z=
>> f( h (RF h) ) z in
>> (g (RF g)) x;;
>>
>> Of course the example above looks like:
>> let fact x= y ( fun q->
>> (fun n->
>> if n<2 then 1
>> else n* (q (n-1)))) x;;
>>
>> When I did it this way the first time it was a bit difficult getting
>> the type right.
>
>I know: Been there done that ;-\ Took me some time.
What can I say. Some people are slower than others.
>Certainly /much/
>longer than simply translating the lambda calculus formula to Lisp, so
>I refuse calling it easy, even if the ML code that finally works is
>short.
And know we see why some people are slower.
I never even thought of "translating" the code.
I did what every one is taught in every math class.
I rederived it in ML. In the process I found it easy.
The only sticking point was that I did not understand
user defined types well enough to write HOFs. Once
I understood that it was trivial.
>
>> But the reason was that I was new to the OCaml typing system. It
>> wasn't what the type should look like, it was just getting the
>> declaration right.
>
>If it's so easy, why did they even bother putting it into the ML FAQ?
Because there are lazy people who don't write code from first
principles, or bother to learn enough about user defined types
to write HOFs ( the true FP practitioner doesn't just use HOFs
he writes them too ).
>
>> While not an expert, I should say this type of infinite cascading
>> type and data is typical of a class of ML programs. I believe the
>> little MLer has an example early on.
>>
>> This should also be easy for a Lisper/Schemer to grasp as it just
>> extends on some of their ideas.
>
>Sure, once you know how to do it, it seems easy and obvious. But that
>is true about almost all problems.
No. It's easy and obvious because I learned enough OCaml to make it
easy and obvious. These are aspects of the language which are
fundamental, and anyone taking a professional approach to programming
in ML should be familiar with it enough to understand how to write
HOF's. It's only hackers who have a hard time implementing Y in ML.
--------------------------------------------------
Thaddeus L. Olczyk, PhD
Think twice, code once.
Thaddeus L Olczyk <······@interaccess.com> writes:
> While it's true that in math and CS, many definitions evolve
> over time ( ones that come to mind right now are
> function/procedure [which were distinct, now considered the
> same thing], fiber bundles, sheaves, topological space ... ),
Actually, the resp. definitions of fiber bundles, sheaves and
topological spaces /haven't/ changed much over time. If they
have changed at all, once they were called by that names.
> that's all just bullshit thrown out to distract people from
> *your stupidity*.
Darn, I had hoped I'd get away with it one more time.
> Thaddeus L. Olczyk, PhD
I was somewhat hoping that now, having finally obtained your
degree, which is seemingly very important to you, you'd have
become a bit more relaxed. I was wrong.
Farewell,
--
Nils G�sche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xD26EF2A0
On 19 Apr 2003 00:33:57 +0200, Nils Goesche <···@cartan.de> wrote:
>Thaddeus L Olczyk <······@interaccess.com> writes:
>
>> While it's true that in math and CS, many definitions evolve
>> over time ( ones that come to mind right now are
>> function/procedure [which were distinct, now considered the
>> same thing], fiber bundles, sheaves, topological space ... ),
>
>Actually, the resp. definitions of fiber bundles, sheaves and
>topological spaces /haven't/ changed much over time. If they
>have changed at all, once they were called by that names.
>
When Gauss spoke of topological spaces they were more
like smooth manifolds ( smooth Hausdorff manifolds to be more
precise ). The definition changed over a period of time till
it settled on it's present definition mid 40's ( IIRC).
Steenrod discusses the problems of varying definitions
of fibre bundles in his book.
I'll skip sheaves since I don't remember the details.
>> that's all just bullshit thrown out to distract people from
>> *your stupidity*.
>
>Darn, I had hoped I'd get away with it one more time.
>
Don't you mean twice, as it's clear that this reply is
another attempt at distraction, totally ignoring the
issues.
>> Thaddeus L. Olczyk, PhD
>
>I was somewhat hoping that now, having finally obtained your
>degree,
Sorry to disillusion you, but I got my doctorate many years ago.
I stopped keeping track when it passed ten.
Perhaps you will learn from this mistake. Making unfounded
assumptions will often cause you to make dumb errors. Keep
this in mind when you start doing serious programming, as
it wil save you from a lot of errors in your code.
>which is seemingly very important to you,
Is it? I suppose so. A doctorate is not something just anyone
can accomplish. It takes a dedicated effort over a period of years,
something most people don't have the patience for.
Most of the time I really don't think about it. It's just something
I did in the past.
>you'd have
>become a bit more relaxed. I was wrong.
You seem to be wrong quite a bit of the time. Perhaps you would
not be wrong as much if you did not make unfounded assumptions.
--------------------------------------------------
Thaddeus L. Olczyk, PhD
Think twice, code once.
On 8353 day of my life Thaddeus L. Olczyk wrote:
>
> >> >And you have to be a bit relaxed when using this requirement; for
> >> >instance, writing an Y-combinator in ML is very hard because of the
> >> >stupid type checker.
> >> No it is easy.
> >> In OCaml,
> >> let rec fix f x=f (fix f) x;;
> >That's cheating and you know it :-)
> No. It's not.
> It's a standard definition of Y in a combinatorial approach
> to computing.
But 'let rec' does Y-combination behind scene. So, it is trick.
Try to implement Y-combinator without rec...
--
Ivan Boldyrev
PGP fp: 3640 E637 EE3D AA51 A59F 3306 A5BD D198 5609 8673 ID 56098673
Outlook has performed an illegal operation and will be shut down.
If the problem persists, contact the program vendor.
On 17 Apr 2003 17:53:15 +0200, Nils Goesche <······@cartan.de> wrote:
>Thaddeus L Olczyk <······@interaccess.com> writes:
>
>> On 17 Apr 2003 16:27:53 +0200, Nils Goesche <······@cartan.de> wrote:
>>=20
>> >A definition that seems sensible to me would be something like: A
>> >language is functional if it somehow contains the lambda calculus.
>> >If you can take lambda calculus formulae and readily translate them
>> >into working code.
>
>> That makes nearly every modern language functional.
>
>Certainly not Java or C# ;-)=20
Yes. Both contain lambda calculus. As does any language
which supports objects.
In ( a sort hand wavy way ),
class Lambda
{
public:
retval exec(arglist){...}
}
Java ( can't say I know enough about C# ) may lack some syntactic
sugar to make it pretty, but it's there.
>But even if that's true -- then so be it.
>If it is true that modern languages tend to be functional, too, then
>you could call that progress. Why should we change the definition of
>``functional=B4=B4 every year in order to keep the ratio of functional t=
o
>non-functional languages constant over time?
>
While it's true that in math and CS, many definitions evolve over
time ( ones that come to mind right now are function/procedure
[which were distinct, now considered the same thing], fiber bundles,
sheaves, topological space ... ), that's all just bullshit thrown out
to distract people from *your stupidity*.
That's because the definition that you have suggested is not some
formal definition appearing in seminal "Introduction to Functional
Programming" type books or papers. It's *your* definition, and it
sucks. Because it's your definition and not a formal one, there is
no suggestion that I am changing the definition over time. As I said,
it's simply a distraction to hide the fact that your definition
*sucks*.
As for your definition, it sucks because it fails to make any
distinction. Almost everyone would agree that languages like
Haskell, ML, Clean, Scheme and ( sometimes ) Lisp are functional.
And your definition includes those. But your definition would say that
languages like C, Eiffel and Smalltalk ( not to mention C++, Java and
C# ) are functional, which almost no one would agree with.
>> >And you have to be a bit relaxed when using this requirement; for
>> >instance, writing an Y-combinator in ML is very hard because of the
>> >stupid type checker.
>>=20
>> No it is easy.
>>=20
>> In OCaml,=20
>> let rec fix f x=3Df (fix f) x;;
>
>That's cheating and you know it :-)
>
No. It's not.
It's a standard definition of Y in a combinatorial approach
to computing.
>> For a more traditional approach.
>> type 'a rf =3D RF of ( 'a rf -> 'a );;
>>=20
>> let y f x=3D=20
>> let g (RF h) z=3D
>> f( h (RF h) ) z in
>> (g (RF g)) x;;
>>=20
>> Of course the example above looks like:
>> let fact x=3D y ( fun q->
>> (fun n->=20
>> if n<2 then 1=20
>> else n* (q (n-1)))) x;;
>>=20
>> When I did it this way the first time it was a bit difficult getting
>> the type right.
>
>I know: Been there done that ;-\ Took me some time. =20
What can I say. Some people are slower than others.
>Certainly /much/
>longer than simply translating the lambda calculus formula to Lisp, so
>I refuse calling it easy, even if the ML code that finally works is
>short.
And know we see why some people are slower.
I never even thought of "translating" the code.
I did what every one is taught in every math class.
I rederived it in ML. In the process I found it easy.
The only sticking point was that I did not understand
user defined types well enough to write HOFs. Once
I understood that it was trivial.
>
>> But the reason was that I was new to the OCaml typing system. It
>> wasn't what the type should look like, it was just getting the
>> declaration right.
>
>If it's so easy, why did they even bother putting it into the ML FAQ?
Because there are lazy people who don't write code from first
principles, or bother to learn enough about user defined types
to write HOFs ( the true FP practitioner doesn't just use HOFs
he writes them too ).
>
>> While not an expert, I should say this type of infinite cascading
>> type and data is typical of a class of ML programs. I believe the
>> little MLer has an example early on.
>>=20
>> This should also be easy for a Lisper/Schemer to grasp as it just
>> extends on some of their ideas.
>
>Sure, once you know how to do it, it seems easy and obvious. But that
>is true about almost all problems.
No. It's easy and obvious because I learned enough OCaml to make it
easy and obvious. These are aspects of the language which are
fundamental, and anyone taking a professional approach to programming
in ML should be familiar with it enough to understand how to write
HOF's. It's only hackers who have a hard time implementing Y in ML.
--------------------------------------------------
Thaddeus L. Olczyk, PhD
Think twice, code once.
laotseu <······@removethis.free.fr> writes:
> Lispers friends, let's have you're opinion on that point : is Common
> Lisp a functionnal language ?
It depends on your definition of "functional programming language".
In the more general sense, any language with higher-order functions
and functions as a first-class type is a functional programming
language. In the strictest sense, the language has to be purely
applicative (or free of side effects). Common Lisp satisfies the
first definition, but not the second.
Florian Weimer wrote:
> laotseu <······@removethis.free.fr> writes:
>
>
>>Lispers friends, let's have you're opinion on that point : is Common
>>Lisp a functionnal language ?
>
>
> It depends on your definition of "functional programming language".
> In the more general sense, any language with higher-order functions
> and functions as a first-class type is a functional programming
> language.
Ok, the question coming from a 'Functional Python' point of view, the
'more general sense' is enough for me.
And for you all dear Lispers, thanks for your opinions on that point. I
know enough of lisp to know that it supports many paradigms and doesn't
enforce a pure, religious FP style.
I notice that nobody here claimed that you could not do functional
programming in Common Lisp.
> In the strictest sense, the language has to be purely
> applicative (or free of side effects). Common Lisp satisfies the
> first definition, but not the second.
Do you mean that it is *absolutely not possible* to write a whole
program in CL whithout any side effect ? Or that many features in the
language, that you can choose to use or not, are not side effect free ?
I might say that, in the first case, this does not prevent CL from being
(also) a functional language in the 'strictest sens'.
Laotseu
In article <················@removethis.free.fr>,
laotseu <······@removethis.free.fr> wrote:
> Florian Weimer wrote:
> > In the strictest sense, the language has to be purely
> > applicative (or free of side effects). Common Lisp satisfies the
> > first definition, but not the second.
>
> Do you mean that it is *absolutely not possible* to write a whole
> program in CL whithout any side effect ? Or that many features in the
> language, that you can choose to use or not, are not side effect free ?
It's the second. In a strictest-sense functional language, it is
impossible to write a whole program that *does* have side effects.
This leads to the usual amusements such as passing the universe to a
function that then returns a similar-but-not-identical universe with one
property differing...
paul
Paul Wallich wrote:
>
> It's the second. In a strictest-sense functional language, it is
> impossible to write a whole program that *does* have side effects.
It would be easy to write such a program though. Without any sideeffects
the preconditions reduces to the postconditions and so the whole program
disappears. :) Now that would be very nice and simple, it might even be
the silver bullet.
--
Thomas.
"How long is six months? Ten years?"
- Denis Johnson, Fiskadoro