Re: feature request

[Jacques A. Vidrine]

On Tue, May 29, 2001 at 12:53:43PM +0200, Dirk Herrmann wrote:
> On Mon, 28 May 2001, Jacques A. Vidrine wrote:
> > [ Please don't shoot the messenger :-) ]
> Sorry if I have upset you.  I didn't mean to.  I know the whole mess is 
> not your fault :-)

No tears, blood shed :-)

> > I did  a web search  to find some alternative  source of info  for the
> > sake of  argument (or rather, for  the sake of avoiding  it :-). These
> > are among the first few hits:
> 
> Thanks for doing this investigation.
> > This is  just because so many  people make the mistake  of copying the
> > POSIX convention.  They  see ``size_t'' and think, ``Oh,  that's not a
> > bad idea, I'll do that, too.''  It is a common mistake.
> 
> Well, it's only a mistake because of POSIX.  In our special situation,
> however, capitalization may be possible, but will probably look strance:
> 
> scm_Size, scm_Ulong, scm_Bits etc.
>
> We _could_ use such a convention.  But, do we want to?  Is there another
> suggestion for uniform type naming in guile?

As  an  aside,   in  David  Hanson's  excellent   ``C  Interfaces  and
Implementations'', the  author uses the convention  of captilization +
_T  suffix.   If guile  applied  that  convention, you'd  get  Size_T,
ULong_T, Bits_T.  I  never did take to this approach  -- I guess mixed
case offends me :-)

[I know I've  missed past discussions on this very  topic -- please be
patient  if I  ask  stupid  questions] I'm  not  sure why  `scm_size',
`scm_ulong', and  `scm_bits' are not  OK.  Is  there worry of  a clash
with a function name or other  identifier?  I did a quick grep through
libguile/*.h for  `_t\b' to  find what types  have been  `tagged' like
this.  They are listed below, with  the `_t' removed.  In a few cases,
I  added the  `scm_' suffix.   These seem  like quite  reasonable type
names to  me.  In most cases,  I think the `_t'  actually uglifies the
name.

scm_qt
scm_coop
scm_coop_q
scm_mutex
scm_cond
scm_key
scm_coop_userf
scm_bits
scm_guard
scm_inner
scm_c_bvec_limb
scm_heap_seg_data
scm_freelist
scm_c_hook
scm_method
scm_hash_fn
scm_assoc_fn
scm_delete_fn
scm_c_hook_type
scm_c_hook_function
scm_c_hook_entry
scm_c_hook
scm_double
scm_complex
scm_sizet
scm_struct_free
scm_catch_body
scm_catch_handler

Adding a  type suffix doesn't add  much, although some of  these names
could use improvement of other sorts.  E.g. I kind of like using `_fn'
for pointers to functions, so `scm_guard_fn' instead of `scm_guard'.

> SCM_BOOL_T is not a type, but a constant, namely the value #t.  

Oh, that makes  sense.  I should have grokked that  from the all-caps.
SCM_BOOL_T/SCM_BOOL_F.

> OK, the
> name ist strange and might even be renamed some day in the 57th
> century.  But, it's not only types that could sensibly end with _t.

Yes, true.  There is scm_lisp_t,  which seems perfectly named :-( Note
that it  is not a type  :-) I guess  I would probably name  the actual
value  scm_lisp_t_sym, and  provide a  SCM_LISP_T macro  (and likewise
SCM_LISP_NIL).  This makes it orthogonal to SCM_BOOL_T/SCM_BOOL_F, and
for all intents and purposes, these are constants.

Cheers,
-- 
Jacques Vidrine / address@hidden / address@hidden / address@hidden