* Re: [goops] adding a number class with generic methods
@ 2006-05-04 19:13 Marco Maggi
2006-05-04 19:26 ` Mikael Djurfeldt
0 siblings, 1 reply; 11+ messages in thread
From: Marco Maggi @ 2006-05-04 19:13 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [goops] adding a number class with generic methods 2006-05-04 19:13 [goops] adding a number class with generic methods Marco Maggi @ 2006-05-04 19:26 ` Mikael Djurfeldt 2006-05-06 23:07 ` Neil Jerram 0 siblings, 1 reply; 11+ messages in thread From: Mikael Djurfeldt @ 2006-05-04 19:26 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [goops] adding a number class with generic methods 2006-05-04 19:26 ` Mikael Djurfeldt @ 2006-05-06 23:07 ` Neil Jerram 2006-05-07 9:37 ` Mikael Djurfeldt 0 siblings, 1 reply; 11+ messages in thread From: Neil Jerram @ 2006-05-06 23:07 UTC (permalink / raw) Cc: guile-user "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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [goops] adding a number class with generic methods 2006-05-06 23:07 ` Neil Jerram @ 2006-05-07 9:37 ` Mikael Djurfeldt 2006-05-07 11:45 ` Neil Jerram 2006-05-09 7:56 ` Ludovic Courtès 0 siblings, 2 replies; 11+ messages in thread From: Mikael Djurfeldt @ 2006-05-07 9:37 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [goops] adding a number class with generic methods 2006-05-07 9:37 ` Mikael Djurfeldt @ 2006-05-07 11:45 ` Neil Jerram 2006-05-09 7:56 ` Ludovic Courtès 1 sibling, 0 replies; 11+ messages in thread From: Neil Jerram @ 2006-05-07 11:45 UTC (permalink / raw) Cc: guile-user "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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [goops] adding a number class with generic methods 2006-05-07 9:37 ` Mikael Djurfeldt 2006-05-07 11:45 ` Neil Jerram @ 2006-05-09 7:56 ` Ludovic Courtès 2006-05-09 8:30 ` Mikael Djurfeldt 1 sibling, 1 reply; 11+ messages in thread From: Ludovic Courtès @ 2006-05-09 7:56 UTC (permalink / raw) Cc: guile-user, Neil Jerram 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [goops] adding a number class with generic methods 2006-05-09 7:56 ` Ludovic Courtès @ 2006-05-09 8:30 ` Mikael Djurfeldt 2006-05-09 9:43 ` GOOPS and Code Complexity Ludovic Courtès 0 siblings, 1 reply; 11+ messages in thread From: Mikael Djurfeldt @ 2006-05-09 8:30 UTC (permalink / raw) Cc: Mikael Djurfeldt, Neil Jerram 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* GOOPS and Code Complexity 2006-05-09 8:30 ` Mikael Djurfeldt @ 2006-05-09 9:43 ` Ludovic Courtès 0 siblings, 0 replies; 11+ messages in thread From: Ludovic Courtès @ 2006-05-09 9:43 UTC (permalink / raw) Cc: guile-user, Neil Jerram 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [goops] adding a number class with generic methods
@ 2006-05-03 5:36 Marco Maggi
2006-05-04 7:47 ` Neil Jerram
0 siblings, 1 reply; 11+ messages in thread
From: Marco Maggi @ 2006-05-03 5:36 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [goops] adding a number class with generic methods 2006-05-03 5:36 [goops] adding a number class with generic methods Marco Maggi @ 2006-05-04 7:47 ` Neil Jerram 0 siblings, 0 replies; 11+ messages in thread From: Neil Jerram @ 2006-05-04 7:47 UTC (permalink / raw) Cc: guile-user "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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [goops] adding a number class with generic methods @ 2006-05-02 20:16 Marco Maggi 0 siblings, 0 replies; 11+ messages in thread From: Marco Maggi @ 2006-05-02 20:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2006-05-09 9:43 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-05-04 19:13 [goops] adding a number class with generic methods Marco Maggi 2006-05-04 19:26 ` Mikael Djurfeldt 2006-05-06 23:07 ` Neil Jerram 2006-05-07 9:37 ` Mikael Djurfeldt 2006-05-07 11:45 ` Neil Jerram 2006-05-09 7:56 ` Ludovic Courtès 2006-05-09 8:30 ` Mikael Djurfeldt 2006-05-09 9:43 ` GOOPS and Code Complexity Ludovic Courtès -- strict thread matches above, loose matches on Subject: below -- 2006-05-03 5:36 [goops] adding a number class with generic methods Marco Maggi 2006-05-04 7:47 ` Neil Jerram 2006-05-02 20:16 Marco Maggi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).