Re: GC rewrite, first version.

[Han-Wen Nienhuys <hanwen@cs.uu.nl>]

dirk@sallust.ida.ing.tu-bs.de writes:
> However, when you are going to add your stuff to CVS I think it is
> important that it does not deliberately violate conventions that have been
> agreed upon.  Feel free to start a discussion about improving the
> convention, but until the decision is made to change things the way you
> like it, please follow the current convention when changing code in CVS.

I'm a bit reluctant to start a discussion, because that typically
draws comments from people that don't code, but do think they know
better anyway.

With this warning in advance, comments from people that write actual
Scheme code is welcome.

Personally, I view source code as a form of prose. It should be easily
readable. Hence I prefer variable names that can just be read as an
english expression, with the prefix scm_ for delimiting our namespace,
perhaps with an abbreviation here or there to keep the lines within my
editor window. Typically, the most generic word (always a noun), eg
number, size, string, comes last

i.e.

  scm_heap_segment_table_size
  scm_formals_str(ing)

in stead of 

  scm_n_heap_segs
  scm_s_formals
  
Inside C structs this convention is kept reasonably well, i.e.

  throw_value
  jmpbuf
  backing_store_size
  line_number
  rstate_size

However, all exported symbols that don't have a Scheme-derived name
are named with unpronounceable and unreadable names.

I would prefer the following:

 internal ENTITY_X:   internal_ENTITY_X  (not i_ENTITY_X)
 string FOO: FOO_string (not s_foo)
 BAR-type: Bar_type (not t_BAR)

 (or even: simply BAR. Constructors are named new_BAR, so no clashes
 should arise)

 number of FOOS: FOO_count

Perhaps the other way (generic word first) would also be readable, but
then most of the C code is wrong.

To what extent are these naming standards decided (names.txt is dated
march, and I believe little has been done on the code since)? If it is
we have to wait for two releases (four years) before the old names are
scrapped, then I'm not going to waste energy on it.

And for the rest, I think that GUILE 1.6 should be released.

As an aside, if no-one objects to it, I would like to merge the new GC
code coming weekend.

-- 
Han-Wen Nienhuys   |   hanwen@cs.uu.nl    | http://www.cs.uu.nl/~hanwen/


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