Help required with exporting and using GOOP generics

Help required with exporting and using GOOP generics

[Brent Pinkney]

[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]

Hello,

I am having serious problems exporting generics from subclasses of 
<object> and then using them in other modules.
I have trawled the logs and tried every combination I can thing of.

I have tried creating a common base class <thing> for all my classes and 
defining the methods there, I have tried exporting generics, and I have 
even tried every combination of #:duplicates (merge-generics, first, 
last. etc.).

I can sometimes make some progress but eventually I grind to a halt - 
often with spurious error messages saying that "format" and "for-each" 
are not memoized.

I am also quite willing to rework my code to fit guile - I just need 
some help on how to proceed.

Basically I would like a class hierarchy.

     Module            Class
-------------------------------------
                         <object>
(brent thing)            <thing>          ; optional - let me know
                              id name name!
(brent foo)             <foo>
                             ; redefines from <thing>
                             id name name!
"same file"            <bar>
                             ; uses thing.name!
(brent baz)            <baz>
                             ; redefines from <thing>
                             name name!

I would then like a common module (brent main) to import (brent thing) 
(brent foo) and (brent baz) and then merrily create and use these classes.


Please can someone provide me with the recipe that will solve the above 
and also scale to a proper large system.

(I have test code - if required)

Thanks

Brent



[-- Attachment #2: Type: text/html, Size: 2447 bytes --]

Re: Help required with exporting and using GOOP generics

[David Pirotte]

Hello Brent,

Please send the code, i'll look at it asap.

I am precisely in a discussion with developers about goops and the way the guile
module system interferes with it, since i also believe that there is a serious
problem indeed: and not 'just' because there is no way to ask goops 'stuff' to land
in a single module, but because if you don't do the right [counter intuitive] thing
then export actually exports single class capable accessors and methods instead of
the generic.

Anyway, please send your code, because there is a way to make it run, it's just a
matter of you understanding how and i'll do my best to help you.

Cheers,
David

;; --

Le Thu, 14 Mar 2013 12:55:11 +0200,
Brent Pinkney <brp@4dst.com> a écrit :

> Hello,
> 
> I am having serious problems exporting generics from subclasses of 
> <object> and then using them in other modules.
> I have trawled the logs and tried every combination I can thing of.
> 
> I have tried creating a common base class <thing> for all my classes and 
> defining the methods there, I have tried exporting generics, and I have 
> even tried every combination of #:duplicates (merge-generics, first, 
> last. etc.).
> 
> I can sometimes make some progress but eventually I grind to a halt - 
> often with spurious error messages saying that "format" and "for-each" 
> are not memoized.
> 
> I am also quite willing to rework my code to fit guile - I just need 
> some help on how to proceed.
> 
> Basically I would like a class hierarchy.
> 
>      Module            Class
> -------------------------------------
>                          <object>
> (brent thing)            <thing>          ; optional - let me know
>                               id name name!
> (brent foo)             <foo>
>                              ; redefines from <thing>
>                              id name name!
> "same file"            <bar>
>                              ; uses thing.name!
> (brent baz)            <baz>
>                              ; redefines from <thing>
>                              name name!
> 
> I would then like a common module (brent main) to import (brent thing) 
> (brent foo) and (brent baz) and then merrily create and use these classes.
> 
> 
> Please can someone provide me with the recipe that will solve the above 
> and also scale to a proper large system.
> 
> (I have test code - if required)
> 
> Thanks
> 
> Brent
> 
> 

Re: Help required with exporting and using GOOP generics

[Mark H Weaver]

Hi Brent,

Brent Pinkney <brp@4dst.com> writes:
> I am having serious problems exporting generics from subclasses of
> <object> and then using them in other modules.

Apologies for the confusion.  You're not the only one who's been having
trouble with this.  There *is* a proper solution, which I will describe
below, but clearly this issue needs to be discussed in the manual, and
we should probably add some compiler warnings as well.

The root of the problem is that GOOPS automatically defines generic
functions whenever you add a method to a generic that does not exist.
IMO, this was a serious design error, made many years ago.  It was done
in the name of convenience, but has caused enormous confusion over the
years.  It is best to *never* rely on this automatic behavior.

The proper solution is as follows:

* Every generic function must be defined (using 'define-generic') and
  exported from one (and only one) module.

* Every module that uses a generic function, or adds a method to it (and
  that includes slot accessors), must first import the generic function
  from the (one) module that exports it.

Think of a generic function as a normal procedure that contains an
internal table of methods.  Like any other procedure, there's a single
module that defines it and exports it.  The fact that some modules add
methods to these internal tables does not mean that it is appropriate to
export the procedure from those other modules.

Hope this helps,

      Mark

Re: Help required with exporting and using GOOP generics

[dsmich]

---- Mark H Weaver <mhw@netris.org> wrote: 
> The proper solution is as follows:
> 
> * Every generic function must be defined (using 'define-generic') and
>   exported from one (and only one) module.
> 
> * Every module that uses a generic function, or adds a method to it (and
>   that includes slot accessors), must first import the generic function
>   from the (one) module that exports it.
> 
> Think of a generic function as a normal procedure that contains an
> internal table of methods.  Like any other procedure, there's a single
> module that defines it and exports it.  The fact that some modules add
> methods to these internal tables does not mean that it is appropriate to
> export the procedure from those other modules.

Thanks Mark.  Very concisely put.

-Dale
 

Re: Help required with exporting and using GOOP generics

[Brent Pinkney]

[-- Attachment #1: Type: text/plain, Size: 1281 bytes --]

On 15/03/2013 02:11, dsmich@roadrunner.com wrote:
> ---- Mark H Weaver <mhw@netris.org> wrote:
>> The proper solution is as follows:
>>
>> * Every generic function must be defined (using 'define-generic') and
>>    exported from one (and only one) module.
>>
>> * Every module that uses a generic function, or adds a method to it (and
>>    that includes slot accessors), must first import the generic function
>>    from the (one) module that exports it.
>>
>> Think of a generic function as a normal procedure that contains an
>> internal table of methods.  Like any other procedure, there's a single
>> module that defines it and exports it.  The fact that some modules add
>> methods to these internal tables does not mean that it is appropriate to
>> export the procedure from those other modules.
> Thanks Mark.  Very concisely put.

Really ?

How does that work in an environment where you are using third party 
libraries, lice srfi, ice-9, guile-lib, etc as well as your own code.

How could one possibly ensure that the other libraries export say 
"format" correctly - perhaps they are purists and not even aware of the 
goops modules.

I think guile has it backwards here - goops must not break quiles 
modules when someone imports a guile generic.


Thanks

Brent






[-- Attachment #2: Type: text/html, Size: 2194 bytes --]

Re: Help required with exporting and using GOOP generics

[Mark H Weaver]

Mark H Weaver <mhw@netris.org> wrote:
> The proper solution is as follows:
>
> * Every generic function must be defined (using 'define-generic') and
>   exported from one (and only one) module.
>
> * Every module that uses a generic function, or adds a method to it (and
>   that includes slot accessors), must first import the generic function
>   from the (one) module that exports it.
>
> Think of a generic function as a normal procedure that contains an
> internal table of methods.  Like any other procedure, there's a single
> module that defines it and exports it.  The fact that some modules add
> methods to these internal tables does not mean that it is appropriate to
> export the procedure from those other modules.

Brent Pinkney <brp@4dst.com> wrote:
> How does that work in an environment where you are using third party
> libraries, lice srfi, ice-9, guile-lib, etc as well as your own code.

I'm sorry, I don't understand what you mean here.

> How could one possibly ensure that the other libraries export say
> "format" correctly - perhaps they are purists and not even aware of
> the goops modules.

'format' is not a generic function.  What does that have to do with this
discussion?

> I think guile has it backwards here - goops must not break quiles
> modules when someone imports a guile generic.

Again, I don't understand.  What do you mean by "break guile's modules"?
Can you please elaborate?

    Thanks,
     Mark

Re: Help required with exporting and using GOOP generics

[Mark H Weaver]

Brent Pinkney <brp@4dst.com> writes:
> How does that work in an environment where you are using third party
> libraries, lice srfi, ice-9, guile-lib, etc as well as your own code.

Okay, I have a guess about what you meant here.  Suppose two
independently developed modules add methods to generics with the same
name.  How can they arrange to export the generic from a single module?
This is the heart of the issue.

The problem is, how does Guile know that these two generics with the
same name *should* be merged together?  Maybe they have completely
different semantics.

For example, suppose a curses-based display module defines a "draw"
generic function, and adds methods to it for the standard Scheme data
types such as strings and lists.  Now suppose an unrelated OpenGL
display module defines its own "draw" generic function, and adds methods
for the same Scheme data types.

It would obviously be bad if Guile assumed that these were the same
generic function, just because they have the same name.  And yet
avoiding such collisions would require giving generic functions long
names, and the crossing one's fingers and hoping that no one else used
the same name, just like in the bad old days of Lisps based on
dynamically-scoped variables.

On the other hand, if you know that two generics from independently
developed modules should be merged, then you can make that happen using
the 'merge-generics' stuff.  However, it's best to avoid this way of
doing things when feasible.

In particular, the practice of letting each module in your project
automatically define fresh generics (and then merging these generics
together while importing the modules) has a serious problem: it means
that each module ends up with generics that only work on the classes
that it *directly* imported.  In many cases this is not sufficient.

      Mark