On 6 Feb, 23:10, gavino <·········@gmail.com> wrote:
> If one was forced to use onyl functional programming how would one
> cover the areas typically handled by oo programming?
You can take a fair shot at OOP in a pure FPL by modelling classes as
0-place closures. An instance of a class is created by applying that
closure which produces an association list of attribute-value pairs.
Inheritance is handled by a class calling on its superclasses when
instantiated.
Mark
modeling OOP using functional lang is easy. Just use global variables
for holding data. Suppose f is your function's name. And suppose you
want f to behave like a class, have methods, holds data, and be able
to create a instance of it.
In a nutshell, you do like this:
(defvar f-mydata ...) ; declare global var for class f's data
; define the class f
(setq f
(lambda ()
"class f does this and that ..."
(setq mydata1 ...) ; inner data ()
(setq mydata1 ...) ; inner data ()
...
(setq method1 (lambda ...)) ; inner function (method)
(setq method2 (lambda ...)) ; inner function (method)
...
)
)
Now, to create a object out of it, like this:
(setq g f) ; now g is a instance of f
To call methdos in f, do like this:
(g method1 arg1 arg2 ...)
--------------------------
The above assuming a non-pure functional lang, that is, the lang
allows you to set a var many times. Am not sure how OOP'd be modeled
in Haskell.
For a few thousands words article explaining this in detail, see:
• What are OOP's Jargons and Complexities
http://xahlee.org/Periodic_dosage_dir/t2/oop.html
Xah
···@xahlee.org
∑ http://xahlee.org/
☄
On Feb 6, 3:26 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
> On 6 Feb, 23:10, gavino <·········@gmail.com> wrote:
>
> > If one was forced to use onyl functional programming how would one
> > cover the areas typically handled by oo programming?
>
> You can take a fair shot at OOP in a pure FPL by modelling classes as
> 0-place closures. An instance of a class is created by applying that
> closure which produces an association list of attribute-value pairs.
> Inheritance is handled by a class calling on its superclasses when
> instantiated.
>
> Mark
On 7 Feb, 01:36, Xah Lee <····@xahlee.org> wrote:
> modeling OOP using functional lang is easy. Just use global variables
> for holding data. Suppose f is your function's name. And suppose you
> want f to behave like a class, have methods, holds data, and be able
> to create a instance of it.
>
> In a nutshell, you do like this:
>
> (defvar f-mydata ...) ; declare global var for class f's data
>
> ; define the class f
> (setq f
> (lambda ()
> "class f does this and that ..."
>
> (setq mydata1 ...) ; inner data ()
> (setq mydata1 ...) ; inner data ()
> ...
>
> (setq method1 (lambda ...)) ; inner function (method)
>
> (setq method2 (lambda ...)) ; inner function (method)
>
> ...
> )
> )
>
> Now, to create a object out of it, like this:
>
> (setq g f) ; now g is a instance of f
>
> To call methdos in f, do like this:
>
> (g method1 arg1 arg2 ...)
>
> --------------------------
> The above assuming a non-pure functional lang, that is, the lang
> allows you to set a var many times. Am not sure how OOP'd be modeled
> in Haskell.
>
> For a few thousands words article explaining this in detail, see:
>
> • What are OOP's Jargons and Complexities
> http://xahlee.org/Periodic_dosage_dir/t2/oop.html
>
> Xah
> ····@xahlee.org
> ∑http://xahlee.org/
>
> ☄
>
> On Feb 6, 3:26 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
>
>
>
> > On 6 Feb, 23:10, gavino <·········@gmail.com> wrote:
>
> > > If one was forced to use onyl functional programming how would one
> > > cover the areas typically handled by oo programming?
>
> > You can take a fair shot at OOP in a pure FPL by modelling classes as
> > 0-place closures. An instance of a class is created by applying that
> > closure which produces an association list of attribute-value pairs.
> > Inheritance is handled by a class calling on its superclasses when
> > instantiated.
>
> > Mark- Hide quoted text -
>
> - Show quoted text -
Yes; thats something like the way I would do it.
Mark
On Feb 6, 5:36 pm, Xah Lee <····@xahlee.org> wrote:
> modeling OOP using functional lang is easy. Just use global variables
> for holding data. Suppose f is your function's name. And suppose you
> want f to behave like a class, have methods, holds data, and be able
> to create a instance of it.
>
> In a nutshell, you do like this:
>
> (defvar f-mydata ...) ; declare global var for class f's data
>
> ; define the class f
> (setq f
> (lambda ()
> "class f does this and that ..."
>
> (setq mydata1 ...) ; inner data ()
> (setq mydata1 ...) ; inner data ()
> ...
>
> (setq method1 (lambda ...)) ; inner function (method)
>
> (setq method2 (lambda ...)) ; inner function (method)
>
> ...
> )
> )
>
> Now, to create a object out of it, like this:
>
> (setq g f) ; now g is a instance of f
>
> To call methdos in f, do like this:
>
> (g method1 arg1 arg2 ...)
>
> --------------------------
> The above assuming a non-pure functional lang, that is, the lang
> allows you to set a var many times. Am not sure how OOP'd be modeled
> in Haskell.
>
> For a few thousands words article explaining this in detail, see:
>
> • What are OOP's Jargons and Complexities
> http://xahlee.org/Periodic_dosage_dir/t2/oop.html
>
> Xah
> ····@xahlee.org
> ∑http://xahlee.org/
>
> ☄
>
> On Feb 6, 3:26 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > On 6 Feb, 23:10, gavino <·········@gmail.com> wrote:
>
> > > If one was forced to use onyl functional programming how would one
> > > cover the areas typically handled by oo programming?
>
> > You can take a fair shot at OOP in a pure FPL by modelling classes as
> > 0-place closures. An instance of a class is created by applying that
> > closure which produces an association list of attribute-value pairs.
> > Inheritance is handled by a class calling on its superclasses when
> > instantiated.
>
> > Mark
could you build a object oriented application server from that?
On Thu, 7 Feb 2008 13:59:30 -0800 (PST), gavino <·········@gmail.com>
wrote:
>On Feb 6, 5:36 pm, Xah Lee <····@xahlee.org> wrote:
>> modeling OOP using functional lang is easy. Just use global variables
>> for holding data. Suppose f is your function's name. And suppose you
>> want f to behave like a class, have methods, holds data, and be able
>> to create a instance of it.
>>
>> In a nutshell, you do like this:
>>
>> (defvar f-mydata ...) ; declare global var for class f's data
>>
>> ; define the class f
>> (setq f
>> (lambda ()
>> "class f does this and that ..."
>>
>> (setq mydata1 ...) ; inner data ()
>> (setq mydata1 ...) ; inner data ()
>> ...
>>
>> (setq method1 (lambda ...)) ; inner function (method)
>>
>> (setq method2 (lambda ...)) ; inner function (method)
>>
>> ...
>> )
>> )
>>
>> Now, to create a object out of it, like this:
>>
>> (setq g f) ; now g is a instance of f
>>
>> To call methdos in f, do like this:
>>
>> (g method1 arg1 arg2 ...)
>>
>> --------------------------
>> The above assuming a non-pure functional lang, that is, the lang
>> allows you to set a var many times. Am not sure how OOP'd be modeled
>> in Haskell.
>>
>> For a few thousands words article explaining this in detail, see:
>>
>> � What are OOP's Jargons and Complexities
>> http://xahlee.org/Periodic_dosage_dir/t2/oop.html
>>
>> Xah
>> ····@xahlee.org
>> ?http://xahlee.org/
>>
>> ?
>>
>> On Feb 6, 3:26 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
>>
>> > On 6 Feb, 23:10, gavino <·········@gmail.com> wrote:
>>
>> > > If one was forced to use onyl functional programming how would one
>> > > cover the areas typically handled by oo programming?
>>
>> > You can take a fair shot at OOP in a pure FPL by modelling classes as
>> > 0-place closures. An instance of a class is created by applying that
>> > closure which produces an association list of attribute-value pairs.
>> > Inheritance is handled by a class calling on its superclasses when
>> > instantiated.
>>
>> > Mark
>
>could you build a object oriented application server from that?
Why don't you try and let us know.
--
for email reply remove "/" from address
From: Joost Diepenmaat
Subject: Re: How does functional programming attack the object oriented programming area?
Date:
Message-ID: <87lk5xismu.fsf@zeekat.nl>
gavino <·········@gmail.com> writes:
> If one was forced to use onyl functional programming how would one
> cover the areas typically handled by oo programming?
By copying. Do you have anything specific in mind?
Joost.
From: Pascal Bourguignon
Subject: Re: How does functional programming attack the object oriented programming area?
Date:
Message-ID: <87ejbppnpg.fsf@thalassa.informatimago.com>
gavino <·········@gmail.com> writes:
^^^^^^^^^
> If one was forced to use onyl functional programming how would one
> cover the areas typically handled by oo programming?
This is not funny. Just drop it.
--
__Pascal Bourguignon__ http://www.informatimago.com/
This universe shipped by weight, not volume. Some expansion may have
occurred during shipment.
On Feb 6, 6:10 pm, gavino <·········@gmail.com> wrote:
> If one was forced to use onyl functional programming how would one
> cover the areas typically handled by oo programming?
I read an interesting post about generalized folds on recursive types
recently. One exercise covered is implementing `lists' as closures. A
fun read, and not too long.
http://sigfpe.blogspot.com/2008/02/purely-functional-recursive-types-in.html
//J
From: Pascal Costanza
Subject: Re: How does functional programming attack the object oriented programming area?
Date:
Message-ID: <60vrcsF1sqok4U1@mid.individual.net>
gavino wrote:
> If one was forced to use onyl functional programming how would one
> cover the areas typically handled by oo programming?
http://mumble.net/~jar/pubs/oopis.ps
http://www.cs.aau.dk/~normark/scheme-oop/scheme-oop.ps
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Feb 6, 11:47 pm, Pascal Costanza <····@p-cos.net> wrote:
> gavino wrote:
> > If one was forced to use onyl functional programming how would one
> > cover the areas typically handled by oo programming?
>
> http://mumble.net/~jar/pubs/oopis.pshttp://www.cs.aau.dk/~normark/scheme-oop/scheme-oop.ps
>
> Pascal
>
> --
> 1st European Lisp Symposium (ELS'08)http://prog.vub.ac.be/~pcostanza/els08/
>
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/
wow
scheme really kicks ass
On Feb 7, 9:46 pm, gavino <·········@gmail.com> wrote:
>
> wow
> scheme really kicks ass
Yeah, Scheme's designed to kick ass easily, since you'll need to do it
often.
Now, Common Lisp has most of the ass-kickin' built in, allowing you to
behave more socially.
On Feb 6, 3:10 pm, gavino <·········@gmail.com> wrote:
> If one was forced to use onyl functional programming how would one
> cover the areas typically handled by oo programming?
Hi Gavino,
One way would be to use object-oriented functional programming:
immutable objects only. No mutator methods, just accessors and
constructors. Functional and OO programming are not mutually exclusive
opposites; object-orientation doesn't imply the use of imperative
programming.
You can simulate an object changing state by constructing another one
like it, but with different contents analogous to what the state
change would be. Constructors (like the CONS function in Lisp) are
functional. Object accessors (like CAR and CDR in Lisp) are also
functional.
OO programming was developed to support simulations, and that makes a
good example.
A simulation under functional programming, might look like the
repeated application of a filter function ``next-state'' to a dynamic
set of objects representing the simulated universe. This next-state,
applied to the universe U at time N would return a new database
representing the universe at time N+1. The new database would contain
some old objects (representing things that didn't change state) as
well as some new ones.
Imagine how much easier debugging might be if you can hang on to the
entire old version of the full state of the simulation and see what
differences next-state computed.
Of course, the simulation calls next-state in a loop, which involves
hanging on to the dynamic set in some variable which is overwritten at
each iteration with the new dynamic set.
(loop
(setf u (next-state u)))
That bit of imperative programming can be eliminated, if desired, by
using tail recursion.
(defun simulation-loop (u)
(simulation-loop (next-state u))
Of course, a real piece of simulation sofware has to produce some kind
of output: the state of the simulation after a given number of steps,
or even output from each stage (logged as a text stream, or possibly
with a dynamically updated GUI representation, etc).
On Feb 7, 1:17 pm, Kaz Kylheku <········@gmail.com> wrote:
> On Feb 6, 3:10 pm, gavino <·········@gmail.com> wrote:
>
> > If one was forced to use onyl functional programming how would one
> > cover the areas typically handled by oo programming?
>
> Hi Gavino,
>
> One way would be to use object-oriented functional programming:
> immutable objects only. No mutator methods, just accessors and
> constructors. Functional and OO programming are not mutually exclusive
> opposites; object-orientation doesn't imply the use of imperative
> programming.
>
> You can simulate an object changing state by constructing another one
> like it, but with different contents analogous to what the state
> change would be. Constructors (like the CONS function in Lisp) are
> functional. Object accessors (like CAR and CDR in Lisp) are also
> functional.
>
> OO programming was developed to support simulations, and that makes a
> good example.
>
> A simulation under functional programming, might look like the
> repeated application of a filter function ``next-state'' to a dynamic
> set of objects representing the simulated universe. This next-state,
> applied to the universe U at time N would return a new database
> representing the universe at time N+1. The new database would contain
> some old objects (representing things that didn't change state) as
> well as some new ones.
>
> Imagine how much easier debugging might be if you can hang on to the
> entire old version of the full state of the simulation and see what
> differences next-state computed.
>
> Of course, the simulation calls next-state in a loop, which involves
> hanging on to the dynamic set in some variable which is overwritten at
> each iteration with the new dynamic set.
>
> (loop
> (setf u (next-state u)))
>
> That bit of imperative programming can be eliminated, if desired, by
> using tail recursion.
>
> (defun simulation-loop (u)
> (simulation-loop (next-state u))
>
> Of course, a real piece of simulation sofware has to produce some kind
> of output: the state of the simulation after a given number of steps,
> or even output from each stage (logged as a text stream, or possibly
> with a dynamically updated GUI representation, etc).
can you use that to create an object oreiented application server?
On Feb 7, 11:00 pm, gavino <·········@gmail.com> wrote:
> can you use that to create an object oreiented application server?
Can YOU use anything to create any kind of application?
No, don't answer, this is a rhetorical question!
Oh, usenet, why do I bother?