overloading an existing operator in Guile

overloading an existing operator in Guile

[Damien Mattei]

hello,
is it possible to overload an existing operator in Guile?

example overload + to concatenate vectors.

for example in Scheme (+ i admit) i can do :
; first stage overloading
(define-overload-existing-operator +)

; second stage overloading
(overload-existing-operator + vector-append (vector? vector?))

and use it like that:
> (+ #(1 2 3) #(4 5 6))
'#(1 2 3 4 5 6)
> (+ #(1 2 3) #(4 5) #(6 7 8 9))
'#(1 2 3 4 5 6 7 8 9)
> {#(1 2) + #(3) + #(4 5 6)}
'#(1 2 3 4 5 6)

is it possible and how to do it using GOOPS (guile object oriented
programming system) , i already did some sort of thing with new object
, but not with an existing operator like + that apply to numbers only.

Regards,
Damien

Re: overloading an existing operator in Guile

[Jean Abou Samra]

> Le 3 oct. 2023 à 11:14, Damien Mattei <damien.mattei@gmail.com> a écrit :
> 
> is it possible to overload an existing operator in Guile?


Yes, but it's a bit buggy. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64508

Re: overloading an existing operator in Guile

[Damien Mattei]

thank you
i understand i must overload + the usual way in <vector> class
scheme@(guile-user)> <vector>
$2 = #<<class> <vector> 104a6e380>

about the described problem this should not be a problem because -
<vector> as no sense in term of concatanate

On Tue, Oct 3, 2023 at 11:19 AM Jean Abou Samra <jean@abou-samra.fr> wrote:
>
>
>
> Le 3 oct. 2023 à 11:14, Damien Mattei <damien.mattei@gmail.com> a écrit :
>
> is it possible to overload an existing operator in Guile?
>
>
>
> Yes, but it's a bit buggy. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64508

Re: overloading an existing operator in Guile

[Damien Mattei]

solution:

scheme@(guile-user)> (define-method (+ (x <vector>) (y <vector>))
(vector-append x y))
;;; <stdin>:11:46: warning: possibly unbound variable `vector-append'
scheme@(guile-user)> (use-modules (srfi srfi-43))
scheme@(guile-user)> (+ 2 3)
$3 = 5
scheme@(guile-user)> (+ #(1 2 3) #(4 5))
$4 = #(1 2 3 4 5)

scheme@(guile-user)> {#(1 2 3) + #(4 5)}
$5 = #(1 2 3 4 5)

On Tue, Oct 3, 2023 at 12:33 PM Damien Mattei <damien.mattei@gmail.com> wrote:
>
> thank you
> i understand i must overload + the usual way in <vector> class
> scheme@(guile-user)> <vector>
> $2 = #<<class> <vector> 104a6e380>
>
> about the described problem this should not be a problem because -
> <vector> as no sense in term of concatanate
>
> On Tue, Oct 3, 2023 at 11:19 AM Jean Abou Samra <jean@abou-samra.fr> wrote:
> >
> >
> >
> > Le 3 oct. 2023 à 11:14, Damien Mattei <damien.mattei@gmail.com> a écrit :
> >
> > is it possible to overload an existing operator in Guile?
> >
> >
> >
> > Yes, but it's a bit buggy. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64508

Re: overloading an existing operator in Guile

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 1814 bytes --]



Op 03-10-2023 om 11:13 schreef Damien Mattei:
> hello,
> is it possible to overload an existing operator in Guile?
> 
> example overload + to concatenate vectors.
> 
> for example in Scheme (+ i admit) i can do :
> ; first stage overloading
> (define-overload-existing-operator +)
> 
> ; second stage overloading
> (overload-existing-operator + vector-append (vector? vector?))
> 
> and use it like that:
>> (+ #(1 2 3) #(4 5 6))
> '#(1 2 3 4 5 6)
>> (+ #(1 2 3) #(4 5) #(6 7 8 9))
> '#(1 2 3 4 5 6 7 8 9)
>> {#(1 2) + #(3) + #(4 5 6)}
> '#(1 2 3 4 5 6)
> 
> is it possible and how to do it using GOOPS (guile object oriented
> programming system) , i already did some sort of thing with new object
> , but not with an existing operator like + that apply to numbers only.

It's explained in ‘(guile)Methods and Generic Functions’ how to do this.

However, I very much recommend not doing this in your situation.

While this could be a valid interpretation of vector ‘addition’, here is 
another valid interpretation incompatible with yours:

;; element-wise addition
(+ #(1 2 3) #(4 5 6))
#(5 7 9)

Sure, you could choose vector appending in Scheme+ and document that 
appropriately, but so could a hypothetical SchemePlus choose 
element-wise addition, and then if someone imports a library using 
Scheme+ and also a library SchemePlus, there is ambiguity and GOOPS will 
get things wrong!

Instead, I propose using the symbol '++' and defining a new method named 
'++'.  It would unambiguously mean ‘appending’ (*) instead of 
‘addition’, and as an additional benefit, some other languages (^) use 
'++' to mean appending as well.

(*) string-append, append, vector-append, ...
(^) for example, Coq and Haskell

Best regards,
Maxime Devos.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: overloading an existing operator in Guile

[Jean Abou Samra]

> Le 3 oct. 2023 à 20:35, Maxime Devos <maximedevos@telenet.be> a écrit :
> 
> It's explained in ‘(guile)Methods and Generic Functions’ how to do this.
> 
> However, I very much recommend not doing this in your situation.

+1. I'd recommend only implementing a method foo on a type bar if you are in control of either foo or bar. (Rust has an analogous concept called "trait coherence".)

Re: overloading an existing operator in Guile

[Damien Mattei]

i agree with you all but there is a misunderstanding of what i'm
currently doing.

I'm not making + that append vectors a part of Scheme+, it is just for
a personal program that i want to overload it. This will never be in
Scheme+. (even if python use + for appending list, and list in python
are half way from scheme's vectors and scheme's list, perheaps the
confusion is coming from that)

On Tue, Oct 3, 2023 at 8:41 PM Jean Abou Samra <jean@abou-samra.fr> wrote:
>
>
> > Le 3 oct. 2023 à 20:35, Maxime Devos <maximedevos@telenet.be> a écrit :
> >
> > It's explained in ‘(guile)Methods and Generic Functions’ how to do this.
> >
> > However, I very much recommend not doing this in your situation.
>
> +1. I'd recommend only implementing a method foo on a type bar if you are in control of either foo or bar. (Rust has an analogous concept called "trait coherence".)
>
>