Scheme and OOPS? 
Author Message
 Scheme and OOPS?

Kent> However, a careful addition of a couple of simple OOP concepts
Kent> (polymorphism, inheritance, data abstraction)

yea! let's add polymorphism and abstraction to Scheme!  OOP is just
full of wonderful ideas!

--

                        heart
scott draves            liver



Sun, 24 Jul 1994 01:44:12 GMT  
 Scheme and OOPS?


* >I'm just curious, is there any active work going on
* >to extend the current Scheme standards with OOP extensions?

* There is a saying around here (I first heard it from Norman Adams)
* that "Objects are a poor man's Closures".  Writing object systems in
* Scheme is darn easy.  I think that everyone I know has written at
* least one.  The problem with standardization is deciding which model
* to use--a topic of current research and debate.

That's not the only issue.  Some of us think that OOP is mostly HOOPLA
and not worth spending much energy on.  In particular, why fix the
model at the language level when each program can use whichever it
prefers by building it?



Sun, 24 Jul 1994 11:36:08 GMT  
 Scheme and OOPS?

Quote:

>I'm just curious, is there any active work going on
>to extend the current Scheme standards with OOP extensions?

There is a saying around here (I first heard it from Norman Adams)
that "Objects are a poor man's Closures".  Writing object systems in
Scheme is darn easy.  I think that everyone I know has written at
least one.  The problem with standardization is deciding which model
to use--a topic of current research and debate.

-Ken{*filter*}ey
======
NOTE: N. Adams and J. Rees, "Object-Oriented Programming in Scheme",
Conference Record of the 1988 ACM Conference on Lisp and Functional
Programming, August 1988, 277-288.



Sun, 24 Jul 1994 00:19:41 GMT  
 Scheme and OOPS?
I'm just curious, is there any active work going on
to extend the current Scheme standards with OOP extensions?

I guess there's always the danger that the language goes the
way of C++, and creates a nightmare concerning BNF definitions.

However, a careful addition of a couple of simple OOP concepts
(polymorphism, inheritance, data abstraction) using generic functions
shouldn't create the case where Scheme is suddenly not pure, and
requires too much computer resources...

Kent Sandvik
----
no signature since 1990



Thu, 21 Jul 1994 07:47:43 GMT  
 Scheme and OOPS?

Quote:

>I'm just curious, is there any active work going on
>to extend the current Scheme standards with OOP extensions?

>I guess there's always the danger that the language goes the
>way of C++, and creates a nightmare concerning BNF definitions.

>However, a careful addition of a couple of simple OOP concepts
>(polymorphism, inheritance, data abstraction) using generic functions
>shouldn't create the case where Scheme is suddenly not pure, and
>requires too much computer resources...

Scheme has traditionally taken the approach of being as minimal as
possible.  The basic idea has always been to provide the minimal
constructs necessary to build the various systems that people use.

You can implement a message-passing object-oriented system in Scheme,
based on either inheritance or delegation, without too much
difficulty. (I've done both; each took me less than three days. I
haven't attempted to try it with the new macro system, but I don't
think that that presents any major difficulties.)

Adding something like OO, which has no solid connection with the basic
model of scheme, and which can be implemented easily if you want it,
would be completely against the whole scheme philosophy.

        <MC>
--
[ Mark Craig Carroll <MC> ] You say you know no tricks, have no talents -
[ U of Delaware, CIS Dept ] Isn't everyone supposed to have their own?
[ Grad Student/Lab Hacker ] Yes, but few are obvious. Few draw notice to those



Sat, 23 Jul 1994 22:57:27 GMT  
 Scheme and OOPS?
There is not a lack of OOP work being done in scheme.  If anything,
the problem is that there is so much going on that I would guess a
standard isn't likely to happen for awhile.  [Qualification: I haven't
been a really active member of the scheme community for a few years...
there could be more of a consensus than I am aware of.]  The oldest
scheme OO that I can remember is SCOOPS which TI (among others)
distributed with PC-Scheme although I think a flavors package might
have appeared first.  There is OakLisp which had "objects" all the way
down.  In "The Art of the MetaObject Protocol" the authors indicated
that they are playing with a MetaObject Protocol for scheme written in
CLOS.  And the list goes on.

--mark



Sun, 24 Jul 1994 04:05:00 GMT  
 Scheme and OOPS?

Quote:

>I'm just curious, is there any active work going on
>to extend the current Scheme standards with OOP extensions?
>I guess there's always the danger that the language goes the
>way of C++, and creates a nightmare concerning BNF definitions.

I think it's premature.  In my own small studies I've found tens
of variations on how objects & classes (and objects without classes)
should work, ranging from the original Smalltalk system to the
rococo CLOS stuff to the extremely simple but somewhat unfinished
SELF inheritance paradigm.  ("somewhat unfinished": last summer,
the main SELF guys mentioned they might change the multiple
inheritance stuff because it made odd messes.)

Also, if you're going to design a language or system today,
you should consider parallel execution (the 2-16 processor class
machine).  RISC was the last easy trick for building faster machines,
and multiprocessor boxes are the current one.  Concurrency in
objects is pretty tricky, but it does give an elegant
avenue for moving "Standard Scheme" into those environments.

Also, the Scheme syntax is a clean self-consistent standard;
with macros it's powerful enough that OO can be done as a
library (that may or may not be built in).


details.  

Lance Norskog



Sat, 23 Jul 1994 15:39:29 GMT  
 Scheme and OOPS?
[ Apologies if this article goes out twice - I hit the wrong keys in
my newsreader. ]


Quote:
> That's not the only issue.  Some of us think that OOP is mostly HOOPLA
> and not worth spending much energy on.  In particular, why fix the
> model at the language level when each program can use whichever it
> prefers by building it?

Code reuse.  If I want to grab some OO code from you and some OO code
from somebody else, I'm unlikely to be able to do that without at
least some (and potentially quite a lot of) work if you each use your
own methods for implementing that.

david carlton

       Well, O.K.  I'll compromise with my principles because of
       EXISTENTIAL DESPAIR!



Sun, 24 Jul 1994 22:13:39 GMT  
 Scheme and OOPS?

   > That's not the only issue.  Some of us think that OOP is mostly HOOPLA
   > and not worth spending much energy on.  In particular, why fix the
   > model at the language level when each program can use whichever it
   > prefers by building it?

   Code reuse.  If I want to grab some OO code from you and some OO code
   from somebody else, I'm unlikely to be able to do that without at
   least some (and potentially quite a lot of) work if you each use your
   own methods for implementing that.

And you think you'll get that in a language where implementing your
own is so easy?  I can understand why people don't implement their own
OO extensions in C, and use whichever the system designers (C++
designers) chose, but in Scheme it is quite a different matter.



Mon, 25 Jul 1994 21:29:19 GMT  
 Scheme and OOPS?

Quote:


> * >I'm just curious, is there any active work going on
> * >to extend the current Scheme standards with OOP extensions?
> * There is a saying around here (I first heard it from Norman Adams)
> * that "Objects are a poor man's Closures".  Writing object systems in
> * Scheme is darn easy.  I think that everyone I know has written at
> * least one.  The problem with standardization is deciding which model
> * to use--a topic of current research and debate.
> That's not the only issue.  Some of us think that OOP is mostly HOOPLA
> and not worth spending much energy on.  In particular, why fix the
> model at the language level when each program can use whichever it
> prefers by building it?

A clarification, I'm aware that OOP extensions could be implemented
within hours in *most* computer languages that have the necessary
building blocks.

I'm mostly interested in any activities related to a *standardization*
of OOP extensions, as with CLOS/MOP.

Yes, I know OOP is hoopla, and polymorphism is poor mans functional
programming, however the current computer industry is screaming for
fast prototyping environments. Scheme could actually become a major
player with PC-oriented software engineering, if it had the necessary
semantics/syntax issues standardized which the industry needs.

And as we all know the OOP meme is a strong one just now. Most major
players in the PC industry I'm aware of are using OOP frameworks for
cross-platform porting.

Anyway, it's really up to all of us, if we want Scheme to be a main
teaching and tinkering tool, fine. If we want the computer industry
to use commercially oriented dynamic languages, then we need to do
something about the situation.

Would you like to have your son programming in C++? :-)

Kent Sandvik
----
not speaking for any particular computer company



Tue, 26 Jul 1994 04:00:40 GMT  
 Scheme and OOPS?

Quote:

>   > That's not the only issue.  Some of us think that OOP is mostly HOOPLA
>   > and not worth spending much energy on.  In particular, why fix the
>   > model at the language level when each program can use whichever it
>   > prefers by building it?
>    Code reuse.  If I want to grab some OO code from you and some OO code
>    from somebody else, I'm unlikely to be able to do that without at
>    least some (and potentially quite a lot of) work if you each use your
>    own methods for implementing that.
> And you think you'll get that in a language where implementing your
> own is so easy?

I simply do not understand what you are saying here.  Perhaps I was
being unclear: what I meant to say is that, yes, as you say, in Scheme
programs can build their own OO extensions.  However, if two people
write code building their own OO extensions and do that in different
ways, then I am unlikely to be able to grab code from the first person
which depends on her model and grab code from the second person which
depends on her model and use them together.  Is this what you think I
said?  If so, what is it that you think that I think I'm going to get?
Difficulty of reusing OO code?  Yes.

david carlton

       NEWARK has been REZONED!!  DES MOINES has been REZONED!!



Tue, 26 Jul 1994 10:06:28 GMT  
 Scheme and OOPS?




* > * >I'm just curious, is there any active work going on
* > * >to extend the current Scheme standards with OOP extensions?

* > * There is a saying around here (I first heard it from Norman Adams)
* > * that "Objects are a poor man's Closures".  Writing object systems in
* > * Scheme is darn easy.  I think that everyone I know has written at
* > * least one.  The problem with standardization is deciding which model
* > * to use--a topic of current research and debate.

* > That's not the only issue.  Some of us think that OOP is mostly HOOPLA
* > and not worth spending much energy on.  In particular, why fix the
* > model at the language level when each program can use whichever it
* > prefers by building it?

* A clarification, I'm aware that OOP extensions could be implemented
* within hours in *most* computer languages that have the necessary
* building blocks.

* I'm mostly interested in any activities related to a *standardization*
* of OOP extensions, as with CLOS/MOP.

I understood that fully well.  On the other hand, what are the
necessary building blocks for OOP?  As far as I'm concerned, they are

- Cheap dynamic memory allocation and management, i.e. GC.
- The ability to create objects with local state, i.e. closures.
- The ability to select a procedure from a set according to some key,
i.e. ASSQ (I know you can do better).

The only thing that's missing from Scheme is syntax that packages the
last two, but that is easy to provide.

I'd be much happier with something that Alan Bawden suggested, namely
an OOP tool kit.  Writing the appropriate data structures for fast
method resolution, etc. is not trivial, yet this is not inherent to
OOP.  Any data-driven style of programming can use a fast method
resolver.

* Yes, I know OOP is hoopla, and polymorphism is poor mans functional
* programming, however the current computer industry is screaming for
* fast prototyping environments. Scheme could actually become a major
* player with PC-oriented software engineering, if it had the necessary
* semantics/syntax issues standardized which the industry needs.

* And as we all know the OOP meme is a strong one just now. Most major
* players in the PC industry I'm aware of are using OOP frameworks for
* cross-platform porting.

* Anyway, it's really up to all of us, if we want Scheme to be a main
* teaching and tinkering tool, fine. If we want the computer industry
* to use commercially oriented dynamic languages, then we need to do
* something about the situation.

And you seriously think that adding some OOP cuteness to Scheme would
accomplish this?  I think you don't understand the inertia of
compatibility with C.



Wed, 27 Jul 1994 06:04:31 GMT  
 Scheme and OOPS?

* > And you think you'll get that in a language where implementing your
* > own is so easy?

* I simply do not understand what you are saying here.  Perhaps I was
* being unclear: what I meant to say is that, yes, as you say, in Scheme
* programs can build their own OO extensions.  However, if two people
* write code building their own OO extensions and do that in different
* ways, then I am unlikely to be able to grab code from the first person
* which depends on her model and grab code from the second person which
* depends on her model and use them together.  Is this what you think I
* said?  If so, what is it that you think that I think I'm going to get?
* Difficulty of reusing OO code?  Yes.

What I meant is the following:
Since it is so easy to build your own simple OO system in Scheme,
people will continue to do so whether there is a standard OO package
or not, thus you will still not be able to easily share the code.

Think about it:

Even if we were to adapt a standard OO package, it is unlikely that
Scheme is going to have a complex (very featureful) OO system.  It
goes too much against the grain of the language.

Since it won't be that featureful, some (many) people will decide to
bypass it and write their own.  After all, it's easy.

If it is somehow featureful and complex, many poeple will decide to
bypass it because it is viewed as overkill.

I think it will be realistically impossible to reach the compromise of
a sufficiently featureful yet not huge and overly complex OO system
that everyone will want to use.



Wed, 27 Jul 1994 23:24:50 GMT  
 Scheme and OOPS?

Quote:

>    > That's not the only issue.  Some of us think that OOP is mostly HOOPLA
>    > and not worth spending much energy on.  In particular, why fix the
>    > model at the language level when each program can use whichever it
>    > prefers by building it?
>    Code reuse.  If I want to grab some OO code from you and some OO code
>    from somebody else, I'm unlikely to be able to do that without at
>    least some (and potentially quite a lot of) work if you each use your
>    own methods for implementing that.
> And you think you'll get that in a language where implementing your
> own is so easy?  I can understand why people don't implement their own
> OO extensions in C, and use whichever the system designers (C++
> designers) chose, but in Scheme it is quite a different matter.

I think the key issue is a *standard*. If something like this was defined
we could have shareable Scheme class libraries, or even better, component
oriented libraries.

It is true that Scheme makes one tinker, however I'm mostly looking at Scheme
as a potential future commercial development language. And in this case
implementing personal OOP extensions won't create a component industry.

Kent Sandvik



Wed, 27 Jul 1994 09:40:49 GMT  
 
 [ 70 post ]  Go to page: [1] [2] [3] [4] [5]

 Relevant Pages 

1. Multiple Inheritance OOPS package for Scheme?

2. Implementing OOPS in pure Scheme

3. OOPS in Scheme (summary)

4. OOPS system for Scheme - where?

5. Fed OOPS ... OOPS! We forgot to include Ada!

6. Oops

7. Oops!

8. oops

9. Oops!

10. OOPS

11. Oops, a serious J shortcoming

12. oops

 

 
Powered by phpBB® Forum Software