Re: First-class environment proposal

[Mikael Djurfeldt <mdj@nada.kth.se>]

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

> On Wed, 10 Mar 1999, Jim Blandy wrote:
> 
> >    When there is a C function which provides the same functionality as a
> > primitive, but with a different interface tailored for C's needs, it
> > usually has the same name as the primitive's C function, with the suffix
> > `_internal'.  Thus, `scm_env_ref_internal' is almost identical to
> > `scm_env_ref', except that it indicates an unbound variable in a manner
> > friendlier to C code.

[comment to Jim]

I'd prefer scm_<prefix list>_env_ref.

To me scm_env_ref_internal sounds like an operation which you use to
refer to something which is internal.

I think the names become easier to read if we only have prefixes.
With both prefixes and suffixes, the brain has to do more work when
extracting the most information carrying piece.

> Sorry for nitpicking, but I doubt that 'internal' is a good choice.  I may
> be wrong, but to my knowledge internal is typically used to indicate
> functions that only belong to the implementation and not to the interface. 
> I would feel uncomfortable to call 'internal' functions from a library.
> 
> Maybe it's possible to find a good alternative suffix?  

What about

  scm_c_env_ref ()

for an operation which has the role of a C version of a corresponding
Scheme primitive and

  scm_i_env_ref ()

for an operation mainly intended for use internally.

?

Just an observation.:

Several people have suggested to rename env --> environment.  While I
agree in general that long names are good, it seems like a pity to use
such a long "prefix": The majority of functions will get the prefix
`scm_environment_'.  That leaves less room for the informative part of
the name where we also want to be able to use long names...

/mdj