This is the mail archive of the guile@cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: records


Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:

> Chris Bitmead <chris@tech.com.au> writes:
> 
> >.However display is unlikely to have the same code for all types
> 
> It has.
>  
> 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.

So, since C++ uses something like vtable[function_id](arguments) to
dispatch by type, C++ also simulates inheritance through genericity?!

In fact, some other Scheme implementations use same thing as C++
vtable (like Rscheme) - their cells have object type pointer and so
they don't need a switch at all.

In the case above, it's a simple fact that Guile's way of tagging
types needs more complex dispatch mechanism than *only* a jump through
a pointer. So display is polymorphic. You should be able to tell
/without/ looking at the implementation, by the way.

> 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.
> 
> In contrast take a look at the implementation of smobs:  Every smob
> has its own print function.  So the smob's print function is polymorphic.

These two paragraphs contradict each other. Either Meyer is right and
printing in Scheme can NOT be polymorphic or you are right and print
in Scheme /can/ be polymorphic after all... if everything were a smob
(and Guile could technically be rewritten that way, with performance
loss).

> My point was that polymorphism is superior to genericity. You can
> easily emulate genericity by using polymorphism.  Unfortunately
> scheme is functional language and the authors of scheme choose
> genericity in favor of polymorphim.

A CLOS generic function is completely unrelated to anything you said
about genericity. In particular, it's polymorphic. Refer to CLtL for
the relevant definitions (and Meyer's definitions are not relevant in
this context, as we are discussing CLOS/GOOPS/Guile, rather than
Eiffel).

So, where in the CLOS design or GOOPS implementation do you find basis
for stating that authors of scheme chose genericity in the sense you
use (as it is obvious to me that everything you say against genericity
is irrelevant to CLOS which, as it happens, does NOT use huge switch
statements, and GOOPS, which also does not use huge switch statements)?

> If think the problem is that when you want to introduce polymorphism
> into guile you must first define an explicit type system.

Read GOOPS implementation. This is true, but only requires
(typeof object) to be defined on everything and returns a meaningful
result. It is not clear to me how it relates to Scheme's (not) being
polymorphic - especially since in some other Scheme implementation
typeof could be a simple pointer fetch.

> On the other hand you can't create a complete operating environment
> just by using guile.  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.  So I think that every guile object would be
> (more or less) a proxy object for a programm or object written in C.

This is absolutely false for the particular program I'm writing, which
uses C for the tricky parts that need speed but majorly relays on
Guile everywhere else (about 50% of the 20,000 lines count is
Guile). See http://petra.zesoi.fer.hr/~silovic/sart. The most you can
conclude from Guile being extension language is that *some* objects
will be proxy objects for C code. Since smobs already are GOOPS types,
this doesn't really present a problem.

> > I'm not sure that there is "standard OO terminology". 
> 
> I would say that Rumbaugh, Meyer, Booch and Jakobsen are the
> authorities in the OO field.  UML is standard these days.
> 
> The same terminology is also used by Wirth, Stourstrup and others.
> If you look at the latest book from Tom DeMarco you will see that he
> also uses their terminology. :)

The fact that CLOS does not use this terminology is completely
irrelevant to its success or failure.

-- 
I refuse to use .sig

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]