Re: Guile naming conventions

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

Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:

> Consequence:
> 
> We must either change the environment proposal to meet the convention
> that guile currently uses 

[...]

> or we should change guile's naming conventions. 

Yes.  As various people, especially Dirk, has discussed, it would be
very good to establish clear principles for naming in Guile.

But establishing such a convention has big consequences, so it should
be done with good consideration.

Personallly, I don't have time right now to deal with this problem.  I
wish someone could take a good look at the state of the current code.
For example: How extensively has the convention I described been
followed on the C and Scheme levels?

It feels awkward if we have to rename > 50% of the macros...

Also, Maciej has to say a word about the coming releases from a
backward compatibility perspective: When could we do such a change, if
at all?


Then there is the issue of the relative merits of the conventions
themselves.  One big win with your convention is that it is consistent
with R5RS.  It is also reasonably systematic.  However, I find it a
bit awkward that `set' can end up somewhere in the middle of names.
In fact, it also can end up both in front and at the end of a name.
I think the current convention is based upon a division of the
macros/functions associated with a type into the following three
groups:

Selectors

  foo_x
  foo_y
  ...

Mutators

  set_foo_x
  set_foo_y

Other operations

  foo_op1
  foo_op2

This is kind of simple to think about:

You have components of the type which you access using the component
names.  Also, you have a set of operations which you name with a verb.

Then you prepend the type name on everything.

Finally, since a value is called foo_x, you set it with set_foo_x
(note that the name "foo_x" isn't split by "set").


I'm afraid that, in the suggested convention, one will tend to always
let either the type name or the component name be implicit, so that
the convention will look kind of complex if you are lazy enough not to
envision the deeper meaning in your "minds eye"...