Re: [PATCH] Avoid `SCM_VALIDATE_LIST ()'

[Ludovic Courtès]

Hi,

Han-Wen Nienhuys <address@hidden> writes:

> -  return scm_c_memq (x, lst);
> +  for (; !SCM_NULL_OR_NIL_P (lst); lst = SCM_CDR (lst))
> +    {
> +      SCM_VALIDATE_CONS (2, lst);
>
> Looks cleaner to use SCM_CONS_P (or whatever it is called) as loop guard,
> so it is obviously correct, and crash if the lst is not properly terminated 
> after the loop (- perhaps only if we're not compiling in optimizing mode).

Two things: `SCM_NULL_OR_NIL_P ()' is different from `scm_is_pair ()',
and `SCM_NULL_OR_NIL_P ()' can be passed any object so it does work if
LST is a dotted list.

> On a tangent, is anyone still seriously considering to run Emacs atop GUILE?

There's Ken Reaburn's attempt at http://www.mit.edu/~raeburn/guilemacs/ ,
and there's also the Elisp support that's under `lang'.  I don't think
the former is really maintained.  The latter isn't actively maintained
either but I think it's in a pretty good shape.  Neil?

> -  SCM from_here;
> +  SCM from_here, hare;
>
> you could do the init to lst right here.  IMO it's neater not to have 
> uninitialized
> memory locations during program execution.

I find it nicer to have initialization right before the first use.  I'd
write it like this:

  for (from_here = hare = lst;
       !SCM_NULL_OR_NIL_P (from_here);
       from_here = SCM_CDR (from_here))

but I was trying to minimize changes.

> -;;;; Copyright (C) 2000, 2001, 2006 Free Software Foundation, Inc.
> +;;;; Copyright (C) 2000, 2001, 2006, 2008 Free Software Foundation, Inc.
>
> Can we do this in one fell swoop, adding 2008 to all files?

I wouldn't do that.  I think updating the copyright year *when* a change
is made is better: it allows people to see at a glance whether a file
has been changed at all recently and avoids pointless commits.  I use
this Emacs hook, which makes it painless:

  (add-hook 'write-file-hooks 'copyright-update)

However, the GNU maintainer's guide (see (info "(maintain) Copyright
Notices")) prefers the other way:

     To update the list of year numbers, add each year in which you have
  made nontrivial changes to the package.  (Here we assume you're using a
  publicly accessible revision control server, so that every revision
  installed is also immediately and automatically published.)  When you
  add the new year, it is not required to keep track of which files have
  seen significant changes in the new year and which have not.  It is
  recommended and simpler to add the new year to all files in the
  package, and be done with it for the rest of the year.

Thanks,
Ludo'.