User perception on backward compatibility

User perception on backward compatibility

[Ludovic Courtès]

Hello!

I think the next big task will be to list and try to reduce
incompatibilities compared to 1.8.

For the record, here’s what I found in GNU Dico; it’s interesting to see
how its maintainer feels about backward compatibility in Guile:

  http://mail.gnu.org.ua/archives/html/public/bug-dico/threads.html#00000

Thanks,
Ludo’.

Re: User perception on backward compatibility

[Thien-Thi Nguyen]

() ludo@gnu.org (Ludovic Courtès)
() Thu, 21 Jan 2010 11:54:51 +0100

   I think the next big task will be to list and try to reduce
   incompatibilities compared to 1.8.

Yes, please.

At the moment, i would ask you to look at the guile-user message
w/ subject "(define ((f a) b) ...)".

thi

Re: User perception on backward compatibility

[Ludovic Courtès]

Hi,

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> At the moment, i would ask you to look at the guile-user message
> w/ subject "(define ((f a) b) ...)".

I didn’t reply on the grounds that Andy may have his views on this.  :-)

Thanks,
Ludo’.

Re: User perception on backward compatibility

[Mike Gran]

> From: Ludovic Courtès <ludo@gnu.org>

> 
> Hello!
> 
> I think the next big task will be to list and try to reduce
> incompatibilities compared to 1.8.
> 
> For the record, here’s what I found in GNU Dico; it’s interesting to see
> how its maintainer feels about backward compatibility in Guile:
> 
>   http://mail.gnu.org.ua/archives/html/public/bug-dico/threads.html#00000

Guile's API has always fairly incompatibly from revision to 
revision.  Each rev always requires a significant rewrite of the glue
code in Guile-using projects.

Just in the time that I've been using Guile, I've used four different 
functions to convert an integer into a guile number: gh_int2scm, 
SCM_MAKINUM, scm_int2num, scm_from_int.

A lot of projects have their own Guile compatibility layers to map
current practice to a consistent API: AutoGen, Geda, even Gucu.

Maybe we need a gnulib-like project for guile ;-)

So, yeah, reducing incompatibilities might be nice.

Thanks,
Mike

Re: User perception on backward compatibility

[Ludovic Courtès]

Hi Mike,

Mike Gran <spk121@yahoo.com> writes:

> Guile's API has always fairly incompatibly from revision to 
> revision.  Each rev always requires a significant rewrite of the glue
> code in Guile-using projects.

s/revision/major version/.  Fortunately, major versions are pretty rare,
but I get your point, of course.

> Just in the time that I've been using Guile, I've used four different 
> functions to convert an integer into a guile number: gh_int2scm, 
> SCM_MAKINUM, scm_int2num, scm_from_int.

That’s partly because until 1.8, and to a lesser extent now, there has
been a poor separation between the internal API and the public API,
along with incomplete documentation.  I think 1.8 has been a noticeable
improvement on both fronts, and we can probably do better
(‘SCM_INTERNAL’ and the GNU ld version script are good tools to formally
separate public from private APIs and version them.)

> A lot of projects have their own Guile compatibility layers to map
> current practice to a consistent API: AutoGen, Geda, even Gucu.
>
> Maybe we need a gnulib-like project for guile ;-)

Heh.

> So, yeah, reducing incompatibilities might be nice.

I sympathize and encourage people to report (and fix) incompatibilities
introduced in 1.9.  :-)

Looking at http://hydra.nixos.org/jobset/nixpkgs/guile2test already
gives a good idea of things to look at.

Thanks,
Ludo’.

Re: User perception on backward compatibility

[Sergey Poznyakoff]

Mike Gran <spk121@yahoo.com> ha escrit:

> Maybe we need a gnulib-like project for guile ;-)

Oh, no. That'd be an overkill, really :^) But retaining the old
interfaces for at least a couple of revisions, since introduction of
the new ones, will be very helpful (the current practice of
issuing deprecation warnings is quite OK).

Regards,
Sergey

Re: User perception on backward compatibility

[Kjetil S. Matheussen]

Thien-Thi Nguyen:
>
>   I think the next big task will be to list and try to reduce
>   incompatibilities compared to 1.8.
>
> Yes, please.
>
> At the moment, i would ask you to look at the guile-user message
> w/ subject "(define ((f a) b) ...)".
>

I agree about this. IMO it's very elegant, and also
(probably) the simplest way to expand define:

(define-macro (define def . rest)
   (if (pair? def)
       `(define ,(car def)
 	 (lambda ,(cdr def)
 	   ,@rest))
       `(internal-define ,def ,@rest)))

=> (macroexpand '(define ((f a) b) ...))
(internal-define f (lambda (a) (lambda (b) ...)))

Re: User perception on backward compatibility

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi,
>
> Thien-Thi Nguyen <ttn@gnuvola.org> writes:
>
>> At the moment, i would ask you to look at the guile-user message
>> w/ subject "(define ((f a) b) ...)".
>
> I didn’t reply on the grounds that Andy may have his views on this.  :-)

I think it just needs a bit of define-syntax.

As it happens, the definition of define-public has the required form:

(define-syntax define-public
  (syntax-rules ()
    ((_ (name . args) . body)
     (define-public name (lambda args . body)))
    ((_ name val)
     (begin
       (define name val)
       (export name)))))

and it works:

scheme@(guile-user)> (define-public ((f a) b) (* a b))
scheme@(guile-user)> (f 2)
#<program a117550 (b)>
scheme@(guile-user)> ((f 2) 3)
6

But I completely agree that we want `define' to support that too, `out
of the box'.

What is the correct way of writing something like this in boot-9.scm?

(define-syntax primitive-define define)

(define-syntax define
  (syntax-rules ()
    ((_ (name . args) . body)
     (define name (lambda args . body)))
    ((_ name val)
     (begin
       (primitive-define name val)
       (export name)))))

Regards,
      Neil

Re: User perception on backward compatibility

[Peter Brett]

Mike Gran <spk121@yahoo.com> writes:

> A lot of projects have their own Guile compatibility layers to map
> current practice to a consistent API: AutoGen, Geda, even Gucu.

gEDA 1.6.x doesn't have a compatibility layer -- we only support Guile
1.8.x at the moment.  However, we're still using a bunch of API that's
deprecated in 1.8.x.

OTOH if there are major changes in the C API in 2.x (particularly the
mechanisms for converting strings and numbers to/from SCM
representation) I will likely go postal.

                                     Peter

-- 
Peter Brett <peter@peter-b.co.uk>
Remote Sensing Research Group
Surrey Space Centre