Is C a functional programming language?
Marcel K Haesok
Is C a functional programming language?
I know that C can be 'algorithm'-intensive.
Can VB as algorithm-intensive as C?
Marcel
Peter Holland
LISP is a functional language. C++ can be a functional language through
the use of anonymous objects and Functors.
VB isn't even a language... it's grunts and whistles :).
- Pete
Sunil Mishra
> This is a multi-part message in MIME format.
> --------------ACED77745AD6B26E80877BF2
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> I think you can write functional prgrams in C, it's just really easy not to
> ;)
I don't think so. The idea of a functional language is one that treats
functions as first class objects. In other words, you should be able to at
the very least create and destroy functions during runtime. C does not
allow that. It allows for a crude form of function application, that is
all. It does not even allow a program to query for information about a
function, let alone do anything more sophisticated. (But then I don't think
ML allows for queries about functions either, does it?)
Sunil
Sunil Mishra
> C is primarily an imperative language, not a functional language.
> LISP is a functional language. C++ can be a functional language through
> the use of anonymous objects and Functors.
> VB isn't even a language... it's grunts and whistles :).
Well, LISP is not strictly functional either, though I've heard it started
out that way :-) It allows for a variety of programming styles, which is
really cool. The great thing about functional programming, IMHO, is that it
is very expressive. Which also makes it a little harder to learn. And if I
were to go out on a limb, that is probably as important a factor in the
functional emphasis of lisp as any historical inertia.
Sunil
Martin Rodgers
says...
> Is C a functional programming language?
This question has been, or is being, answered in the "Functional vs
procedural" thread in comp.lang.functional. Functional programming means
rather more than just using a language with functions, just as OOP is
rather more than just using a language with objects.
Here's the comp.lang.functional FAQ:
http://www.cs.nott.ac.uk/Department/Staff/gmh/faq.html
--
Remove insect from address to email me | You can never browse enough
will write code that writes code that writes code for food
http://www.wildcard.demon.co.uk/dev/meta.html
Gareth McCaughan
> C is not OO.
> Is C a functional programming language?
Not in any very useful sense. (It's probably more or less exactly
as functional as it is OO: that is, you can sort of do functional
programming in C, and you can sort of do OO programming in C, but
neither is a very pleasant experience.)
FP is characterised by
- the ability to treat functions as first-class objects
(C does let you pass function pointers around, but it doesn't
have closures or any other way of defining new functions on
the fly; so you have to simulate closures by hand using
structures or something. Painful.)
- programming in a side-effect-free style
(you can sort of do this in C, but it's not much fun.)
- the idea that everything is an expression (the trouble
with "statements" like C's |for|, |switch| etc is that
there are restrictions on where you can put them, which
makes them hard to use neatly in macros and inelegant
for several purposes.)
- a preference for expressing control flow in terms of
function composition rather than explicit sequencing
(this is made much harder in C by its lack of garbage
collection; it means you can't create and pass around
large objects without a lot of awkward bookkeeping.)
As others have pointed out, Lisp isn't only a functional language.
You can do functional programming in Lisp if you want to, just as
you can do OO programming or traditional procedural programming.
This flexibility is one of the language's major strengths.
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
gj...@dpmms.cam.ac.uk Cambridge University, England.
Tim Bradshaw
> C is not OO.
> Is C a functional programming language?
It's really hard to regard a language without anonymous functions as
functional I think.
--tim (who likes C)
Paul Gover
>
> C is not OO.
> Is C a functional programming language?
When I last looked at functional programming languages, several years
ago, there were as many definitions of "functional programming" as
there were FP languages - in a 1-1 relationship, of course. But none
of them used a definition which would include C. FP languages let you
treat functions in the same way as a procedural language lets you
treat data, and an OO language lets you treat objects. In particular,
you get the concepts of assigning functions or function expressions to
variables or passing them as parameters. For example, an FP language
might have an operator ".", where foo2 = foo.bah is the function
produced by first applying foo, then applying bah to foo's result (or
vice-versa).
IMHO C is a dysfunctional programming language, but not as
dysfunctional as C++ :-)
Paul Gover
IBM Warwick Development Group
Opinions my own, not IBM's
Mike Smith
>C is not OO.
*Any* language (even COBOL) can be used to develop object-oriented systems,
if you know what you're doing. Special proof in the case of C: The first
C++ "compilers" were actually preprocessors that output C code, which was
then compiled into the target executable.
>Is C a functional programming language?
It may look a little like one, while you're learning it, but it's really a
procedural language, a la Pascal. A better example of a functional language
would be LISP.
>I know that C can be 'algorithm'-intensive.
>Can VB as algorithm-intensive as C?
This is kind of like the OO question above. Any programming language can be
used to implement an algorithm if you know what you're doing.
--
Mike Smith. No, the other one.
Erik Naggum
| C is primarily an imperative language, not a functional language.
| LISP is a functional language.
this is really cross-posted way to widely to ever be useful, but I'll
answer the "LISP" part, anyway.
there is no _one_ language called "LISP". nowadays, is makes more sense
to talk about Common Lisp or Scheme. referring to Common Lisp as the
"LISP" your father knew is like calling C++ or Ada "Algol". referring to
Scheme as "LISP" is like calling C "Algol".
Common Lisp is object-oriented, functional, and imperative. it is what
you want it to be. Scheme is functional and imperative. you can make it
be whatever you want it to be.
IMNSHO, _programmers_ are object-oriented, functional, or imperative. if
they love pain and suffering, they will stick with a language that makes
their work tedious and boring and hard to get right, and this includes a
surprisingly large fraction of them, but otherwise they tend to choose
languages that support the way they already think.
however, one clue is important: if the language does not offer automatic
memory management ("garbage collection"), it takes extraordinary effort
to make it functional or object-oriented, and most attempts have failed.
in other words: if you're really into this, you can write a functional
environment in C, but without such an environment, C is imperative.
#:Erik
Marcel K Haesok
also the siginficance of garbage collection. Merci. marcel
Gareth McCaughan wrote:
> Marcel Haesok wrote:
>
> > C is not OO.
> > Is C a functional programming language?
>
Espen Vestre
> Common Lisp is object-oriented, functional, and imperative. it is what
> you want it to be.
there is only one thing I want Common Lisp to be which is still isn't:
"logical". I'm still waiting for a really useful implementation
of Prolog in Common Lisp...
--
espen
Darren Webb
order of computation isn't imperative. LISP, Miranda, Nesl, Scheme etc. do
this, usually by manipulation of sequences or steams. Streams are conceptually
of infinite length, so modelling real-time systems (remember, there is no state)
is quite simple. Functional languages are quite useful for modelling and
prototyping, but have been used sparingly in commercial systems (I believe some
European telephone exchanges are implemented using function languages).
Imperative langauges impose an order on computation - you have to be very
careful with the order of computation. Executing instructions concurrently is
dangerous because, in most cases, order is important because of state. Sorry,
but C, C++, etc. are not functional because they impose such order.
Technically, imperative programs could be written in such a way so they appear
to be functional, but this is not in the essence of a functional language so
let's
not pretend this is possible.
VB is crap, let's not pretend it's anything but an Australian brand of beer.
Thanks
Darren
Nick Ambrose wrote:
>
> I think you can write functional prgrams in C, it's just really easy not to
> ;)
> a functional language is usually one that imposes that requirement (which
> C++ certainly doesn't)
> like ML/LISP/Miranda etc.
>
> Nick
>
> Peter Holland wrote:
>
> > C is primarily an imperative language, not a functional language.
> > LISP is a functional language. C++ can be a functional language through
> > the use of anonymous objects and Functors.
> > VB isn't even a language... it's grunts and whistles :).
> >
> > - Pete
> >
> > Marcel K Haesok wrote:
> > >
> > > C is not OO.
> > > Is C a functional programming language?
> > > I know that C can be 'algorithm'-intensive.
> > > Can VB as algorithm-intensive as C?
> > >
> > > Marcel
--
Darren Webb Department of Computer Science,
Research Student The University of Adelaide
South Australia 5005
dar...@cs.adelaide.edu.au Tel: +61 8 8303 6170
http://www.cs.adelaide.edu.au/~darren Fax: +61 8 8303 4366
Erik Naggum
| A functional language is generally characterised by its lack of state, so the
| order of computation isn't imperative. LISP, Miranda, Nesl, Scheme etc. do
| this, usually by manipulation of sequences or steams.
sigh. both Lisp and Scheme are not functional by this definition. Lisp
objects have state, and they can be destructively modified if you so want.
BTW, all object-oriented languages have objects with state as an inherent
property of their design.
#:Erik, who wonders how people who don't know Lisp "know" so much about it
Johan Kullstam
> A functional language is generally characterised by its lack of
> state, so the order of computation isn't imperative. LISP, Miranda,
> Nesl, Scheme etc. do this, usually by manipulation of sequences or
> steams. Streams are conceptually of infinite length, so modelling
> real-time systems (remember, there is no state) is quite simple.
most real-time systems have state. i am doing most of my work in the
control field. state-space (aka markov) representation is very
common. transfer functions are also common. even though the stream
is of infinite length, history *is* important.
> Functional languages are quite useful for modelling and prototyping,
> but have been used sparingly in commercial systems (I believe some
> European telephone exchanges are implemented using function
> languages).
> Imperative langauges impose an order on computation - you have to be
> very careful with the order of computation. Executing instructions
> concurrently is dangerous because, in most cases, order is important
> because of state. Sorry, but C, C++, etc. are not functional
> because they impose such order.
all languages impose an order on computation. e.g., in lisp (foo (bar
x)) is not necessarily the same as (bar (foo x)).
in C you might do
y = bar(x);
z = foo(y);
i think the distinction is that in a functional mode of thinking you
reach for more functions and in the imperitive style, you introduce
more variables to hold intermediate values along the way.
*both* helper functions *and* intermediate values are valid ways to
simplify a program. imperitive (using intermediate values like y
above) isn't *wrong*, it's forcing everything into an imperitive mold
that is a hindrance to your programming effort.
C makes creating helper functions difficult. you can do some
functional type constructions, but it is relatively painful.
in lisp it is easy (lambda, flet, labels &c). lisp handles functions
as easily as it does regular variables. this may be what makes
something a functional language.
notice that you can still introduce variables setq your way through
life in lisp too. lisp can be just as imperitive as C.
--
johan kullstam
Barry Margolin
Johan Kullstam <kull...@ne.mediaone.net> wrote:
>all languages impose an order on computation. e.g., in lisp (foo (bar
>x)) is not necessarily the same as (bar (foo x)).
But in a Lisp with lazy evaluation (which is the quality that he was
ascribing to functional languages, but I think most people consider
indpendent), (foo (bar x)) doesn't specify the order in which FOO and BAR
run. I think that's what he meant by not imposing order.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, 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.
Barry Margolin
Espen Vestre <e...@nextel.no> wrote:
>there is only one thing I want Common Lisp to be which is still isn't:
>"logical". I'm still waiting for a really useful implementation
>of Prolog in Common Lisp...
Isn't POPLOG a merger of Lisp and logic programming?
Travis Griggs
objects and messaging down to it's very core.
Would someone mind telling me why this is cross posted to <comp.lang.smalltalk>?
--
Travis Griggs (a.k.a. Lord of the Fries)
Key Technology
tgr...@keyww.com
Member, Fraven Skreiggs Software Collective
- C for Sinking
- Java for Drinking
- Smalltalk for Thinking
...and Power to the Penguin!
jedi
Hey guys!!!
Change a newsgroup!
Filter the newsgroups list you are posting to!
This is PB terain here!
You are abusing bandwidth with your typing empty nothing!
Do that somewhere else!
Go away!
Shoo!!!
:~@
Gareth McCaughan wrote in message <86lngvk...@g.pet.cam.ac.uk>...
>Marcel Haesok wrote:
>
>> C is not OO.
>> Is C a functional programming language?
>
Lieven Marchand
> In article <w63e317...@wallace.nextel.no>,
> Espen Vestre <e...@nextel.no> wrote:
> >there is only one thing I want Common Lisp to be which is still isn't:
> >"logical". I'm still waiting for a really useful implementation
> >of Prolog in Common Lisp...
>
> Isn't POPLOG a merger of Lisp and logic programming?
>
POPLOG is a system based on Pop-11, an interesting LISP like language
with implementations of Common Lisp and Prolog that are integrated
very tightly with respect to inter language function calling and
gargage collection.
--
Lieven Marchand
Don Geddis
> there is only one thing I want Common Lisp to be which is still isn't:
> "logical". I'm still waiting for a really useful implementation
> of Prolog in Common Lisp...
This question would be more appropriate for an AI group than a Lisp group.
In particular, the FAQ for comp.ai has a long list of theorem proving systems.
For example, you can take a look at the "Software" section at the bottom of
http://logic.stanford.edu/
which offers the "Epilog inference package", a commercial version of a
Prolog-like system (but better than Prolog!) written in Lisp.
Or, if you demand Lisp source code, you could use my own somewhat silly "DTP":
http://logic.stanford.edu/software/dtp/
It's a research system that I implemented for my thesis (so it isn't
particularly efficient), but it does real model elimination (= Prolog without
semantic bugs), it's free, and you get Common Lisp source code.
Plus, there are tons more offerings you can find in the comp.ai FAQ.
-- Don
--
Don Geddis ged...@tesserae.com
Tesserae Information Systems, Inc. http://tesserae.com
275 Shoreline Drive, Suite 505 (650) 508-7893
Redwood Shores, CA 94065 (650) 508-7891 [fax]
Tim Bradshaw
> Darren Webb <dar...@cs.adelaide.edu.au> writes:
>
> > A functional language is generally characterised by its lack of
> > state, so the order of computation isn't imperative. LISP, Miranda,
> > Nesl, Scheme etc. do this, usually by manipulation of sequences or
> > steams. Streams are conceptually of infinite length, so modelling
> > real-time systems (remember, there is no state) is quite simple.
>
> most real-time systems have state. i am doing most of my work in the
> control field. state-space (aka markov) representation is very
> common. transfer functions are also common. even though the stream
> is of infinite length, history *is* important.
However, you can represent state in systems which` have no state'!
Have a look at the wonderful bank-account example in SICP[1] to see this.
In this example they represent a bank-account -- a fine example of a system
which really needs to have state -- in a purely functional way. It's a
wonderful example.
--tim
[1] SICP = Structure & Interpretation of COmputer Programs by
Abelson & Sussman.
Sunil Mishra
I remember that example, and for the most part it does indeed rely on using
functions that manipulate a lexical environment. I thought that was the
neatest trick ever when I first came across it! But I digress... Weren't
you required to use destructive operators to set the values of variables in
the enclosed environment? That to me would clearly violate the functional
programming paradigm of the return value being dependent entirely on the
inputs. Perhaps we're using different definitions of functional? :-)
Sunil
Marcel K Haesok
I am really taking to heart your expert knowledge about lisp, Miranda etc, those
functinal languages. But how I would love to hear from such a conociente as to 'WHY'
VB is so bad...(although I can guess that you don't seem to want to even waste your
breaths about the matter...)
THanks Marcel.
Ps: Incidentally, I am no Australian, but why brush the tar on Austrailia?
Darren Webb wrote:
> A functional language is generally characterised by its lack of state, so the
> order of computation isn't imperative. LISP, Miranda, Nesl, Scheme etc. do
> this, usually by manipulation of sequences or steams. Streams are conceptually
> of infinite length, so modelling real-time systems (remember, there is no state)
> is quite simple. Functional languages are quite useful for modelling and
> prototyping, but have been used sparingly in commercial systems (I believe some
> European telephone exchanges are implemented using function languages).
>
> Imperative langauges impose an order on computation - you have to be very
> careful with the order of computation. Executing instructions concurrently is
> dangerous because, in most cases, order is important because of state. Sorry,
> but C, C++, etc. are not functional because they impose such order.
>
> Technically, imperative programs could be written in such a way so they appear
> to be functional, but this is not in the essence of a functional language so
> let's
> not pretend this is possible.
>
> VB is crap, let's not pretend it's anything but an Australian brand of beer.
>
> Thanks
> Darren
>
> Nick Ambrose wrote:
> >
> > I think you can write functional prgrams in C, it's just really easy not to
> > ;)
> > a functional language is usually one that imposes that requirement (which
> > C++ certainly doesn't)
> > like ML/LISP/Miranda etc.
> >
> > Nick
> >
> > Peter Holland wrote:
> >
> > > C is primarily an imperative language, not a functional language.
> > > LISP is a functional language. C++ can be a functional language through
> > > the use of anonymous objects and Functors.
> > > VB isn't even a language... it's grunts and whistles :).
> > >
> > > - Pete
> > >
> > > Marcel K Haesok wrote:
> > > >
> > > > C is not OO.
> > > > Is C a functional programming language?
Marcel K Haesok
I did it intentionally, in order to solicit opinions from all walks of
programmers. This is because I am a middleaged 'upstart' programmer, passionate and
in a hurry to get some objective perspective about computing laguages.
Marcel K Haesok
becomming' the language of choice among Computing intellectuals... Marcel
Johan Kullstam wrote:
> Darren Webb <dar...@cs.adelaide.edu.au> writes:
>
> > A functional language is generally characterised by its lack of
> > state, so the order of computation isn't imperative. LISP, Miranda,
> > Nesl, Scheme etc. do this, usually by manipulation of sequences or
> > steams. Streams are conceptually of infinite length, so modelling
> > real-time systems (remember, there is no state) is quite simple.
>
> most real-time systems have state. i am doing most of my work in the
> control field. state-space (aka markov) representation is very
> common. transfer functions are also common. even though the stream
> is of infinite length, history *is* important.
>
> > Functional languages are quite useful for modelling and prototyping,
> > but have been used sparingly in commercial systems (I believe some
> > European telephone exchanges are implemented using function
> > languages).
>
> > Imperative langauges impose an order on computation - you have to be
> > very careful with the order of computation. Executing instructions
> > concurrently is dangerous because, in most cases, order is important
> > because of state. Sorry, but C, C++, etc. are not functional
> > because they impose such order.
>
> all languages impose an order on computation. e.g., in lisp (foo (bar
> x)) is not necessarily the same as (bar (foo x)).
>
Christopher R. Barry
> Darren Webb wrote:
[...]
> > VB is crap, let's not pretend it's anything but an Australian brand
> > of beer.
> Dear Daren,
> I am really taking to heart your expert knowledge about lisp,
> Miranda etc, those functinal languages. But how I would love to hear
> from such a conociente as to 'WHY' VB is so bad...(although I can
> guess that you don't seem to want to even waste your breaths about the
> matter...)
[...]
I thought numerous posters already did a sufficient job of enumerating
over VB's strengths and weaknesses (Darren didn't specifically give
you an explaination, but others did). Since the good and bad of VB was
already so thoroughly covered in this thread, yet you continue to
cross-post asking questions about it, could you be wanting us to make
the decision of whether to use VB or not for you?
Ordinarily I would say that we couldn't make that decision for you -
that sometimes in the road of life you encounter forks in your path
that only you can choose the direction to take.
But what the hell, I'll decide for you. Go for it. Use Visual Basic. I
think you will particularely appreciate its features and functionality
and what it does best. Contrary to what you may have heard before, VB
is not *evil*. Usage of it is not morally akin to Kicking Puppies [TM]
and other such carnal atrocities.
So go to Barnes and Noble or Amazon and grab one of these "VB for
Dummies" books and let your wonderful journey into the ways of quick
and painless Windows programming begin. And never forget - it's not
the destination that counts, but the journey. ;-)
If you ever start to feel that VB has become too painful or inadequate
for your purposes, then go ahead and download a free Lisp and give
that a shot.
Christopher
Tim Bradshaw
> I remember that example, and for the most part it does indeed rely on using
> functions that manipulate a lexical environment. I thought that was the
> neatest trick ever when I first came across it! But I digress... Weren't
> you required to use destructive operators to set the values of variables in
> the enclosed environment? That to me would clearly violate the functional
> programming paradigm of the return value being dependent entirely on the
> inputs. Perhaps we're using different definitions of functional? :-)
>
No, it doesn't do that. It works using infinite, lazily-evaluated, streams:
something like one stream to represent transactions and one to represent
the account balance. The program was a function which mapped from
one stream to the other.
--tim
Mark William Hopkins
A single-threaded language could be considered functional in the following
sense:
Corresponding to every statement (or sequence or control flow
structure) S is a lambda "operator" [S] such that for any
expression E
[S](E) is the value of E after applying S
Operator, here, means syntatic operator (roughly: macro). Example: for
a simple variable x, the assignment x = E corresponds to the operator
( lambda x. ( ... ) ) E
and the result of applying this operator on an experssion F would be
(lambda x. F) E
And, of course, "lambda x", itself, is a lambda operator -- the
archetypical one.
A multi-threaded language and operators even in single-threaded languages
that imply the use or involvement of concurrency (including, particularly,
I/O operations) fall outside the scope of this.
Concurrency is something that can only be defined once you have a model
of evaluation defined already. The reason for this is that you need to
define what "atomic operator" means first -- which is premised on a prior
definition of an evaluation mechanism. For example, with the lambda calculus
one may define "concurrency" with respect to the SECD machine (taking its
operations as "atomic"), or with respect to CAML or some other evaluation
mechanism.
Since, therefore, concurrency lies at the level of evaluation mechanism --
below the purely denotational level of the lambda calculus -- it falls
outside the scope of a purely functional language.
Therefore, the single-threaded part of C or any other imperative language
is functional (allowing for the use of infinite lambda expressions), but
the concurrency or multi-threaded part is not.
So, in the case of C for example, all of the <stdio.h> routines would be
excluded.