GH replacement proposal (includes a bit of Unicode)

GH replacement proposal (includes a bit of Unicode)

[Marius Vollmer]

Hi,

I have a partial proposal for making type conversions between Scheme
and C easier.

The first question is, do we need something different?  Is the stuff
below better enough to be worth the trouble of making everyone switch
to it?

I think it does improve upon the existing situation by being

  - thread safe (allowing true concurrency)
  - more consistent
  - allowing sophisticated internal data representation (for example
    for copy-on-write substrings, Unicode, etc.)
  - macro-free so that we can maintain binary compatibility easier


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.


Opinions?

-----

One important part of the Guile API is concerned with the conversion
between Scheme values and C values.  The functions that perform these
conversions follow a common pattern.

* Type predicates

Type predicates for C code are named like this

    int scm_is_<type> (SCM val);

They return 0 or 1. 

There are also the usual predicates that return a Scheme boolean, such
as scm_string_p.

* Conversion from C to Scheme

For a C type <type>, the function that converts it into a Scheme value
looks like

    SCM scm_from_<type> (<type> val, ...);

This function could be pronounced as "make Scheme from <type>" to
remember that the conversion is from <type> to a Scheme object.
No error will usually be signalled, except when not enough memory is
available.

Sometimes a function named

    SCM scm_take_<type> (<type> val, ...);

is provided.  ("let Scheme take <type>".)  This function works like
scm_from_<type> but the memory associated with VAL will be taken over
by Guile.

* 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.

* Concrete functions

** Booleans

  - SCM scm_is_bool (SCM val);

  - SCM scm_from_bool (int val);

    Return SCM_BOOL_T when val in non-zero, else return SCM_BOOL_F.

  - int scm_to_bool (SCM);
  - int scm_is_true (SCM);

    Return 0 when SCM is SCM_BOOL_F, else return 1.

** Integers

  - SCM scm_is_integer (SCM val);

  Determine whether VAL is an integer, exact or inexact.  Note that
  the number 3.0 is an inexact integer although it is stored as a
  double.

  - SCM scm_from_signed_integer (scm_t_intmax val);
  - SCM scm_from_unsigned_integer (scm_t_uintmax val);

    Return the SCM value representing the integer <val>.  The SCM
    value will always be exact.

  - 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);
    
    Convert the SCM value VAL to a C integer when it is representable
    and when it is between min and max inclusive, or between 0 and max
    inclusive.  Signal an error when it isn't.  The SCM value can be
    exact or inexact, but it must be an integer.  That is,

       scm_to_signed_integer (scm_from_double (3.0), -100, +100)

    yields the C integer 3 while

       scm_to_signed_integer (scm_from_double (3.5), -100, +100)

    is an error.

  - SCM scm_from_char (signed char);
  - SCM scm_from_short (short);
  - SCM scm_from_int (int val);
  - SCM scm_from_long (long val);
  - SCM scm_from_longlong (long long val);
  - SCM scm_from_ssize (ssize_t val);
    ...

  - SCM scm_from_uchar (unsigned char);
  - SCM scm_from_ushort (unsigned short);
  - SCM scm_from_uint (unsigned int val);
  - SCM scm_from_ulong (unsigned long val);
  - SCM scm_from_ulonglong (unsigned long long val);
  - SCM scm_from_size (size_t val);
    ...

  - signed char        scm_to_char (SCM);
  - short              scm_to_short (SCM);
  - int                scm_to_int (SCM);
  - long               scm_to_long (SCM);
  - long long          scm_to_longlong (SCM);
  - ssize_t            scm_to_ssize (SCM);
    ...

  - unsigned char      scm_to_uchar (SCM);
  - unsigned short     scm_to_ushort (SCM);
  - unsigned int       scm_to_uint (SCM);
  - unsigned long      scm_to_ulong (SCM);
  - unsigned long long scm_to_ulonglong (SCM);
  - size_t             scm_to_size (SCM);
    ...

    Convert from/to the indicated integral types, signalling errors
    when the SCM value can not be represented.  For integer types that
    are not provided for, you can use the general functions from
    above.  For example, scm_from_short (x) is the same as

        scm_from_signed_integer ((short)(x))

    and scm_to_short (x) is the same as

        ((short)(scm_to_signed_integer (x, SHORT_MIN, SHORT_MAX)))

    Thus, these functions are merely a convenience.

    Note that scm_to_char can not convert a Scheme character to a C
    char integer.  See below.

** Floating point numbers

We don't go to such a great length to cover all possible types
here. "double" ought to be enough, no?

  - int scm_is_real (SCM val);

  Determine whether VAL is a real number, inexact or exact.  Note that
  a number such as 1/3 or 0 is real, although it is not stored as a
  double.

  - SCM scm_from_double (double val);

    Return the SCM value corresponding to VAL.  The SCM value will be
    'inexact' as far as scm_inexact_p is considered but will be
    exactly equal to VAL.  When you want to have an exact SCM value,
    use

        scm_inexact_to_exact (scm_from_double (val))

    this will yield an exact fraction.

  - double scm_to_double (SCM);

    Convert VAL to the closest number representable as a double.
    Numbers that are too large or too small are converted into +Inf or
    -Inf, respectively.

** Complex numbers

  - int scm_is_complex (SCM val);

  Determine whether VAL is a complex number, inexact or exact.  Note
  that a number such as 1/3 is complex, although it is not stored as
  two doubles.

Complex numbers can be regarded as a compound type and need no
dedicated conversion functions.  For example, you can do

    scm_make_rectangular (scm_from_double (0.0), scm_from_double (1.0))

or

    double imag = scm_to_double (scm_imag_part (z));

but there are also convenience functions that are actually a bit more
efficient:

  - 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);

But remember to use the generic functions scm_make_rectangular,
scm_real_part, etc if you don't care whether the parts of a complex
number are floating point numbers or not.  For example, Guile might
someday offer complex numbers where the real part is a fraction
(currently it is always a double) and it is good to be prepared for
this by not treating the parts of a complex as doubles when it is not
needed.

** Characters

A Scheme character in Guile is equivalent to a Unicode code point.

  - int scm_is_character (SCM val);
  - long scm_to_unicode (SCM ch);
  - SCM  scm_from_unicode (long code);

** Strings

Strings present the new problem that memory needs to be allocated or
found for storing the result.  Also, when new memory has been
allocated, one needs to make sure that it isn't leaked in the case of
non-local exits (like from errors in subsequent conversions).  Such a
cleanup action can be registered with scm_frame_unwind_handler, which
see.

  - int scm_is_string (SCM val);

  - 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.

  - SCM scm_from_utf8_string (unsigned char *str, ssize_t len);

  Same as above, but STR is encoded in UTF-8.  Future versions of
  Guile will use UTF-8 internally and then this function will not need
  to perform any conversions at all.

  - SCM scm_take_utf8_string (unsigned char *str, ssize_t len);

  Same as above, but the memory for STR is taken over by Guile.  It
  will eventually be freed using libc 'free'.

  - 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.

  When LENP is NULL and the string does indeed contain a zero
  character, it is not encodable and an error is signalled.

  - unsigned char *scm_to_utf8_string (SCM str, size_t *lenp);

  Same as above but returns a UTF-8 encoded string.  This will always
  work when LENP is non-NULL.

  [ More encodings can be specified later, for example by just
    referring to the character sets supported by 'iconv'.  The above
    two, locale and utf8, are needed for transitioning Guile to
    Unicode.  Right now, strings are in the locale encoding but in the
    future they will be in UTF-8. ]

The above functions always return newly allocated memory.  When that
is deemed too expensive, the following functions can be used instead.
However, care must be taken to use them correctly and reasonably.

  - scm_lock_heap ();
  - scm_unlock_heap ();

  These two functions lock and unlock all SCM objects (the heap).  The
  heap should not be locked for long periods of time and no calls to
  'normal' libguile functions are allowed while it is locked.  A
  function is 'normal' unless it is specifically documented to be
  useable with a locked heap.  (Indeed, most 'unnormal' functions can
  _only_ be used while the heap is locked.)

  You can not lock the heap twice.  Calling scm_lock_heap while the
  heap is already locked results in undefined behavior.  Likewise,
  calling scm_unlock_heap when the heap is not locked is verboten.

  - const unsigned char *scm_l_get_utf8_string_mem (SCM str);

  Return a pointer to the internal UTF-8 bytes of STR.  This function
  can only be called while the heap is locked and the returned pointer
  becomes invalid when the heap is unlocked later on.  The string is
  _not_ guaranteed to be zero-terminated, you _must_ use
  scm_l_get_utf8_string_len (see below).

  You are not allowed to modify the string contents.

  (The "scm_l_" prefix denotes a function that must be called with a
  locked heap.)

  - size_t scm_l_get_utf8_string_len (SCM str);

  Return the length in bytes of STR.  Heap must be locked.

** Symbols
  
Symbols have strings as their names and you can get that name via
scm_symbol_to_string.  However, it is more efficient to convert
to/from a symbol directly.

  - int scm_is_symbol (SCM val);
  - SCM scm_from_locale_symbol (unsigned char *str, ssize_t len);
  - SCM scm_from_utf8_symbol (unsigned char *str, ssize_t len);
  - SCM scm_take_utf8_symbol (unsigned char *str, ssize_t len);
  - unsigned char *scm_to_locale_symbol (SCM str, size_t *lenp);
  - unsigned char *scm_to_utf8_symbol (SCM str, size_t *lenp);
  - const unsigned char *scm_l_get_utf8_symbol_mem (SCM str);
  - size_t scm_l_get_utf8_symbol_len (SCM str);

** Uniform vectors

[ Uniform vectors should get the same kind of support as strings, but
without the encoding business of course. ]

  - int scm_is_u8vector (SCM val);
  - SCM scm_from_u8vector (unsigned char *vec, size_t len);
  - SCM scm_take_u8vector (unsigned char *vec, size_t len);
  - unsigned char *scm_to_u8vector (SCM vec, sizte_t *lenp);
  - unsigned char *scm_l_get_u8vector_mem (SCM vec);
  - size_t scm_l_get_u8vector_len (SCM vec);

  etc.

** Compound types

  - int scm_is_pair (SCM val);
  - SCM scm_car (SCM pair);
  - SCM scm_cdr (SCM pair);

  - int scm_is_list (SCM val);
  - 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);

  - int scm_is_vector (SCM val);
  - SCM scm_c_vector_ref (SCM vec, int idx);
  - SCM scm_c_vector_set (SCM vec, int idx, SCM val);
  - int scm_c_vector_length (SCM vec);

Additional types can be handled with code like

  if (scm_from_bool (scm_procedure_p (val)))
    ...



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

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

[Paul Jarc]

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.

>   - 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?

> 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.

Nits to follow...

> * 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.

>  - SCM scm_is_bool (SCM val);
...
>   - SCM scm_is_integer (SCM val);

Those should return int, right?

>   - 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?

>   - long scm_to_unicode (SCM ch);
>   - SCM  scm_from_unicode (long code);

long, or unsigned long?  Does Unicode need negative values?

>   - 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.

>   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?

>   - 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.


paul


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

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

[Marius Vollmer]

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

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

[Paul Jarc]

[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]

Marius Vollmer <marius.vollmer@uni-dortmund.de> wrote:
> Thanks, do you think it worth implementing (and thereby deprecting the
> old stuff)?

As long as the old stuff isn't removed gratuitously, I'd say go for
it.  But maybe profile some code both ways to see if the function call
overhead is significant.  The current macro type predicates just
examine the bits of the SCM value, without even following a pointer,
right?  OTOH, these functions could be implemented as macros too, if
the performance gain was significant, so that shouldn't necessarily
affect the decision of whether to use the new API.

>> 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?)

No, just the Scheme stack.  See exit-for-system-error in the attached
file.
guile> (exit-for-system-error "myprog" (lambda () (delete-file "/foo")))
myprog: unlink("/foo"): No such file or directory

(There's a hard-coded mapping of "delete-file" -> "unlink", etc.)

> Hmm, I don't think we should do that.  There is nothing to be gained
> in treating SCM_BOOL_T specifically here.

Well, maybe just a little bit special - scm_to_bool could map #f -> 0,
#t -> 1, everything else -> 2.  That could be useful for something
like format.

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

Consistency with the functions for other types would dictate that
there should be only is_bool and to_bool, and not is_true or is_false.
OTOH, each of them could help code readability in different cases, so
I'd include them all.  None of them should be very hard to write or
maintain.


paul

[-- Attachment #2: errors.scm --]
[-- Type: text/plain, Size: 4749 bytes --]

(use-modules ((srfi srfi-1)  :select (find)))
(use-modules ((srfi srfi-13) :select
              (string-append/shared substring/shared string-join)))
(use-modules ((ice-9 format) :select (format)))

(define call/cc call-with-current-continuation)

(define (exception-argument key value)
  value)

(define (die message)
  (display (string-append/shared message "\n") (current-error-port))
  (flush-all-ports)
  (exit 100))

(define primitive-apply
  (call/cc
   (lambda (return)
     (define (raise-error)
       (apply execlp '()))
     (define (lazy-handler . exception)
       (let* ((stack (make-stack #t lazy-handler))
              (frame (and (stack? stack) (stack-ref stack 0)))
              (proc (and (frame? frame) (frame-procedure frame))))
         (return proc)))
     (lazy-catch #t raise-error lazy-handler))))

(define-macro (defined-values&forms . flags)
  (if (null? flags)
    ''()
    (let ((flag (car flags))
          (rest `(defined-values&forms . ,(cdr flags))))
      (if (defined? flag)
        `(cons (cons ,flag ',flag) ,rest)
        rest))))

(define synonyms
  '((open-fdes open)))

(define subst
  '((open-fdes      . open)
    (delete-file    . unlink)
    (primitive-exit . exit)
    (primitive-fork . fork)))

(define (printer:fdes-flags flags)
  (let ((output-string ""))
    (define (output-append string)
      (set! output-string (string-append/shared output-string "|" string)))
    (define (output val-sym)
      (let* ((flag (car val-sym))
             (intersection (logand flags flag)))
        (and (= intersection flag)
             (begin
               (set! flags (- flags flag))
               (output-append (symbol->string (cdr val-sym)))
               #t))))
    (find     output (defined-values&forms O_RDWR O_WRONLY O_RDONLY))
    (for-each output (defined-values&forms
                       O_CREAT O_EXCL O_APPEND O_TRUNC O_NONBLOCK
                       O_NDELAY O_NOCTTY O_SYNC))
    (if (not (zero? flags))
      (output-append (format #f "0x~x" flags)))
    (substring/shared output-string 1)))

(define arg-printers `(((open . 1) . ,printer:fdes-flags)))

(define (find-args frame proc-name/string proc-syns)
  (let* ((proc? (frame-procedure? frame))
         (frame-args      (and proc? (frame-arguments frame)))
         (frame-proc      (and proc? (frame-procedure frame)))
         (frame-proc-name (and proc? (procedure-name frame-proc)))
         (prev (frame-previous frame)))
    (cond
     ((and proc? (memq frame-proc-name proc-syns))
      frame-args)
     ((and proc?
           (eq? frame-proc primitive-apply)
           (procedure? (car frame-args))
           (memq (procedure-name (car frame-args)) proc-syns))
      (cadr frame-args))
     (else
      (and prev (find-args prev proc-name/string proc-syns))))))

(define (print-args proc proc-args)
  (if proc-args
    (let loop ((i (1- (length proc-args)))
               (l '()))
      (if (< i 0)
        l
        (loop (1- i)
              (cons
               (let* ((key (cons proc i))
                      (printer (assoc-ref arg-printers key))
                      (printer (or printer object->string)))
                 (printer (list-ref proc-args i)))
               l))))
    '("unknown arguments")))

(define (exit-for-system-error program-name thunk)
  (define (lazy-handler . exception)
    (let* ((proc-name/string (cadr exception))
           (proc-name (string->symbol proc-name/string))
           (proc-syns (or (find (lambda (syn) (memq proc-name syn))
                                synonyms)
                          (list proc-name)))
           (stack (make-stack #t lazy-handler))
           (frame (and (stack? stack) (stack-ref stack 0)))
           (proc-args (and (frame? frame)
                           (find-args frame proc-name/string proc-syns)))
           (proc-name (or (assq-ref subst proc-name) proc-name))
           (errno (system-error-errno exception))
           (status (if (memq errno (list ENOMEM ETXTBSY EIO ENFILE))
                     111 100)))
      (display (string-append/shared
                program-name ": " (symbol->string proc-name) "("
                (string-join (print-args proc-name proc-args) ", ")
                "): " (strerror errno) "\n")
               (current-error-port))
      (flush-all-ports)
      (exit status)))
  (lazy-catch 'system-error thunk lazy-handler))

(define (system-error-case thunk error-values)
  (call/cc
   (lambda (return)
     (define (lazy-handler . exception)
       (let* ((errno (system-error-errno exception))
              (entry (assq errno error-values)))
         (if entry
           (return (cdr entry))
           (apply throw exception))))
     (lazy-catch 'system-error thunk lazy-handler))))

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

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

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

[Dirk Herrmann]

Hello Marius,

in general, a nice proposal. I have some suggestions and comments, though.

Marius Vollmer wrote:

>  - int scm_to_bool (SCM);
>  - int scm_is_true (SCM);
>
>    Return 0 when SCM is SCM_BOOL_F, else return 1.
>
I would only provide the scm_to_bool variant. There is IMO no benefit in 
having two functions which do exactly the same thing. Providing these 
two might give the impression that there is some difference in them. 
Further, there is always the question whether scm_is_true checks for any 
true value or explicitly for SCM_BOOL_T. Things would be clearer if 
instead of scm_is_true the function provided would be scm_is_false, but 
given scm_to_bool, I see no reason for providing it. Thus, just leave it 
with scm_to_bool.

>** Integers 
>
>  - SCM scm_is_integer (SCM val);
>
Paul has already commented on the return type typo.

>  - 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. IMO, the 
boundary checking feature is somewhat too specific. This does, however, 
not mean that internally we could not use a helper function / macro that 
implements the functions in this way.

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 
http://mail.gnu.org/archive/html/guile-devel/2001-09/msg00290.html.

>    Convert the SCM value VAL to a C integer when it is representable
>    and when it is between min and max inclusive, or between 0 and max
>    inclusive.  Signal an error when it isn't.  [...]
>
I think your suggestion that scm_to_<integer-type> should throw an error 
if the value can not be represented is good, since such errors shall not 
go unnoticed. For development convenience, however, I would like to have 
an easy possibility to figure out whether a value can be represented or 
not, since it is a lot of fuss for a developer to capture errors. Thus 
we should consider the following possibilities for extension / 
modification of your proposal:

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.
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.

The advantage of alternative 1 is, that it does not add additional 
functions to the API. Further, it is always clear to the user that the 
conversion may fail. If the user does not care about failure, it is 
possible to pass the NULL pointer for the success argument.

The advantage of alternative 2 is, that the user may choose whether the 
error checking is of interest or not. Further, the scm_to_<type> 
functions can easily be implemented using the scm_to_<type>_2 functions. 
The disadvantage is, that there are a lot of additional API functions, 
and that it is not easy to find good names to distinguish between the 
two kinds of functions.

The advantage of alternative 3 is, that the scm_fits_<type> check may be 
used as a predicate, even if no actual conversion is desired by the 
user. 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.

Thus, I would prefer either alternative 1 or 2, favoring alternative 1.

>** Floating point numbers
>
>We don't go to such a great length to cover all possible types
>here. "double" ought to be enough, no?
>
According to ISO-C99 there are the types float, double and long double. 
For the moment I agree that double would be sufficient. And, since the 
naming pattern is quite symmetric, it would not be a problem to extend 
it to float and long double, if there would be interest in the community.

>  - 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);
>
>But remember to use the generic functions scm_make_rectangular,
>scm_real_part, etc if you don't care whether the parts of a complex
>number are floating point numbers or not.  For example, Guile might
>someday offer complex numbers where the real part is a fraction
>(currently it is always a double) and it is good to be prepared for
>this by not treating the parts of a complex as doubles when it is not
>needed.
>
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. What about using the 
pattern scm_from_<type>_r_<type>_i if a complex is to be constructed 
from separately given real and imaginary parts, and scm_from_<type> if a 
complex is to be constructed from one value? This would allow for a lot 
of combinations, e. g. the first  function from your proposal would be 
renamed to scm_from_double_r_double_i, other possibilities could be 
scm_from_float_complex, scm_from_double_r_imaginary_i etc.. Not that 
these are needed today, but the naming scheme should from the start be 
designed to be open for such extensions.

>** Characters
>
>A Scheme character in Guile is equivalent to a Unicode code point.
>
Yes!

>  - 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.

>  - 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?

>The above functions always return newly allocated memory.  When that
>is deemed too expensive, the following functions can be used instead.
>However, care must be taken to use them correctly and reasonably.
>
>  - 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.

Best regards
Dirk



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

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

[Marius Vollmer]

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

> Marius Vollmer <marius.vollmer@uni-dortmund.de> wrote:
>> Thanks, do you think it worth implementing (and thereby deprecting the
>> old stuff)?
>
> As long as the old stuff isn't removed gratuitously, I'd say go for
> it.

The old stuff will not be removed from Guile, but from the main body
of the manual.

> But maybe profile some code both ways to see if the function call
> overhead is significant.  The current macro type predicates just
> examine the bits of the SCM value, without even following a pointer,
> right?  OTOH, these functions could be implemented as macros too, if
> the performance gain was significant, so that shouldn't necessarily
> affect the decision of whether to use the new API.

Yes, right.  What about inline functions?  We already use them for
scm_cell and scm_double_cell, we can use them for converting fixnums
as well, for example.

>>> 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?)
>
> No, just the Scheme stack.  See exit-for-system-error in the attached
> file.

I see.  You will still get the name of the subr that has been called
directly from Scheme, but not any names further down the call chain.
For example,

  SCM
  subr2 (SCM x)
  {
    ... scm_to_int (x) ...
  }

  SCM
  subr1 (SCM x)
  {
    return subr (x);
  }

  guile> (subr1 #f)

will cause something like

  In procedure subr1 in expression (subr1 #f):
  Wrong type argument: #f

instead of

  In procedure subr2 in expression (subr1 #f):
  Wrong type argument in position 1: #f

>> Hmm, I don't think we should do that.  There is nothing to be gained
>> in treating SCM_BOOL_T specifically here.
>
> Well, maybe just a little bit special - scm_to_bool could map #f -> 0,
> #t -> 1, everything else -> 2.  That could be useful for something
> like format.

If you really want to check for #t, you should use 'eq?', I'd say:

  scm_is_eq (x, SCM_BOOL_T)

>> Maybe we should't have scm_to_bool and scm_is_bool at all?
>> scm_is_true (and maybe scm_is_false) should suffice.
>
> Consistency with the functions for other types would dictate that
> there should be only is_bool and to_bool, and not is_true or is_false.
> OTOH, each of them could help code readability in different cases, so
> I'd include them all.  None of them should be very hard to write or
> maintain.

Yes, well.  I haven't made my mind up yet, but I tend to just use
scm_is_true and scm_is_false.  It's not a big problem to be a little
unsymmetric, I'd say.


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

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

[Paul Jarc]

Marius Vollmer <marius.vollmer@uni-dortmund.de> wrote:
> The old stuff will not be removed from Guile, but from the main body
> of the manual.

Ok.

> What about inline functions?  We already use them for scm_cell and
> scm_double_cell, we can use them for converting fixnums as well, for
> example.

Sounds good.

> will cause something like
>
>   In procedure subr1 in expression (subr1 #f):
>   Wrong type argument: #f
>
> instead of
>
>   In procedure subr2 in expression (subr1 #f):
>   Wrong type argument in position 1: #f

Which means, if subr1 calls more than one system functions that could
fail, I won't know what operation failed or what its arguments were,
unless I know a lot about subr1. :(

Could Guile provide a portable interface to walk the C stack?  (And
would the innermost part of the C stack still be there after an
exception?)  Or could all this information be included exception
values, at least for system-error?

> If you really want to check for #t, you should use 'eq?', I'd say:
>
>   scm_is_eq (x, SCM_BOOL_T)

That works too.  I don't feel very strongly about it either way.


paul


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

Delivery failure (guile-devel@gnu.org)

[Bruce Korb]

Your message has encountered delivery problems
to the following recipient(s):

guile-devel@gnu.org
Delivery failed
550 Invalid address in message header

Final-Recipient: rfc822; guile-devel@gnu.org
Action: failed
Status: 2.0.0 (Success - no additional status information available)
Remote-MTA: dns; mx20.gnu.org
Diagnostic-Code: smtp; 550 Invalid address in message header

Date: Wed, 21 Apr 2004 09:30:55 -0700
Subject: Re: GH replacement proposal (includes a bit of Unicode)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Marius Vollmer wrote:

> Yes, well.  I haven't made my mind up yet, but I tend to just use
> scm_is_true and scm_is_false.  It's not a big problem to be a little
> unsymmetric, I'd say.

I'd disagree.  Any lack of symmetry requires increased knowledge
and more care in usage.  So, if ``scm_is_<type>'' is implemented
for nearly all types, then it needs to be implemented for them all.
"All types except for bool" is too hard to remember.



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

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

[Marius Vollmer]

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

>> will cause something like
>>
>>   In procedure subr1 in expression (subr1 #f):
>>   Wrong type argument: #f
>>
>> instead of
>>
>>   In procedure subr2 in expression (subr1 #f):
>>   Wrong type argument in position 1: #f
>
> Which means, if subr1 calls more than one system functions that could
> fail, I won't know what operation failed or what its arguments were,
> unless I know a lot about subr1. :(

Well, yes.  But you don't get much more information now.  Unless you
know much about subr1, knowing that the first argument to subr2 is
wrong doesn't help much.

> Could Guile provide a portable interface to walk the C stack?

That would be ideal, yes.  We already have something like it for
producing Scheme backtraces: they are done by walking the C stack, but
with help from the C code.

I'm feeling a bit uneasy about this too...

> (And would the innermost part of the C stack still be there after an
> exception?)

Yes, not after the exception but it can be gathered just before
trowing, like we do it now for the Scheme backtrace.

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


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

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

[Marius Vollmer]

Bruce Korb <bkorb@veritas.com> writes:

> Marius Vollmer wrote:
>
>> Yes, well.  I haven't made my mind up yet, but I tend to just use
>> scm_is_true and scm_is_false.  It's not a big problem to be a little
>> unsymmetric, I'd say.
>
> I'd disagree.  Any lack of symmetry requires increased knowledge
> and more care in usage.  So, if ``scm_is_<type>'' is implemented
> for nearly all types, then it needs to be implemented for them all.
> "All types except for bool" is too hard to remember.

Yeah, point well taken.

Sooo, right now I'm wembleying towards having

 scm_is_true   --- return 0 for #f, 1 for everything else
 scm_is_false  --- return 1 for #f, 0 for everything else

 scm_is_bool   --- return 1 for #t and #f, 0 for everything else
 scm_to_bool   --- return 0 for #f, 1 for everything else
 scm_from_bool --- return #f for 0, #t for everything else

Is there an advantage of having instead

 scm_to_bool   --- return 0 for #f, 1 for #t, else signal error

What about

 scm_from_bool --- return #f for 0, #t for 1, else signal error

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


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

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

[Paul Jarc]

Marius Vollmer <mvo@zagadka.de> wrote:
> Is there an advantage of having instead
>
>  scm_to_bool   --- return 0 for #f, 1 for #t, else signal error

It would be more symmetric, as I suggested earlier.

A procedure argument might have defined meanings for #f and #t, and
later it might be extended with defined meanings for other values.
Now suppose a new caller passes 42, expecting the new extended
semantics, but it happens to be calling an old version of the
procedure which only supports boolean values.  Having a scm_to_bool
which signals an error here would help detect this problem early.

> What about
>
>  scm_from_bool --- return #f for 0, #t for 1, else signal error

I think 1 in C is sufficiently less distinctive than #t in Scheme that
this would not be good.


paul


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

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

[Dale P. Smith]

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

> Marius Vollmer <mvo@zagadka.de> wrote:
>> What about
>>
>>  scm_from_bool --- return #f for 0, #t for 1, else signal error
>
> I think 1 in C is sufficiently less distinctive than #t in Scheme that
> this would not be good.

Istr that the new C standard has a bool type.  (Maybe I'm thinking of
C++?)  If it does, shouldn't there be a plan to use that?

-Dale

-- 
Dale P. Smith
dsmith at actron dot com


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

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

[Paul Jarc]

dsmith@actron.com (Dale P. Smith) wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
>> I think 1 in C is sufficiently less distinctive than #t in Scheme
>
> Istr that the new C standard has a bool type.  (Maybe I'm thinking of
> C++?)  If it does, shouldn't there be a plan to use that?

C99 does have _Bool, but it's still just another integer type holding
zero or nonzero integer values.


paul


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

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

[Kevin Ryde]

dsmith@actron.com (Dale P. Smith) writes:
>
> Istr that the new C standard has a bool type.

Yes, but not older C.  It's a bit too soon to demand c99 from
everyone.


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

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

[Rob Browning]

Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:

> 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.

> Thus, I would prefer either alternative 1 or 2, favoring alternative 1.

I had the same concern, and offhand, think I'd probably prefer 1 as well.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


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

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

[Rob Browning]

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:

> Hi,
>
> I have a partial proposal for making type conversions between Scheme
> and C easier.

Overall, I like it, and most of the comments I thought of have already
been covered by Paul, Dirk, and others.

>   These two functions lock and unlock all SCM objects (the heap).  The
>   heap should not be locked for long periods of time and no calls to
>   'normal' libguile functions are allowed while it is locked.  A
>   function is 'normal' unless it is specifically documented to be
>   useable with a locked heap.  (Indeed, most 'unnormal' functions can
>   _only_ be used while the heap is locked.)
>
>   You can not lock the heap twice.  Calling scm_lock_heap while the
>   heap is already locked results in undefined behavior.  Likewise,
>   calling scm_unlock_heap when the heap is not locked is verboten.
>
>   - const unsigned char *scm_l_get_utf8_string_mem (SCM str);

I'm a little wary of the locking, especially global locking, but I
suppose it may well be necessary.  I don't have a strong feeling
either way offhand, but presuming for the moment that it is necessary,
then is there any way to lock down a particular value rather than the
entire heap?  Also, could and should we make it easy to install a
frame unwind handler that unlocks the heap when acquiring the lock?
Finally, what's the argument against allowing recursive locking by the
same thread, too expensive?

On a related note, in many cases, I suspect all the user may really
need is a cheap way to copy some offset + size chunk of the data into
their own buffer, especially when dealing with homogeneous uint8
arrays.  If so, then it might make sense to provide a set of functions
that can do that, handling whatever locking and memcpying is needed.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


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

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

[Dirk Herrmann]

Marius Vollmer wrote:

>prj@po.cwru.edu (Paul Jarc) writes:
>  
>
>>But maybe profile some code both ways to see if the function call
>>overhead is significant.  The current macro type predicates just
>>examine the bits of the SCM value, without even following a pointer,
>>right?  OTOH, these functions could be implemented as macros too, if
>>the performance gain was significant, so that shouldn't necessarily
>>affect the decision of whether to use the new API.
>>    
>>
>
>Yes, right.  What about inline functions?  We already use them for
>scm_cell and scm_double_cell, we can use them for converting fixnums
>as well, for example.
>  
>
With respect to binary backwards compatibility, inline functions are as 
bad as macros. In this case, a decision has to be taken between 
performance and backwards compatibility.

Best regards,
Dirk



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

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

[Dirk Herrmann]

Marius Vollmer wrote:

>Sooo, right now I'm wembleying towards having
>
> scm_is_true   --- return 0 for #f, 1 for everything else
> scm_is_false  --- return 1 for #f, 0 for everything else
>
> scm_is_bool   --- return 1 for #t and #f, 0 for everything else
> scm_to_bool   --- return 0 for #f, 1 for everything else
> scm_from_bool --- return #f for 0, #t for everything else
>
The names scm_is_true and scm_is_false don't fit into the schema, since 
true and false are no types. I am not sure if this is intentional or 
just an oversight. Further, if implemented as above, scm_is_true does 
not bring additional benefit and is confusing, since scm_is_false checks 
for #f, while scm_is_true checks for not-#f. But, there is still not yet 
any function that checks for #t. To do so, you would first have to call 
scm_is_bool and scm_is_true afterwards.

>Is there an advantage of having instead
>
> scm_to_bool   --- return 0 for #f, 1 for #t, else signal error
>  
>
This is certainly the most symmetric approach. If this approach was 
used, then (some maybe different named equivalent of) scm_is_true and 
scm_is_false (checking for exactly #t and #f) would begin to make sense, 
since scm_is_true would then be useful to replace the 
scm_is_bool/scm_to_bool sequence, similar with scm_is_false. However, I 
can well live with scm_to_bool giving 1 for anything but #f, since even 
in scheme the interpretation of non-#f values as true values is 
standard, and the explicit comparison with #t is comparably seldom.

>What about
>
> scm_from_bool --- return #f for 0, #t for 1, else signal error
>
I would accept any value != 0 as false here. Even when the new ISO-C99 
_Bool type was used, this would still work, since integers will 
implicitly be converted to _Bool, giving 0 for 0, 1 for any non-zero 
value. That is, if we plan to change the argument type to _Bool later, 
signalling an error for values != 0 and != 1 would then become useless 
anyway.

Best regards
Dirk



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

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

[Dirk Herrmann]

Rob Browning wrote:

>Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:
>
>  
>
>>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.
>>    
>>
>>Thus, I would prefer either alternative 1 or 2, favoring alternative 1.
>>    
>>
>
>I had the same concern, and offhand, think I'd probably prefer 1 as well.
>
Thinking more about it, I would even go further and simply disallow the 
passing of NULL. It's just another asymmetry and magic number. The rule 
woule be, that (if the SCM argument is of the correct type), the caller 
always has to provide a valid pointer for success. On the contrary, if 
the SCM argument is not of the correct type, an error should be thrown. 
The success argument is therefore only for overflow checks, not for type 
checks. This is symmetric with the other conversion functions.

Best regards
Dirk



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

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

[Dirk Herrmann]

Rob Browning wrote:

>On a related note, in many cases, I suspect all the user may really
>need is a cheap way to copy some offset + size chunk of the data into
>their own buffer, especially when dealing with homogeneous uint8
>arrays.  If so, then it might make sense to provide a set of functions
>that can do that, handling whatever locking and memcpying is needed.
>
I agree. The need for the locking functions and the direct access to the 
heap data seem only to be introduced to avoid allocating memory for 
every new conversion. With Rob's suggestion, the user can provide a 
buffer beforehand and have guile simply copy chunks of string contents 
into that buffer. This is much cleaner, since it remains hidden how 
guile represents strings internally, all locking (if necessary) can be 
done by guile internally, and still the benefit is achieved that memory 
allocation is avoided. There may still remain situations where this 
approach will impose some performance penalty, but at some point we 
simply must value our own development freedom and cleanlyness of design 
over performance.

IMO, looking at the problems with the separation of memoization and 
execution, the problems with the generational garbage collector, the 
problems with the module system: If more internals of guile would have 
remained hidden from the start, allowing us to optimize stuff behind the 
scences, guile would have a much better performance today! I spend 90% 
percent of the time that I work on the separation of memoization and 
execution thinking how I can incrementally introduce my patches such 
that the big incompatible change is postponed as late as possible.

Best regards
Dirk



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

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

[Paul Jarc]

Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> wrote:
> The names scm_is_true and scm_is_false don't fit into the schema,
> since true and false are no types.

We might think of these scm_is_* functions more generally as
predicates, some of which happen to be type predicates.  But I agree
that type predicates ought to have their own naming convention
separate from other predicates.  (OTOH, we could think of types as
general sets of values, and these two sets just happen to not
correspond directly to any C-level type tag.)

Then again, I think I'm pretty happy with what we have in validate.h.
Shrug.

> Further, if implemented as above, scm_is_true does not bring
> additional benefit and is confusing, since scm_is_false checks for
> #f, while scm_is_true checks for not-#f.

They may be more readable in different situations.  It's up to the
programmer to use them well.

> But, there is still not yet any function that checks for #t. To do
> so, you would first have to call scm_is_bool and scm_is_true
> afterwards.

Or, as Marius suggested, scm_is_eq(x, SCM_BOOL_T).


paul


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

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

[Rob Browning]

Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:

> IMO, looking at the problems with the separation of memoization and
> execution, the problems with the generational garbage collector, the
> problems with the module system: If more internals of guile would have
> remained hidden from the start, allowing us to optimize stuff behind
> the scences, guile would have a much better performance today! I spend
> 90% percent of the time that I work on the separation of memoization
> and execution thinking how I can incrementally introduce my patches
> such that the big incompatible change is postponed as late as possible.

Hmm.  So if we're going to have to make that change anyway (before
1.8?), then why delay (presuming the incremental approach slows you
down)?  I don't mean to imply there's not a reason, I just wanted to
understand it.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


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

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

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

>>   These two functions lock and unlock all SCM objects (the heap).  The
>>   heap should not be locked for long periods of time and no calls to
>>   'normal' libguile functions are allowed while it is locked.  A
>>   function is 'normal' unless it is specifically documented to be
>>   useable with a locked heap.  (Indeed, most 'unnormal' functions can
>>   _only_ be used while the heap is locked.)
>>
>>   You can not lock the heap twice.  Calling scm_lock_heap while the
>>   heap is already locked results in undefined behavior.  Likewise,
>>   calling scm_unlock_heap when the heap is not locked is verboten.
>>
>>   - const unsigned char *scm_l_get_utf8_string_mem (SCM str);
>
> I'm a little wary of the locking, especially global locking, but I
> suppose it may well be necessary.  I don't have a strong feeling
> either way offhand, but presuming for the moment that it is necessary,
> then is there any way to lock down a particular value rather than the
> entire heap?

Having a lock for every object would have a high overhead and give you
very little in terms of performance, I guess.  Also, they would be
tricky to use.

When you need to lock two objects, there would be the danger of
deadlocks, when other code needs to lock the exact same two objects,
but does it in reverse order.

You would also have to allow locking an object twice, further
increasing overhead.

> Also, could and should we make it easy to install a frame unwind
> handler that unlocks the heap when acquiring the lock?

That is not necessary since a non-local exit is not allowed to happen
when the heap is locked.  (The proposal needs to state that
scm_l_get_string_utf8_mem does not throw, it returns NULL for
non-strings.)

Locking the heap really means putting you into a completely different
world; none of Guile's functions can be us while the heap is locked.

> Finally, what's the argument against allowing recursive locking by the
> same thread, too expensive?

It would not work.  Locking the heap essentially has lexical scope:
either some piece of code has been written to use Guile normally, or
it has been written to work with a locked heap.  (Or it doesn't care
about Guile at all.)

When some function calls scm_unlock_heap, it likely expects the heap
to be unlocked after that call and starts to use normal libguile
functions again (doing allocation, for example).  When the heap has
not in fact been unlocked, well...

scm_lock_heap / scm_unlock_heap is a typical C style API: you must use
it correctly and when you don't the behavior is nasty.  Luckily, you
don't need to use it often.

> On a related note, in many cases, I suspect all the user may really
> need is a cheap way to copy some offset + size chunk of the data into
> their own buffer, especially when dealing with homogeneous uint8
> arrays.  If so, then it might make sense to provide a set of functions
> that can do that, handling whatever locking and memcpying is needed.

Yes, that would be a good addition.  However, I'd still want to have
the low-level functions (scm_lock_heap, scm_l_* etc.) available.  You
can use them to code the more convenient variants, but it is unlikely
that we can provide convenience variants for all cases.

For example, you might want to pass a string to gdk_draw_text, or to
libc fputs, or to some other function that works with raw strings that
you know is OK to be called with a locked heap.

This would be a typical use

  int
  write_scm_string (int fd, SCM str)
  {
    int n;
    const char *mem;
    size_t len;

    scm_lock_heap ();
    mem = scm_l_get_string_utf8_mem (str);
    len = scm_l_get_string_utf8_len (str);
    if (mem)
      n = write (fd, mem, len);
    else
      {
        n = -1;
        errno = EINVAL;
      }
    scm_l_unlock_heap ();
    return n;
  }

[ Maybe we should have

    if (scm_l_get_string_utf8_raw (str, &mem, &len))
      ...

  instead?
]


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

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

[Rob Browning]

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:

> Having a lock for every object would have a high overhead and give
> you very little in terms of performance, I guess.  Also, they would
> be tricky to use.

You definitely wouldn't want a lock for every object.  I was mostly
thinking of objects where (for efficiency or whatever) we felt that we
needed to provide the more primitive access (like strings and uniform
arrays).  There wouldn't be an efficiency argument for locking
anything smaller.

> Locking the heap really means putting you into a completely
> different world; none of Guile's functions can be us while the heap
> is locked.

Yep.  That's why I'm concerned, and I'd like to make a rare case where
non-guile-hackers actually need to lock the heap.

> When some function calls scm_unlock_heap, it likely expects the heap
> to be unlocked after that call and starts to use normal libguile
> functions again (doing allocation, for example).  When the heap has
> not in fact been unlocked, well...

That makes sense.  I've been sensitized to the threading case where if
you don't have recursive locks, you can end up needing a lot of
foo_lock and foo_nolock versions of functions or needing a "grab_lock"
argument, if you want to be able to use those functions as building
blocks for higher level functions.  Of course recursive locks have
their own issues.

> Yes, that would be a good addition.  However, I'd still want to have
> the low-level functions (scm_lock_heap, scm_l_* etc.) available.  You
> can use them to code the more convenient variants, but it is unlikely
> that we can provide convenience variants for all cases.
>
> For example, you might want to pass a string to gdk_draw_text, or to
> libc fputs, or to some other function that works with raw strings that
> you know is OK to be called with a locked heap.
>
> This would be a typical use
>
>   int
>   write_scm_string (int fd, SCM str)

I can see the argument, but I'm also concerned that we're adding
another function category that people have to keep track of,
"functions that are safe to call with a locked heap".  With scm_l_foo
it's fairly clear, but what about other functions?  Will some
non-guile functions be safe and others not, or will all non-guile
functions be safe?

However, if we can provide the "copy into buffer" varieties for the
common cases, and also provide common things like write_scm_string
ourselves, then we should be able to make the need for locking so low
that it wouldn't bother me, and we can document it with all kinds of
warnings.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


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

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

[Andreas Rottmann]

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:

>> I'm a little wary of the locking, especially global locking, but I
>> suppose it may well be necessary.  I don't have a strong feeling
>> either way offhand, but presuming for the moment that it is necessary,
>> then is there any way to lock down a particular value rather than the
>> entire heap?
>
> Having a lock for every object would have a high overhead and give you
> very little in terms of performance, I guess.  Also, they would be
> tricky to use.
>
Why would the overhead be significantly larger than for one object?
Pika will have per-object locks, and I think the implementation chosen
has little overhead over global locking.

> When you need to lock two objects, there would be the danger of
> deadlocks, when other code needs to lock the exact same two objects,
> but does it in reverse order.
>
You could probably solve this by having an poeration that does an
"atomic" lock of serveral objects. Naive algorithm:

1) lock all objects you can
2) if that's all:
     fine
   else:
     release all objects locked previously, wait a bit and goto 1)

> You would also have to allow locking an object twice, further
> increasing overhead.
>
Why do you need to lock an object twice?

Andy
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Say NO to Software Patents! -- http://petition.eurolinux.org/


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

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

[Dirk Herrmann]

Marius Vollmer wrote:

>If you really want to check for #t, you should use 'eq?', I'd say:
>
>  scm_is_eq (x, SCM_BOOL_T)
>
Why scm_is_eq instead of scm_eq_p? Are you proposing to rename _all_ 
predicates to scm_is_?

Best regards,
Dirk



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

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

[Marius Vollmer]

Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:

> Marius Vollmer wrote:
>
>>If you really want to check for #t, you should use 'eq?', I'd say:
>>
>>  scm_is_eq (x, SCM_BOOL_T)
>
> Why scm_is_eq instead of scm_eq_p?

scm_eq_p is the 'eq?' subr; it returns a SCM boolean.  scm_is_eq is a
C predicate that returns 0 or 1.

> Are you proposing to rename _all_ predicates to scm_is_?

No, they will stay the way they are.  Instead of scm_is_eq, one could
also use

    scm_is_true (scm_eq_p (X, Y))

but scm_is_eq is so fundamental, it ought to have its own name and be
really fast.

There wont be scm_is_procedure or scm_is_even, for example, you will
have to use scm_procedure_p or scm_even_p together with scm_is_true.

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


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

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

[Dirk Herrmann]

Marius Vollmer wrote:

>  Rob Browning <rlb@defaultvalue.org> writes:
>
> > On a related note, in many cases, I suspect all the user may really
> > need is a cheap way to copy some offset + size chunk of the data
> > into their own buffer, especially when dealing with homogeneous
> > uint8 arrays. If so, then it might make sense to provide a set of
> > functions that can do that, handling whatever locking and memcpying
> > is needed.
>
>
>  Yes, that would be a good addition. However, I'd still want to have
>  the low-level functions (scm_lock_heap, scm_l_* etc.) available. You
>  can use them to code the more convenient variants, but it is
>  unlikely that we can provide convenience variants for all cases.

I can not understand at all, why we should introduce such a concept from 
the start: The non-locking related API allows users to do all they could 
want to do. Locking is only introduced to avoid performance problems due 
to memory allocation when extracting string contents. This early 
optimization is done at the wrong time. Before we don't even have an 
implementation without locking available, we don't know how much of a 
problem the memory allocation really is for a typical application. If it 
later appears that the real performance problem comes from the fact that 
our internal memory organization of strings is bad, we are stuck. If it 
later appears that the global locking introduces more performance 
problems than it solves, we are stuck.

Further, to really be able to rate the design of the global heap 
locking, I need more information about how it would be implemented: What 
exactly would happen at the moment one thread calls scm_lock_heap? What 
is the performance penalty for additional thread-switches due to the 
global locking? How much is it compared to the expected performance gain 
for the typical application? Which parts of guile are affected by 
introducing the global locking concept?

In general, I think the proposal is a step in the right direction. My 
suggestion is to start with the non-controversial stuff and provide 
users with an API that allows them to do everything they want, and 
postpone the performance optimization issues. As far as I see it, the 
global locking could be added later without influence on the rest of the 
API.

Best regards
Dirk Herrmann



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

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

[Dirk Herrmann]

Marius Vollmer wrote:

>  Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:
>
> > Why scm_is_eq instead of scm_eq_p?
>
>  scm_eq_p is the 'eq?' subr; it returns a SCM boolean. scm_is_eq is a
>  C predicate that returns 0 or 1.

Ah, I see. Yes, that makes sense.

Best regards,
Dirk



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

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

[Paul Jarc]

Marius Vollmer <mvo@zagadka.de> wrote:
> but scm_is_eq is so fundamental, it ought to have its own name and be
> really fast.

Like, say, SCM_EQ_P? :)


paul


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

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

[Marius Vollmer]

Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> 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
> http://mail.gnu.org/archive/html/guile-devel/2001-09/msg00290.html.

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
this.

> 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


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

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

[Dirk Herrmann]

Marius Vollmer wrote:

>  Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:
>
> >> - 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?

I personally don't like this kind of 'one value, several meanings' paradigm:

- What, if instead of -1, you pass -2? Is it allowed? Is it a run-time 
error?
  Is it being checked by the routine? At least, the compiler can't help you
  any more.

- Readability suffers. If there is only scm_from_locale_string, there will
  be places in the code like the following:

    SCM s = scm_from_locale_string (str, -1);  /* not obvious, what the 
-1 means */

  Compare this with the readability of

    SCM s = scm_from_locale_c_string (str);

  Note that with scm_from_locale_memory there will probably be no
readability problem either, since whoever calls scm_from_locale_memory
must be aware of the length, such that the call will typically look like

SCM s = scm_from_locale_memory (str, len);

with "len" being hopefully some sensible name, thus leading to
self-documenting code.

Best regards,
Dirk Herrmann




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

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

[Dirk Herrmann]

Marius Vollmer wrote:

>  Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:
>
> > 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 this.
>
> > 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);

Yes, when choosing alternative 3, this would be a nice solution. It might
also make sense to add these functions if one of the other alternatives
would be chosen.

> > 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.

I doubt that this is true. The only scenario, where I would _not_ perform
this kind of check is, when I have the full control over all the code that
generates the numbers, and when I know my algorithms well enough to
know that no overflow can occur.

In all other cases, I would at least prefer to print out a warning, at which
place I have received incorrect value. For example, if the number comes from
some extension code provided by the user of my application: It is good
style to indicate clearly, what the user's code did wrong. That is, whether
or not you can do something about a bad value, you still want to know it,
at least to be a little bit more user friendly in your error messages.

And, as I had clarified in a later mail:
DH>> I would even go further and simply disallow the passing of NULL. It's
DH>> just another asymmetry and magic number. The rule woule be, that (if
DH>> the SCM argument is of the correct type), the caller always has to
DH>> provide a valid pointer for success. On the contrary, if the SCM 
argument
DH>> is not of the correct type, an error should be thrown. The success
DH>> argument is therefore only for overflow checks, not for type checks.
DH>> This is symmetric with the other conversion functions.

It may be that we end up with different opinions here. That's OK, but for
the final decision I suggest to check what after the discussion the majority
of developers (or users) prefers.

> >> - 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.

No problem with that. Let's just wait if there is lot of demand for 
something
more efficient, we can re-think the issue then.

Best regards,
Dirk



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

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

[Marius Vollmer]

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

> Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> wrote:
>> The names scm_is_true and scm_is_false don't fit into the schema,
>> since true and false are no types.
>
> We might think of these scm_is_* functions more generally as
> predicates, some of which happen to be type predicates.

Right; that's what I had in mind.  I also propose scm_is_eq, for
example.

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


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

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

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> However, if we can provide the "copy into buffer" varieties for the
> common cases, and also provide common things like write_scm_string
> ourselves, then we should be able to make the need for locking so low
> that it wouldn't bother me, and we can document it with all kinds of
> warnings.

Yes, I agree.  The heap locking thing really is quite a sharp
tool... I wouldn't want people to pull it out wantonly.  In my current
proposal, heap locking wouldn't be implemented before we wouldn't have
moved to UTF-8 anyway, so I'll add a copy-to-buffer variant and mark
the heap locking stuff as 'maybe, eventually'.

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


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

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

[Marius Vollmer]

Andreas Rottmann <a.rottmann@gmx.at> writes:

> Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:
>
>>> I'm a little wary of the locking, especially global locking, but I
>>> suppose it may well be necessary.  I don't have a strong feeling
>>> either way offhand, but presuming for the moment that it is necessary,
>>> then is there any way to lock down a particular value rather than the
>>> entire heap?
>>
>> Having a lock for every object would have a high overhead and give you
>> very little in terms of performance, I guess.  Also, they would be
>> tricky to use.
>>
> Why would the overhead be significantly larger than for one object?
> Pika will have per-object locks, and I think the implementation chosen
> has little overhead over global locking.

Ahh, I don't know about that implementation.  How large is the
overhead? (in bits/object, say.  URL perfectly OK.)

>> When you need to lock two objects, there would be the danger of
>> deadlocks, when other code needs to lock the exact same two objects,
>> but does it in reverse order.
>>
> You could probably solve this by having an poeration that does an
> "atomic" lock of serveral objects. Naive algorithm:
>
> 1) lock all objects you can
> 2) if that's all:
>      fine
>    else:
>      release all objects locked previously, wait a bit and goto 1)

Yes, but I would count this as 'significant overhead' ;-)

>> You would also have to allow locking an object twice, further
>> increasing overhead.
>>
> Why do you need to lock an object twice?

You don't need to, but you can't avoid, in general (I think).  The
might be some code path that locks one object twice without anyone
intending this.

But, yeah, you can partition your code into two kinds, just like with
a single global lock: When you have locked some objects, you can't
call functions that lock more objects.

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


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

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

[Marius Vollmer]

Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:

> I can not understand at all, why we should introduce such a concept
> from the start: The non-locking related API allows users to do all
> they could want to do. Locking is only introduced to avoid performance
> problems due to memory allocation when extracting string
> contents. This early optimization is done at the wrong time.

Yes, I'm now convinced that this part of the proposal is premature.

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


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

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

[Marius Vollmer]

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

> Marius Vollmer <mvo@zagadka.de> wrote:
>> but scm_is_eq is so fundamental, it ought to have its own name and be
>> really fast.
>
> Like, say, SCM_EQ_P? :)

Yeah, but the name should also fit with the rest...

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


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

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

[Bruce Korb]

Marius Vollmer wrote:
> 
> prj@po.cwru.edu (Paul Jarc) writes:
> 
> > Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> wrote:
> >> The names scm_is_true and scm_is_false don't fit into the schema,
> >> since true and false are no types.
> >
> > We might think of these scm_is_* functions more generally as
> > predicates, some of which happen to be type predicates.
> 
> Right; that's what I had in mind.  I also propose scm_is_eq, for
> example.

Would that yield #t if its argument were the `eq' operator, or
would it work on two arguments and yield #t if the two arguments
were equal?  :-)


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

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

[Andreas Rottmann]

Marius Vollmer <mvo@zagadka.de> writes:

> Andreas Rottmann <a.rottmann@gmx.at> writes:
>
>> Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:
>>
>>> Having a lock for every object would have a high overhead and give you
>>> very little in terms of performance, I guess.  Also, they would be
>>> tricky to use.
>>>
>> Why would the overhead be significantly larger than for one object?
>> Pika will have per-object locks, and I think the implementation chosen
>> has little overhead over global locking.
>
> Ahh, I don't know about that implementation.  How large is the
> overhead? (in bits/object, say.  URL perfectly OK.)
>
There is no overhead in bits/object. The locks are allocated
dynamically for each object when requested and released again
afterwards.

>>> When you need to lock two objects, there would be the danger of
>>> deadlocks, when other code needs to lock the exact same two objects,
>>> but does it in reverse order.
>>>
>> You could probably solve this by having an poeration that does an
>> "atomic" lock of serveral objects. Naive algorithm:
>>
>> 1) lock all objects you can
>> 2) if that's all:
>>      fine
>>    else:
>>      release all objects locked previously, wait a bit and goto 1)
>
> Yes, but I would count this as 'significant overhead' ;-)
>
I assume the case 2) whould be hit seldomly...

Andy
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Any technology not indistinguishable from magic is insufficiently advanced.
   -- Terry Pratchett



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

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

[Marius Vollmer]

Bruce Korb <bkorb@veritas.com> writes:

>> Right; that's what I had in mind.  I also propose scm_is_eq, for
>> example.
>
> Would that yield #t if its argument were the `eq' operator, or
> would it work on two arguments and yield #t if the two arguments
> were equal?  :-)

Hehe, it would yield 1 when its two arguments were 'eq?'.


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

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

[Marius Vollmer]

Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:

> Marius Vollmer wrote:
>
>>  Hmm, yes, that might make sense. However, the -1 idiom is pretty
>>  much standard for this kind of interface, no?
>
> I personally don't like this kind of 'one value, several meanings' paradigm:
>
> - What, if instead of -1, you pass -2? [...]
> - Readability suffers. [...]

Yes, I agree that the -1 idiom is not self explaining, but it is well
established and people will instantly recognize it.  I'd even argue
that they will expect to be able to pass -1 for a 'len' parameter and
will be annoyed when they find out that Guile doesn't allow it.

>   Note that with scm_from_locale_memory there will probably be no
> readability problem either, since whoever calls
> scm_from_locale_memory must be aware of the length, such that the
> call will typically look like
>
> SCM s = scm_from_locale_memory (str, len);
>
> with "len" being hopefully some sensible name, thus leading to
> self-documenting code.

This can be had with scm_from_locale_string as well, of course.  When
you write

  SCM s = scm_from_locale_string (str, len);

thats just as readable, I'd say.


Soo, I'm inclined to leave it as it is...

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


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

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

[Marius Vollmer]

Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:

>>  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.
>
> I doubt that this is true. The only scenario, where I would _not_ perform
> this kind of check is, when I have the full control over all the code that
> generates the numbers, and when I know my algorithms well enough to
> know that no overflow can occur.
>
> In all other cases, I would at least prefer to print out a warning, at which
> place I have received incorrect value. For example, if the number comes from
> some extension code provided by the user of my application: It is good
> style to indicate clearly, what the user's code did wrong. That is, whether
> or not you can do something about a bad value, you still want to know it,
> at least to be a little bit more user friendly in your error messages.

Hmm, there might be a misunderstanding somewhere: they way I want it,
scm_to_int would either produce a correctly converted 'int', or would
signal an error.  The error might be a 'wrong type argument' one when
a non-integer has been passed to scm_to_int, or it might be a
'argument out of range' one, when the integer doesn't fit into an
'int'.  There would not be the case that code would silently work with
incorrect values.

Given this behavior, I still think that explicitely checking whether a
SCM value fits into a 'int' will not be done often.  When the value
doesn't fit, what do you do?  You could print a warning, but wouldn't
the error produced by scm_to_int be better?

You could try to explicitly deal with non-int values, but how?  When
you have a method to deal with non-ints why not use it always?

Maybe it is much less efficient, so there really is a reason to do
range checks.  But I believe that this situation happens both
infrequently and when it happens, the second done by scm_to_int is not
a problem.

When it really is a problem, tho, it is likely worthwhile to use the
internal stuff of libguile directly, such as SCM_INUMP, SCM_MAKINUM,
SCM_INUM, etc.  This will be less portable across versions of Guile,
of course, but when that is what it takes...


I see the typical use of scm_to_int etc to be in glue code, like

  SCM
  posix_kill (SCM pid, SCM sig)
  {
    return scm_from_int (kill (scm_to_int (pid), scm_to_int (sig)));
  }

That is all it should take to wrap 'kill'.

>> >> - 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.
>
> No problem with that. Let's just wait if there is lot of demand for
> something
> more efficient, we can re-think the issue then.

Yes.

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


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

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

[Paul Jarc]

Marius Vollmer <mvo@zagadka.de> wrote:
> Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:
>> - Readability suffers. [...]
>
> Yes, I agree that the -1 idiom is not self explaining, but it is well
> established and people will instantly recognize it.

Maybe:
#define scm_from_locale_0string(str) scm_from_locale_string((str), -1)
?


paul


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

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

[Dirk Herrmann]

Marius Vollmer wrote:

>  Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:
>
> > Marius Vollmer wrote:
> >
> >> Hmm, yes, that might make sense. However, the -1 idiom is pretty
> >> much standard for this kind of interface, no?
> >
> > I personally don't like this kind of 'one value, several meanings'
> > paradigm:
> >
> > - What, if instead of -1, you pass -2? [...] - Readability suffers.
> > [...]
>
>  Yes, I agree that the -1 idiom is not self explaining, but it is well
>  established and people will instantly recognize it. I'd even argue
>
What about the -2 and so on?

You are trying to explain why the -1 idiom is not too bad. But, why
do you think it is better? Do you want to save an identifier? This
can't really be the reason. Especially when looking at Paul's suggestion
to introduce a macro scm_from_locale_0string, which also introduces
a new identifier (and, Paul, I like your name better than my suggestion).

>  established and people will instantly recognize it. I'd even argue
>  that they will expect to be able to pass -1 for a 'len' parameter and
>  will be annoyed when they find out that Guile doesn't allow it.

That's a guess. Maybe you should ask the people what they would prefer?
Considering me as part of them, I would not prefer having the -1 idiom.

> > SCM s = scm_from_locale_memory (str, len);
>
>  This can be had with scm_from_locale_string as well, of course. When
>  you write
>
>  SCM s = scm_from_locale_string (str, len);
>
>  thats just as readable, I'd say.

I agree that the function name scm_from_local_string when called with
arguments str and len is not less readable (even better, I would say) than
scm_from_locale_memory when called with arguments str and len. My point,
however, was rather in the direction of saying that if the len argument is
required since the application really knows the length, then passing it will
always be readable. This is in contrast to passing the magic number -1 
if the
application does not know the length.


However, I think you oversimplify my concerns if you only boild it down to
the readability issue. There is also the aspect of type checking support 
by the
compiler, the fact that code that works mostly with 0strings always has to
pass an unnecessary parameter, the fact that the scm_from_locale_string
function always has to handle the special -1 case, and probably more.

Summarized, I would just claim that it is not a good API design, since I 
have
not yet seen a convincing argument in favor of it.


Considering your and Paul's answer, I would like to change my suggestion
to the following pair of functions:

SCM scm_from_locale_string (const unsigned char *str, size_t len);
SCM scm_from_locale_0string (const unsigned char *str);

Best regards,
Dirk




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

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

[Dirk Herrmann]

Marius Vollmer wrote:

>  Hmm, there might be a misunderstanding somewhere: they way I want it,
>  scm_to_int would either produce a correctly converted 'int', or
>  would signal an error. The error might be a 'wrong type argument'
>  one when a non-integer has been passed to scm_to_int, or it might be
>  a 'argument out of range' one, when the integer doesn't fit into an
>  'int'. There would not be the case that code would silently work
>  with incorrect values.

No misunderstanding. I fully agree with you that the code should never
silently work with incorrect values. However, if scm_to_int throws an
error 'wrong type argument' or 'argument out of range', this is still not
too much of a help in many cases.

>  I see the typical use of scm_to_int etc to be in glue code, like
>
>  SCM posix_kill (SCM pid, SCM sig) { return scm_from_int (kill
>  (scm_to_int (pid), scm_to_int (sig))); }
>
>  That is all it should take to wrap 'kill'.

And it is already an example that 'argument out of range' is not a
very good message if the return value is out of range. But, this can
certainly easily be fixed by changing the error message to 'value out
of range'.

Still, I am wondering whether a user of this function would not be
happier if instead of 'argument out of range' or 'value out of range'
the message would be one of
  'process id argument to kill out of range'
  'signal argument to kill out of range'
and if you are not really sure what posix_kill returns
  'return value of system function kill out of range'.


Looking again at the solution that I had suggested:
  <type> scm_to_<type> (SCM value, int *success)
might even be extended: Instead of returning just true or false
for success, the following, more fine-grained results could be
given:
  typedef enum {
    SCM_TO_INTEGER_OK,
    SCM_TO_INTEGER_UNDERFLOW,
    SCM_TO_INTEGER_OVERFLOW
  } scm_t_scm_to_integer_conversion_state;
Depending on the way the scm_to_<type> functions for
integer types would be implemented, this could be provided
at almost no cost. It might be helpful for code that decides
to fall back to the minimum/maximum value in case of an
underflow/overflow.

(This is yet another design alternative.)


But, all in all I could live with the decision to have the range-
checking functions separate.

On what basis would the decision be taken? By asking people
on the guile-devel and guile-user lists what they would prefer?
This would give us a better indication of what the typical case
really is. Everything else is just guessing and taking decisions
on a maybe unsufficient knowledge base.

Best regards,
Dirk



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

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

[Marius Vollmer]

Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:

> Marius Vollmer wrote:
>
>>  Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:
>>
>> > Marius Vollmer wrote:
>> >
>> >> Hmm, yes, that might make sense. However, the -1 idiom is pretty
>> >> much standard for this kind of interface, no?
>> >
>> > I personally don't like this kind of 'one value, several meanings'
>> > paradigm:
>> >
>> > - What, if instead of -1, you pass -2? [...] - Readability suffers.
>> > [...]
>>
>>  Yes, I agree that the -1 idiom is not self explaining, but it is well
>>  established and people will instantly recognize it. I'd even argue
>>
> What about the -2 and so on?

The way it is worded in the proposal right now, -2 would be
interpreted as an unsigned value, that is, as a very large length.  In
other words, only one value, ((size_t)-1), is interpreted specially.

> You are trying to explain why the -1 idiom is not too bad.

I'm arguing that it is well known, not that it is necessarily good or
better.  Also, I really do think that people expect to be able to pass
-1 as the length parameter, as a convenience feature.

One point of the proposal is to make the API very easy to use, where
the 'obvious' way to use it is also the correct one.

So, IMO, we need to interpret -1 specially.  The question is then, is
it an advantage to have an additional way to have Guile count the
string length on its own?

> But, why do you think it is better?

I think it is good enough, but I'm of course listening to your
arguments.

>>  established and people will instantly recognize it. I'd even argue
>>  that they will expect to be able to pass -1 for a 'len' parameter and
>>  will be annoyed when they find out that Guile doesn't allow it.
>
> That's a guess. Maybe you should ask the people what they would prefer?
> Considering me as part of them, I would not prefer having the -1 idiom.

Noted.

> Summarized, I would just claim that it is not a good API design,
> since I have not yet seen a convincing argument in favor of it.

Yeah, I'm convinced.

> Considering your and Paul's answer, I would like to change my suggestion
> to the following pair of functions:
>
> SCM scm_from_locale_string (const unsigned char *str, size_t len);
> SCM scm_from_locale_0string (const unsigned char *str);

I would not like to use the "memory" term to indicate a string that is
not zero terminated; "memory" is too generic.  Also, "0string" feels
not right either, since it makes it look as if a 0string would
be something very special although it is the ordinary thing (for C).

What about

   SCM scm_from_locale_string (unsigned char *str);
   SCM scm_from_locale_string_counted (unsigned char *str, size_t len);

'scm_from_locale_string_counted' would treat len == -1 specially.

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


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

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

[tomas]

On Thu, Jun 03, 2004 at 11:40:03PM +0200, Marius Vollmer wrote:
> Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:
> 
> > Marius Vollmer wrote:
> >
> >>  Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:

[...]

> >>  Yes, I agree that the -1 idiom is not self explaining, but it is well
> >>  established and people will instantly recognize it. I'd even argue
> >>
> > What about the -2 and so on?

For one (rather unimportant) data point -- I lean towards the -1 idiom
(given a sufficiently clear constant declaration, e.g.
#define NULLTERM -1). I'm on the `economic API' camp ;-)

But my leaning is not overly strong either...

> What about
> 
>    SCM scm_from_locale_string (unsigned char *str);
>    SCM scm_from_locale_string_counted (unsigned char *str, size_t len);

What about ...stringn in the second case? (I'm thinking of snprintf
and friends).

Regards
-- tomás


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

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

[Marius Vollmer]

Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:

> No misunderstanding. I fully agree with you that the code should never
> silently work with incorrect values. However, if scm_to_int throws an
> error 'wrong type argument' or 'argument out of range', this is still not
> too much of a help in many cases.

Yes.  For more help, people probably need to use the debugger, or a
backtrace, or maybe need to instrument their code.

>>  I see the typical use of scm_to_int etc to be in glue code, like
>>
>>  SCM posix_kill (SCM pid, SCM sig) { return scm_from_int (kill
>>  (scm_to_int (pid), scm_to_int (sig))); }
>>
>>  That is all it should take to wrap 'kill'.
>
> And it is already an example that 'argument out of range' is not a
> very good message if the return value is out of range.

The return value can not be out of range since a SCM can represent all
values that fot into an 'int'.  (I know that you know that ;-)

> But, this can certainly easily be fixed by changing the error
> message to 'value out of range'.

Yes, not using "argument" in the error message is likely an
improvement.  Not all values that are wrong are thought of directly as
arguments by the user.  For example, the wrong value might be an
element of a list that is an argument.

> Still, I am wondering whether a user of this function would not be
> happier if instead of 'argument out of range' or 'value out of range'
> the message would be one of
>   'process id argument to kill out of range'
>   'signal argument to kill out of range'

Yes, that would be very good.  Right now, we only give argument
positions, and that as good as argument names.  With scm_to_int, we
the argument positions are not included in the error message, which is
a clear drawback.

Right now, I hope that the debugger and the backtrace mechanism can be
used to recover this lost information.  In addition to giving a
backtrace that shows how the flow of control has reached the point of
error, it can also show how the erroneous value has reached this
point.

That is, the backtrace would highlight occurences of the wrong value
in the printed backtrace.

(The obvious problem is that immediate values can not be reliably
found, but hopefully this is not a big problem if we are careful to
acknowledge this uncertainty in the output, i.e, when we state that
"the wrong value might be the second or third argument", say, for
immediates, instead of saying "it is the second one".)

I'll say more when I have toyed more with this idea.

> On what basis would the decision be taken? By asking people
> on the guile-devel and guile-user lists what they would prefer?

*cough*, I just did it my way!  The code is now in CVS head, comments
welcome!

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


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

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

[Marius Vollmer]

tomas@fabula.de writes:

>> What about
>> 
>>    SCM scm_from_locale_string (unsigned char *str);
>>    SCM scm_from_locale_string_counted (unsigned char *str, size_t len);
>
> What about ...stringn in the second case? (I'm thinking of snprintf
> and friends).

Excellent!  I used stringn (to be committed soonish).

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


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