Re: records

[Chris Bitmead <chris@tech.com.au>]

Jost Boekemeier wrote:
> 
> Chris Bitmead <chris@tech.com.au> writes:
> 
> >.However display is unlikely to have the same code for all types
> 
> It has.

There is different code in this function for each of the types....
 
> scm_iprin1 (exp, port, pstate)
> {
>   switch (7 & (int) exp) {
>     case 2:
>     case 6:
>       scm_intprint (SCM_INUM (exp), 10, port);
> 
>     case ... /* print a macro */
> 
>     case ... /* print a closure */
> }
> 
> If display were polymorphic every object (macro, closure, int 
> etc.) would have a print function of its own.

Why are you worrying about how guile/scm has implemented display? As far
as the caller of display is concerned, it appears to be polymorphic.
Sure you can implement polymorphism with a giant switch statement. A C++
compiler will implement it with a giant jump table. What's important is
some mechanism for dispatching on type. Hand coding big switch
statements is a bad way to go, obviously, but the result is the same.
Nobody said that SCM/guile had to use a big switch.
 
> Take a look at Meyer's book on page 1175: "Emulating 
> inheritance with genericity" where he describes that generic 
> functions like scheme's print function must emulate 
> polymorphism by using a giant switch statement.

Nonsense. Even SICP has an example of building an extensible polymorphic
system without hand-coded switch statements. How do you think you can
load tclos.scm into any old scheme and get polymorphism without
switches?

> My point was that polymorphism is superior to genericity. You 
> can easily emulate genericity by using polymorphism. 

Now which sort of genericity are we talking about here? generic
functions in CLOS  IS polymorphism - dispatching on type. On the other
hand genericity in Meyer's vocabulary is a hack for building a type-safe
language, of which Scheme is not.


> Unfortunately scheme is functional language and the authors of 
> scheme choose genericity in favor of polymorphism.

We must be talking at cross purposes here. Scheme doesn't have any built
in system of polymorphism OR genericity (genericity in either of its
possible meanings). Yes one or two built in functions (like display)
have these properties but no extensible system. But you can build
anything on top of Scheme to suit your fancy.
 
> If think the problem is that when you want to introduce 
> polymorphism into guile you must first define an explicit type 
> system.

Naturally. Scheme has a type system. Just not an extensible one in its
vanilla form.
 
> On the other hand you can't create a complete operating 
> environment just by using guile. 

Why??

> As I understand it guile  should only be the glue between 
> objects and programs written in C and it should help objects
> and programs written in C to parse and write their 
> configuration files. 

I don't accept that at all. Guile is good at talking to C, sure. But I
prefer to do things in pure guile.

> So I think that every guile object would be (more or less) a
> proxy object for a programm or object written in C.

No way. If you've got an existing set of C code, sure that is a way to
go. But if you're starting from scratch, pure scheme is much nicer.
 
> P.S.:  I've looked at the "OO FAQ".  Please BURN IT. :) It
> seems do describe pseudo OO terms that were used 20 years ago.
> For example genericity has *nothing* to do with the OO 
> paradigm, it is quite the opposite.

Depends on the circles you move in. generic function in the scheme/lisp
world has absolutely nothing to do with genericity in Meyer's
vocabulary.


-- 
Chris Bitmead
mailto:chris@tech.com.au