Bad deprecation warnings in numbers.c

Bad deprecation warnings in numbers.c

[Neil Jerram]

There is a group of deprecation warnings in (stable) numbers.c that
say, for example:

  scm_c_issue_deprecation_warning ("`scm_mkbig' is deprecated. "
                                   "Use `scm_i_mkbig' instead.");

No!!!!!

This directly contradicts our aim of using `scm_i_' to mark Guile
internals, which libguile users shouldn't use _at all_!

What's the right thing here?  Could we do it before 1.6?

        Neil


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Bad deprecation warnings in numbers.c

[Dirk Herrmann]

On 1 Apr 2002, Neil Jerram wrote:

> There is a group of deprecation warnings in (stable) numbers.c that
> say, for example:
> 
>   scm_c_issue_deprecation_warning ("`scm_mkbig' is deprecated. "
>                                    "Use `scm_i_mkbig' instead.");
> 
> No!!!!!
> 
> This directly contradicts our aim of using `scm_i_' to mark Guile
> internals, which libguile users shouldn't use _at all_!
> 
> What's the right thing here?  Could we do it before 1.6?

IMO, people should not use any of these functions at all.  We should try 
to remove their use from other places within guile as well.  The reason
is, that these functions depend on the implementation of the bignums,
which should be considered the secret knowledge of the number
implementation.  It is, btw., likely to change in the not too far future,
if for example we manage the switch to the GNU mp library.

Best regards,
Dirk Herrmann


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Bad deprecation warnings in numbers.c

[Neil Jerram]

>>>>> "Dirk" == Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:

    Dirk> On 1 Apr 2002, Neil Jerram wrote:
    >> There is a group of deprecation warnings in (stable) numbers.c that
    >> say, for example:
    >> 
    >> scm_c_issue_deprecation_warning ("`scm_mkbig' is deprecated. "
    >> "Use `scm_i_mkbig' instead.");
    >> 
    >> No!!!!!
    >> 
    >> This directly contradicts our aim of using `scm_i_' to mark Guile
    >> internals, which libguile users shouldn't use _at all_!
    >> 
    >> What's the right thing here?  Could we do it before 1.6?

    Dirk> IMO, people should not use any of these functions at all.
    Dirk> We should try to remove their use from other places within
    Dirk> guile as well.  The reason is, that these functions depend
    Dirk> on the implementation of the bignums, which should be
    Dirk> considered the secret knowledge of the number
    Dirk> implementation.  It is, btw., likely to change in the not
    Dirk> too far future, if for example we manage the switch to the
    Dirk> GNU mp library.

OK, but...

- can you think of any good reasons why developers might have been
  using these functions anyway?

- if there are such reasons, what could we suggest to developers that
  they do instead?

If there are no valid reasons for using these functions, we should
change the messages to say that "this function was never intended to
be part of the libguile API".  (And then the mailing list may later
produce a valid reason for us! :-)

If there are valid reasons, we should change the messages to indicate
what developers should _really_ be doing instead.

Regards,
        Neil


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Bad deprecation warnings in numbers.c

[Dirk Herrmann]

On 13 Apr 2002, Neil Jerram wrote:

>     Dirk> IMO, people should not use any of these functions at all.
>     Dirk> We should try to remove their use from other places within
>     Dirk> guile as well.  The reason is, that these functions depend
>     Dirk> on the implementation of the bignums, which should be
>     Dirk> considered the secret knowledge of the number
>     Dirk> implementation.  It is, btw., likely to change in the not
>     Dirk> too far future, if for example we manage the switch to the
>     Dirk> GNU mp library.
[...]
> If there are no valid reasons for using these functions, we should
> change the messages to say that "this function was never intended to
> be part of the libguile API".  (And then the mailing list may later
> produce a valid reason for us! :-)

IMO that's a good way to go.

Best regards
Dirk Herrmann


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Bad deprecation warnings in numbers.c

[Rob Browning]

Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:

> IMO, people should not use any of these functions at all.  We should
> try to remove their use from other places within guile as well.  The
> reason is, that these functions depend on the implementation of the
> bignums, which should be considered the secret knowledge of the
> number implementation.  It is, btw., likely to change in the not too
> far future, if for example we manage the switch to the GNU mp
> library.

FWIW I've got GMP bignum's working here :> Guile passes make check,
but I've still got a lot of FIXMEs and #warnings to repair.

IMO, scm_i_mkbig probably shouldn't be used by user code and shouldn't
even be in numbers.h unless (as is the case ATM) other libguile code
needs to call it.  (The only way around that I can think of would be
go to a "public/private" header arrangement.)

However, a function like 

  void scm_num2mpz(mpz_t dest, SCM src);

(or similar) might not be a bad idea.  We could continue to provide it
in libguile or in a helper lib indefinitely, no matter what our
internal representation is.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Bad deprecation warnings in numbers.c

[Dirk Herrmann]

On Sun, 14 Apr 2002, Rob Browning wrote:

> FWIW I've got GMP bignum's working here :> Guile passes make check,
> but I've still got a lot of FIXMEs and #warnings to repair.

Sounds great.

> IMO, scm_i_mkbig probably shouldn't be used by user code and shouldn't
> even be in numbers.h unless (as is the case ATM) other libguile code
> needs to call it.  (The only way around that I can think of would be
> go to a "public/private" header arrangement.)
> 
> However, a function like 
> 
>   void scm_num2mpz(mpz_t dest, SCM src);
> 
> (or similar) might not be a bad idea.  We could continue to provide it
> in libguile or in a helper lib indefinitely, no matter what our
> internal representation is.

I like this idea.  However, I favor the 'helper lib' approach.

Best regards
Dirk Herrmann


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile