Re: [goops] adding a number class with generic methods

Re: [goops] adding a number class with generic methods

[Marco Maggi]

"Neil Jerram" wrote:
>"Marco Maggi" <marco.maggi-ipsu@poste.it> writes:
> "marco.maggi-ipsu@poste.it" wrote:
>>  I do not understand why  the first solution does not work;
>>I've tried different combinations  of functions but there is
>>something I am missing.
>
> Damn... it seems to work if I do not EXPORT the generic
> methods.
>
>You mean if you remove the "(export =)" line?

Yes, with the following and no EXPORT invocation
it works.

(define-macro (make-comparison-operator class name func)
  `(begin
     (define-method (,name (a ,class) (b ,class))
       (,func (slot-ref a 'n) (slot-ref b 'n)))

     (define-method (,name (a ,class) (b <real>))
       (,func (slot-ref a 'n) (usable->mpfr b)))

     (define-method (,name (a <real>) (b ,class))
       (,func (usable->mpfr a) (slot-ref b 'n)))))

(make-comparison-operator <mpfr> = mpfr-equal?)


--
Marco Maggi




_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: [goops] adding a number class with generic methods

[Mikael Djurfeldt]

On 5/4/06, Marco Maggi <marco.maggi-ipsu@poste.it> wrote:
> "Neil Jerram" wrote:
> >"Marco Maggi" <marco.maggi-ipsu@poste.it> writes:
> > "marco.maggi-ipsu@poste.it" wrote:
> >>  I do not understand why  the first solution does not work;
> >>I've tried different combinations  of functions but there is
> >>something I am missing.
> >
> > Damn... it seems to work if I do not EXPORT the generic
> > methods.
> >
> >You mean if you remove the "(export =)" line?
>
> Yes, with the following and no EXPORT invocation
> it works.

Actually, logically this *is* how the code should be structured.  If
you had created a novel generic function within your module, that
function should have been exported.  But what you really want is just
to add methods to the pre-existing generic function = which you
(implicitly) *import* into your module.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: [goops] adding a number class with generic methods

[Neil Jerram]

"Mikael Djurfeldt" <mdjurfeldt@gmail.com> writes:

> On 5/4/06, Marco Maggi <marco.maggi-ipsu@poste.it> wrote:
>>
>> Yes, with the following and no EXPORT invocation
>> it works.
>
> Actually, logically this *is* how the code should be structured.  If
> you had created a novel generic function within your module, that
> function should have been exported.  But what you really want is just
> to add methods to the pre-existing generic function = which you
> (implicitly) *import* into your module.

I agree that this explains why the export is not necessary (and hence
why it works without it).  But I don't yet understand why adding the
export messes things up.

Regards,
        Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: [goops] adding a number class with generic methods

[Mikael Djurfeldt]

On 5/7/06, Neil Jerram <neil@ossau.uklinux.net> wrote:
> I agree that this explains why the export is not necessary (and hence
> why it works without it).  But I don't yet understand why adding the
> export messes things up.

In the current module system, the effect of mentioning a variable in
an export statement is to set up a new, undefined, variable with that
name.  This variable is added to the module and to the export list of
the model.  The former has the effect of shadowing the old variable =.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: [goops] adding a number class with generic methods

[Neil Jerram]

"Mikael Djurfeldt" <mdjurfeldt@gmail.com> writes:

> On 5/7/06, Neil Jerram <neil@ossau.uklinux.net> wrote:
>> I agree that this explains why the export is not necessary (and hence
>> why it works without it).  But I don't yet understand why adding the
>> export messes things up.
>
> In the current module system, the effect of mentioning a variable in
> an export statement is to set up a new, undefined, variable with that
> name.  This variable is added to the module and to the export list of
> the model.  The former has the effect of shadowing the old variable =.

I see.  Thanks for explaining this.

  Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: [goops] adding a number class with generic methods

[Ludovic Courtès]

Hi,

"Mikael Djurfeldt" <mdjurfeldt@gmail.com> writes:

> In the current module system, the effect of mentioning a variable in
> an export statement is to set up a new, undefined, variable with that
> name.

And thus the first `define-method' creates a new, empty, generic
function.  That makes it sometimes quite tricky to spread method
definitions all over the place (e.g., see G-Wrap...).

Thanks,
Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: [goops] adding a number class with generic methods

[Mikael Djurfeldt]

On 5/9/06, Ludovic Courtès <ludovic.courtes@laas.fr> wrote:
> "Mikael Djurfeldt" <mdjurfeldt@gmail.com> writes:
>
> > In the current module system, the effect of mentioning a variable in
> > an export statement is to set up a new, undefined, variable with that
> > name.
>
> And thus the first `define-method' creates a new, empty, generic
> function.  That makes it sometimes quite tricky to spread method
> definitions all over the place (e.g., see G-Wrap...).

Could you elaborate on that?  In what way does GOOPS/module system
make this tricky, and how do you envision a better design?

It is my opinion that the current design with regards to generic
functions, methods and module system is in no way too restrictive.  If
you think it is, you should read the following reference:

  http://www2.parc.com/csl/groups/sda/publications/papers/Kiczales-OOPSLA92/for-web.pdf

Rather, I think the points where it can be criticized is that some
things are a bit "too automatic" and there should be better and more
error messages in some cases.

If you want a certain generic function to be available everywhere,
then you have to pose exactly the same question as you would do for an
ordinary function: Which module should export this function? 
Everybody else needs to import from that module, even those who add
new methods.

Of course, one may feel that the fact that methods can "spread"
through the generic function in a rather arbitrary manner across
module borders is a problem.  For those who want a more restricted
access to methods, there is the possibility to use extended generics. 
This is explained in NEWS, I think.

Best regards,
M


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

GOOPS and Code Complexity

[Ludovic Courtès]

Hi,

"Mikael Djurfeldt" <mdjurfeldt@gmail.com> writes:

> On 5/9/06, Ludovic Courtès <ludovic.courtes@laas.fr> wrote:
>> And thus the first `define-method' creates a new, empty, generic
>> function.  That makes it sometimes quite tricky to spread method
>> definitions all over the place (e.g., see G-Wrap...).
>
> Could you elaborate on that?  In what way does GOOPS/module system
> make this tricky, and how do you envision a better design?

Oh, I do not mean that GOOPS and Guile's module system make GOOPS hard
to use --- and I'd be unable to envision a better design.  I think
they're both good at their job.

Rather, my opinion is that CLOS-like systems are so flexible that it can
make it quite hard to understand the structure of a piece of code,
specifically when method definitions are spread across different
modules.

This is what happens in the GOOPS-based G-Wrap.  A set of classes and
generics are defined in some top-level module.  Then, there are various
modules that add two-line methods to these generics.  Since there's a
relatively deep class hierarchy, understanding what the control flow may
be can be quite hard, especially in the presence of `next-method' calls
("vertical code reuse", which I find problematic --- but this is not
CLOS-specific).  Interestingly, in G-Wrap, some modules specialize
methods to classes that are not exported themselves.  Nothing wrong with
that, but again, it doesn't help the reader.

Also, the fact that method dispatching takes all arguments into account,
as well as the number of arguments, is one of CLOS' strength compared to
static OO languages like Java/C++.  But it also makes it harder to guess
what code will be executed by just looking at a given method call.

As a method-overloading-module author, one must make sure to:

  1. Not export the binding in question (as shown with this thread);

  2. Import the module that actually defines the generic;

  3. Correctly spell the generic's name.

Of course, these are all necessary for ordinary procedures as well.  But
in the case of GOOPS methods, these can yield harder-to-find errors
(see, e.g.,
http://lists.nongnu.org/archive/html/g-wrap-dev/2005-09/msg00000.html ).

Furthermore, CLOS-like systems introduce a new class of side-effects
that has to be taken into account by the user.  Usually, the only
side-effect induced by using a module is that it modifies the user's
name space.

When GOOPS method definitions are spread across modules, one must be
aware that using a module means more than just adding bindings to their
name space.  For instance, one may have to use a module even if none of
the bindings it exports is of interest, just because that module adds
methods to various previously-defined generics.  Understanding that kind
of relationship among modules is not trivial when reading a
harmless-looking list of `use-module' clauses, IMO.

Another way to express all that it that CLOS is very name-centric.  This
makes a significant difference compared to the Scheme philosophy where
names (top-level bindings) can often be avoided by passing
procedures/closures around.

> Rather, I think the points where it can be criticized is that some
> things are a bit "too automatic" and there should be better and more
> error messages in some cases.

Right, it is true that it's a bit "too automatic".  OTOH, automatic
features like automatically creating when the first `define-method' for
a given name is encountered are quite handy.

As for error messages, I'm not sure they could really be improved.  In
fact, issues like those I mentioned above are "normal", i.e., they are
not GOOPS' nor the module system's fault: rather, these are traps users
should pay attention to.  ;-)

> Of course, one may feel that the fact that methods can "spread"
> through the generic function in a rather arbitrary manner across
> module borders is a problem.  For those who want a more restricted
> access to methods, there is the possibility to use extended
> generics. This is explained in NEWS, I think.

I couldn't find information about it.  Do you have more specific
pointers?

In fact, I had been very enthusiast about CLOS in general and GOOPS in
particular for some time.  Now, I no longer find it so cool, notably
because of the readability issues I mentioned earlier.  I also tend to
agree with the arguments in http://paulgraham.com/noop.html and related
pages.

Thanks,
Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: [goops] adding a number class with generic methods

[Marco Maggi]

"marco.maggi-ipsu@poste.it" wrote:
>  I do not understand why  the first solution does not work;
>I've tried different combinations  of functions but there is
>something I am missing.

Damn... it seems to work if I do not EXPORT the generic
methods.

--
Marco Maggi




_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: [goops] adding a number class with generic methods

[Neil Jerram]

"Marco Maggi" <marco.maggi-ipsu@poste.it> writes:

> "marco.maggi-ipsu@poste.it" wrote:
>>  I do not understand why  the first solution does not work;
>>I've tried different combinations  of functions but there is
>>something I am missing.
>
> Damn... it seems to work if I do not EXPORT the generic
> methods.

You mean if you remove the "(export =)" line?

    Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

[goops] adding a number class with generic methods

[Marco Maggi]

Hi,

  I  am trying  to add  a new  number class,  export generic
methods from a module and import them into another one. If I
ignore the GOOPS tutorial and read only the reference, it is
my understanting that I should do:

;; ----------------------------------------
;; exporting.scm

(define-module (gee gmp ompfr)
  #:use-module (oop goops)
  #:use-module (gee gmp mpfr))

(define-class <mpfr> (<number>)
  (n #:init-value (real->mpfr 0) #:init-keyword #:value))

;; ... other stuff ...

(define-method (= (a <mpfr>) (b <mpfr>))
  (mpfr-equal? (slot-ref a 'n) (slot-ref b 'n)))

(define-method (= (a <mpfr>) (b <real>))
  (mpfr-equal? (slot-ref a 'n) (usable->mpfr b)))

(define-method (= (b <real>) (a <mpfr>))
  (mpfr-equal? (slot-ref a 'n) (usable->mpfr b)))

(export =)

;; ----------------------------------------
;; importing.scm

(define-module (my-test)
  #:use-module (mmg test dotest-1)
  #:use-module (oop goops)
  #:duplicates merge-generics
  #:use-module (gee gmp ompfr))

(= #,(MPFR 2) #,(MPFR 2))

;; ----------------------------------------

but I get this error:

...
   ?: 6  (= #<<mpfr> 40351520> #<<mpfr> 403505e0>)

<unnamed port>: In expression (= #<<mpfr> 40351520> #<<mpfr>
403505e0>):
<unnamed port>: Unbound variable: =


  If I read the tutorial it seems that I have to replace the
'(define-method (= ...' definitions with:

;; ----------------------------------------

(define-generic my=)

(let ((original= =))

  (define-method (my= (a <number>) (b <number>))
    (original= a b)))

(define-method (my= (a <mpfr>) (b <mpfr>))
  (mpfr-equal? (slot-ref a 'n) (slot-ref b 'n)))

(define-method (my= (a <mpfr>) (b <real>))
  (mpfr-equal? (slot-ref a 'n) (usable->mpfr b)))

(define-method (my= (b <real>) (a <mpfr>))
  (mpfr-equal? (slot-ref a 'n) (usable->mpfr b)))

(set! = my=)

;; ----------------------------------------

but I get the same error.

  I do not understand why  the first solution does not work;
I've tried different combinations  of functions but there is
something I am missing.



--
Marco Maggi

"They say jump!, you say how high?"
Rage Against the Machine - "Bullet in the Head"



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user