Re: Non-R5RS behaviour of guile functions.

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

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

> The following functions show a behaviour that is not defined according to
> R5RS:
> 
> * arguments for string may only be characters.  Guile also allows strings
>   and symbols.
> * the argument for string-length, string-ref, substring and string-append
>   has to be a string, but guile also allows symbols.
> 
> I assume that this is considered as a bug?

I consider this a bug, and think we should move to strict R5RS
compliance.  Providing extra functionality not only destroys
portability (the importance of which has been demonstrated by
e.g. Java), but also (in these cases) encourages less readable code
and makes some bugs harder to find.

E.g., if the code contains an expression

  (string-append x y)

you expect x and y to be strings.

It would be much better to use the existing function

  (symbol-append x y)

if x and y are symbols.  (Symbol-append will be provided by a
different module.)

But I think Maciej has to make the decision regarding this change.

Personally, I think we could simply remove the extra functionality.
But if people are afraid of breaking code, we could perhaps announce
that this extra functionality is deprecated and add a, normally
disabled, run-time option (to the eval options interface perhaps)
which the user can use to enable the extra, deprecated functionality.

> Further, I realized that besides SCM_DEFER_INTS and SCM_ALLOW_INTS there
> are macros SCM_REDEFER_INTS and SCM_REALLOW_INTS.  This surprised me,
> since I assumed that SCM_DEFER_INTS and SCM_ALLOW_INT could safely be
> nested.  A look into __scm.h showed that this is not the case and that you
> would have to use the ...RE... version in order to guarantee safe nesting.
> 
> Can anybody explain the reason of this to me?

I guess it is for efficiency reasons: These macros are used frequently
and incrementing a value in memory takes longer time than storing a
value.

(I'm not going to enter a debate about design priorities, no.  :)

> Shouldn't users that use guile to extend C applications be informed
> to only use the ...RE... versions, or wouldn't it even be better to
> make SCM_DEFER_INTS and SCM_ALLOW_INTS use the safer version?

It's obviously wrong that the user is using these macros at all.  We
must provide features at level high enough not to expose such
internals.  Note that these macros probably won't work at all or will
work very differently when we switch to POSIX threads.  Any occurence
of these macros in application code will very likely break in the
future.