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

[Marius Vollmer <marius.vollmer@uni-dortmund.de>]

prj@po.cwru.edu (Paul Jarc) writes:

> Marius Vollmer <marius.vollmer@uni-dortmund.de> wrote:
>> I have a partial proposal for making type conversions between Scheme
>> and C easier.
>
> Looks nice & clean.

Thanks, do you think it worth implementing (and thereby deprecting the
old stuff)?

>>   - macro-free so that we can maintain binary compatibility easier
>
> Well, macros don't cause problems as long as the underlying functions
> (if any) also keep the same interface, right?  Has there been much
> change of, or pressure to change, those interfaces with the current
> macros?

I agree that this is not the most important point: there wont be
binary compatability between 1.6 and 1.8 anyway.  But of course, it
would be nice to have easier binary compatability in the future.

>> Then there is the error handling: the functions below do not take
>> "subr" or "pos" arguments to indicate where the error has happened.  I
>> don't think they are really needed and in any case only provides part
>> of the backtrace.
>
> I have some code that benefits from having the subr name in the
> exception - in the case of 'system-error, it walks the stack to find
> and report the call that failed, including arguments.

Can you give a quick example?  (Does it walk the C stack and prints
the failed system call?)

>> * Conversion from Scheme to C
>>
>>     <type> scm_to_<type> (SCM val, ...);
>>
>> ("convert Scheme to <type>".)  When VAL is not representable as a
>> <type> or additional constraints are not satisfied, an error is
>> signalled.
> ...
>>   - int scm_to_bool (SCM);
>>   - int scm_is_true (SCM);
>>
>>     Return 0 when SCM is SCM_BOOL_F, else return 1.
>
> That sounds good for scm_is_true, but maybe scm_to_bool should throw
> an exception if given a value other than SCM_BOOL_[TF], for
> consistency with other scm_to_* functions.

Hmm, I don't think we should do that.  There is nothing to be gained
in treating SCM_BOOL_T specifically here.  Everywhere else, all values
except SCM_BOOL_F are true, so why should we force the explicit use of
SCM_BOOL_T with scm_to_bool?

Maybe we should't have scm_to_bool and scm_is_bool at all?
scm_is_true (and maybe scm_is_false) should suffice.

>>  - SCM scm_is_bool (SCM val);
> ...
>>   - SCM scm_is_integer (SCM val);
>
> Those should return int, right?

Yes, thanks!

>>   - 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);
>
> Wouldn't a min parameter sometimes be useful for unsigned values too?

Yes, maybe.  I'll add it.

>>   - long scm_to_unicode (SCM ch);
>>   - SCM  scm_from_unicode (long code);
>
> long, or unsigned long?  Does Unicode need negative values?

No, Unicode does not need negative values (as far as I know).  I'll
make this unsigned.

>>   - 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.
>
> Maybe it doesn't matter much, but len could be size_t, and (size_t)-1
> could be the only special value, instead of losing a whole bit to
> signedness.

It doensn't matter much, there wont likely ever be support for strings
that are longer than 31 bits worth of length (or 63 bits).  Right now,
strings have only 24 bits for their length (or 56 bits).  But yes, we
shouldn't restrict us in the interface, so I'll change LEN to size_t.

We should also specify the units of LEN...

>>   The heap should not be locked for long periods of time and no
>>   calls to 'normal' libguile functions are allowed while it is
>>   locked.
>
> What happens if one is called anyway?  Exception, or undefined
> behavior?

Undefined behavior.  The function will likely try to lock/unlock the
heap again and that might crash or unlock the heap too early, etc...

>>   - SCM scm_c_list_ref (SCM list, int idx);
>>   - SCM scm_c_list_set (SCM list, int idx, SCM val);
>>   - int scm_c_list_length (SCM list);
>
> I'd suggest size_t instead of int.  Same for vectors.

Yes, much better.


Thanks!


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel