abstracting Lisp strings - macro name convention?

abstracting Lisp strings - macro name convention?

[Ken Raeburn]

I'd like to give Lisp_String the same treatment I gave Lisp_Cons a
while back, hiding all the knowledge about the internal structure in
the lisp.h macros, except for the creation and GC code.  The goal, of
course, is to make the string implementation more easily replaceable,
either with Guile code or anything else someone comes up with to
improve string handling.

The string-related macros currently follow two different naming
conventions.  One set (STRING_BYTES, STRING_MULTIBYTE,
SET_STRING_BYTES) has been around a long time, but doesn't cover all
the functionality I need; most code still uses XSTRING()->data to get
at the contents.  And there are some "convenience macros", some of
which are already closer to what I need:

    /* Convenience macros for dealing with Lisp strings.  */

    #define SREF(string, index)     XSTRING (string)->data[index]
    #define SDATA(string)           XSTRING (string)->data
    #define SCHARS(string)          XSTRING (string)->size
    #define SBYTES(string)          STRING_BYTES (XSTRING (string))
    #define SMBP(string)            STRING_MULTIBYTE (string)

But these short names don't follow the naming convention used for
other string macros, usually STRING_FOO or SET_STRING_FOO.  And
outside of xdisp.c, they're not used much.  However, they are in line
with the names for macros for accessing Lisp arrays.

If there are no objections to these names, I'll go ahead and start
working on the changes, adding similar names for assignment operations
and whatever else is needed; if the longer STRING_ names are
preferred, I'll work up some new names in that style to use.

Ken

Re: abstracting Lisp strings - macro name convention?

[Richard Stallman]

SMBP is too terse.  That won't be used so often
that we cannot afford a longer and more meaningful name.

Re: abstracting Lisp strings - macro name convention?

[Ken Raeburn]

Richard Stallman <rms@gnu.org> writes:
> SMBP is too terse.  That won't be used so often
> that we cannot afford a longer and more meaningful name.

Okay, I'll use longer names.  Probably something like this set:

  STRING_DATA(obj)      /* produces a char* */
  STRING_REF(obj,index)
  STRING_SET(obj,index,newbyteval)
  STRING_INTERVALS(obj)
  STRING_SET_INTERVALS(obj,interval)
  STRING_NBYTES(obj)    /* STRING_BYTES exists, takes Lisp_String ptr */
  STRING_NCHARS(obj)
  STRING_MULTIBYTE(obj) /* already present */
  STRING_SET_UNIBYTE(obj) /* all uses of SET_STRING_BYTES are of the
                             form SET_STRING_BYTES(XSTRING(x),-1) */

And I'll remove or rename the macros operating on Lisp_String struct
pointers or with the terse names.

  STRING_SET_BYTES(ptr,-1) -> STRING_SET_UNIBYTE(obj)
  STRING_BYTES(ptr)        -> STRING_NBYTES(obj)
  XSTRING(obj)->foo        -> STRING_foo(obj),STRING_SET_foo(obj,...)
  SREF  -> STRING_REF
  SDATA -> STRING_DATA
  etc


With a pervasive change like this, do you really want separate
checkins for each file and detailed function-level change log and CVS
log entries for everything affected?  It's tedious, but doable; I'm
just unclear on how important you feel that level of detail is for
pervasive changes of such a simple nature.  Occasionally other changes
have been checked in with log entries like "all callers changed"; most
(but not all) of them are for static functions, so it's still
describing changes confined to the one file.

Ken

Re: abstracting Lisp strings - macro name convention?

[Stefan Monnier]

>   SREF  -> STRING_REF
>   SDATA -> STRING_DATA

I think the two names above should not be changed.


	Stefan

Re: abstracting Lisp strings - macro name convention?

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> >   STRING_REF(obj,index)
> >   STRING_SET(obj,index,newbyteval)
> 
> Wouldn't it be more consistent to name these
> 
>   STRING_AREF(obj,index)
>   STRING_ASET(obj,index,newbyteval)

Why?  `aref' is a noun-verb pair meaning `array reference'; since
strings are generally thought of as _being_ arrays, not _containing_
arrays,`string array reference' sounds redundant.

A traditional name in lisp, btw, is `sref', but it's not used that much,
so I think it makes sense to use a longer name here.

-Miles
-- 
Freedom's just another word, for nothing left to lose   --Janis Joplin

Re: abstracting Lisp strings - macro name convention?

[Henrik Enberg]

storm@cua.dk (Kim F. Storm) writes:

> Ken Raeburn <raeburn@raeburn.org> writes:
>
>>   STRING_REF(obj,index)
>>   STRING_SET(obj,index,newbyteval)
>
> Wouldn't it be more consistent to name these
>
>   STRING_AREF(obj,index)
>   STRING_ASET(obj,index,newbyteval)

They are called `string-ref' and `string-set!' in scheme.  So if this is
done for a future switch to Guile, the the first alternative is probably
better.

-- 
Booting... /vmemacs.el

Re: abstracting Lisp strings - macro name convention?

[Kim F. Storm]

Ken Raeburn <raeburn@raeburn.org> writes:

>   STRING_REF(obj,index)
>   STRING_SET(obj,index,newbyteval)

Wouldn't it be more consistent to name these

  STRING_AREF(obj,index)
  STRING_ASET(obj,index,newbyteval)

> 
> With a pervasive change like this, do you really want separate
> checkins for each file and detailed function-level change log and CVS
> log entries for everything affected?  It's tedious, but doable; I'm
> just unclear on how important you feel that level of detail is for
> pervasive changes of such a simple nature.  Occasionally other changes
> have been checked in with log entries like "all callers changed"; most
> (but not all) of them are for static functions, so it's still
> describing changes confined to the one file.

For this case, I think it is acceptable (preferable IMO) to just list
the files where you make the changes, i.e. something like

        * file.c, file2.c, file3.c
        * file4.c, file5.c: Use new STRING_ macros.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: abstracting Lisp strings - macro name convention?

[Richard Stallman]

    > SMBP is too terse.  That won't be used so often
    > that we cannot afford a longer and more meaningful name.

    Okay, I'll use longer names.  Probably something like this set:

It may be good to use short names like SREF and SDATA for the commonly
used accessors.  They are used very often.  It wasn't the terseness of
the "S", but the terseness of the "MBP", that I see as undesirable.

    With a pervasive change like this, do you really want separate
    checkins for each file and detailed function-level change log and CVS
    log entries for everything affected?

No, there is no need.  It is sufficient to describe the changes
in the macros and then say "all references changed."