[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GH replacement proposal (includes a bit of Unicode)

From: Marius Vollmer
Subject: Re: GH replacement proposal (includes a bit of Unicode)
Date: Wed, 12 May 2004 22:09:01 +0200
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

Dirk Herrmann <address@hidden> writes:

>>  - scm_t_intmax scm_to_signed_integer (SCM val,
>>                                        scm_t_intmax min, scm_t_intmax max);
>>  - scm_t_uintmax scm_to_unsigned_integer (SCM val, scm_t_uintmax max);
> Since ISO-C99 specifies the intmax_t and uintmax_t typedefs, I would
> prefer to have functions scm_to_intmax and scm_to_uintmax, and have
> them behave similarly to scm_to_int etc. which you describe
> below.

We should have them, but in addition to scm_to_signed_integer and
scm_to_unsigned_integer.  The latter two functions should be the most
general ones that the use can use to easily convert integer types that
are not specifically covered by Guile.  For example, glib provides a
type gint with limits G_MININT and G_MAXINT.  To convert to this type,
you could do

    (gint)scm_to_signed_integer (val, G_MININT, G_MAXINT)

> In addition, it may make sense to use the generic type names signed
> integer and unsigned integer to provide additional functions
> scm_to_signed_integer and scm_to_unsigned_integer that implement the
> very general conversion idea that Gary Houston had proposed in

I like this idea, but I think we should provide it in an even more
general form, converting integers to uniform vectors with a given word
size and endianess.  Using intmax_t should be good enough for all
ordinary integer conversion needs, and much less hairy.

> Alternative 1:
> * change the functions in the following way:
>   <type> scm_to_<type> (SCM value, int *success)
>   Instead of signalling an error, *success indicates whether the value
> can be represented. If *success is 0, the returned value is
> unspecified. If success is NULL, an error is signalled for the case
> that the value can not be represented.

I don't like this very much; I want the fundamental functions to be as
simple as possible.  Passing NULL or (worse), having to pass a valid
pointer add significant noise to the code, and I would like to avoid

> Alternative 2:
> * provide the following additional functions:
>   <type> scm_to_<type>_2 (SCM value, int *success)
>   I have not yet an idea for a good name, thus I have just added the
> _2 postfix.
> Alternative 3:
> * provide the following additional functions:
>   int scm_fits_<type> (SCM value);
>   Return 1 if the value can be converted to a C value of type <type>,
> 0 otherwise. If scm_fits_<type> returns 1 for some value it is
> guaranteed, that a subsequent call to scm_to_<type> does not signal an
> error.

In my opinion, keeping type tests and type conversions separate is the
cleanest approach.  Testing whether an integer fits a given C type
should be quite seldom: what do you do when it doesn't fit?

So, I like alternative 3 best; and I think it will suffice to provide
only two functions:

  int scm_is_unsigned_integer (SCM val,
                               scm_t_uintmax min, scm_t_uintmax max);

  int scm_is_signed_integer (SCM val,
                             scm_t_intmax min, scm_t_intmax max);

> The disadvantage of alternative 3 is, that for a lot of code the
> checking will have to be performed twice: The user will first call
> scm_fits_<type> and then scm_to_<type>. Both, however, will check
> whether the value fits.

Yes, but I don't want to worry about this yet, since I really think
this kind of range checking will not be done significantly often.

>>  - SCM scm_from_complex_double (double re, double im);
>>  - double scm_to_real_part_double (SCM z);
>>  - double scm_to_imag_part_double (SCM z);
>> [...]
> We should be prepared to provide conversion functions for the new
> ISO-C99 types float _Complex, double _Complex, long double _Complex,
> float _Imaginary, double _Imaginary and long double
> _Imaginary. Thus, the naming scheme used above seems a bit confusing
> if we later expect a function scm_from_double_complex to be added.

Hmm, tough.  What about removing scm_from_complex_double completely
and tell people to use

  scm_make_rectangular (scm_from_double (r), scm_from_double (i))

instead?  The scm_from_double_r_double_i scheme looks a bit too
complicated to me.

>>  - SCM scm_from_locale_string (unsigned char *str, ssize_t len);
>>  Return a new Scheme string initialized with STR, a string encoded
>>  according to the current locale.  When LEN is -1, STR must be
>>  zero-terminated and its length is found that way.  Otherwise LEN
>>  gives the length of STR.
> I would prefer to have two functions like scm_from_locale_memory (with
> an unsigned len argument) and scm_from_locale_c_string rather than
> using -1 as a magic number. The same holds for the other
> scm_from_<string-type> functions that you describe below.

Hmm, yes, that might make sense.  However, the -1 idiom is pretty much
standard for this kind of interface, no?

>>  - unsigned char *scm_to_locale_string (SCM str, size_t *lenp);
>>  Convert STR into a C string that is encoded as specified by the
>>  current locale.  Memory is allocated for the C string that can be
>>  freed with 'free'.
>>  When the current locale can not encode STR, an error is signalled.
>>  When LENP is not NULL, the number of bytes contained in the returned
>>  string is stored in *LENP.  The string is zero-terminated, but it
>>  might contain zero characters in the middle.
> Is the terminal zero counted or not?

No, as usual.

>>  - scm_lock_heap ();
>>  - scm_unlock_heap ();
> I urgently suggest that we do not provide such a concept. It makes too
> many implementation details visible to the user (the way, strings are
> implemented internally) and has influences on critical system parts
> (memory management). It is not foreseeable in which way this may
> inhibit further development. From my work on the evaluator I can tell
> you how much leaked implementation details inhibit improvements.

Yeah.  I will withhold this part of the proposal until I have made my
mind up more.  I would only be implemented (for strings) anyway when
we have Unicode support, since only then could
scm_l_get_utf8_string_mem be implemented.

GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405

reply via email to

[Prev in Thread] Current Thread [Next in Thread]