[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: feature request
From: |
Jacques A. Vidrine |
Subject: |
Re: feature request |
Date: |
Tue, 29 May 2001 07:40:38 -0500 |
User-agent: |
Mutt/1.2.5i |
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
- Re: feature request, (continued)
- Re: feature request, Rob Browning, 2001/05/28
- Re: feature request, Lars J. Aas, 2001/05/28
- Re: feature request, Jacques A. Vidrine, 2001/05/28
- Re: feature request, Dirk Herrmann, 2001/05/28
- Re: feature request, Jacques A. Vidrine, 2001/05/28
- Re: feature request, Dirk Herrmann, 2001/05/29
- Re: feature request, Michael Livshin, 2001/05/29
- Re: feature request, Jacques A. Vidrine, 2001/05/29
- Re: feature request,
Jacques A. Vidrine <=
- Re: feature request, Lars J. Aas, 2001/05/29
- Re: feature request, Marius Vollmer, 2001/05/30
- Re: feature request, Rob Browning, 2001/05/30
- Re: feature request, Dirk Herrmann, 2001/05/31
- Re: feature request, Marius Vollmer, 2001/05/31