Re: [WIP-PATCHES] Lisp (and Scheme) jump format specifier and ngettext

[Bruno Haible]

Hi Miguel,

> I've detected that format checks don't detect correctly some common use
> cases for ngettext.  They aren't hard to accommodate when using English,
> but lead to unnatural messages on some other languages, e.g. the number
> may not be omitted on the translation.  The second patch adds test cases
> for that scenario in format-{lisp,scheme}-2.
> 
> The third patch is an attempt to solve the issue about the jump, but I'm
> not comfortable enough with it, perhaps adding a FAT_UNDEFINED type on
> top of the type tower instead of only having FAT_OBJECT is a better
> solution from the design perspective?  I'd need a bit of guidance here,
> because neither with this patch nor with the current implementation the
> following test fails, a check that should be useful too:
> --------------------------------------------
> # Invalid: narrowing type on the translation
> msgid "~a thing"
> msgid_plural "~a things"
> msgstr[0] "~d thing"
> msgstr[1] "~d things"
> --------------------------------------------
> 
> The first patch is a trivial one, as it seems to me a typo, but I wanted
> to check with you before pushing anything, as I've been out for a long
> time.  Should I push it already?

This first patch is correct. The first typo is from me, the second one from
Daiki.

The second patch is right as well. Simply, I had never thought at explicitly
listing plural cases in these unit tests.

> neither with this patch nor with the current implementation the
> following test fails, a check that should be useful too:
> --------------------------------------------
> # Invalid: narrowing type on the translation
> msgid "~a thing"
> msgid_plural "~a things"
> msgstr[0] "~d thing"
> msgstr[1] "~d things"
> --------------------------------------------

Yes, it would be useful to add this test to the test suite. In format.h we
describe the meaning of the 'equality' argument:

     Verify that the argument types/names in msgid_descr and those in
     msgstr_descr are the same (if equality=true), or (if equality=false)
     that those of msgid_descr extend those of msgstr_descr (i.e.
     msgstr_descr may omit some of the arguments of msgid_descr).

This specification is correct; in a msgstr[i] some arguments may be omitted,
but an msgstr[i] should not assume that the argument is an integer when
originally it could be any object.

I think this code is wrong:

  if (equality)
    ...
  else
    {
      struct format_arg_list *intersection =
        make_intersected_list (copy_list (spec1->list),
                               copy_list (spec2->list));

      if (!(intersection != NULL
            && (normalize_list (intersection),
                equal_list (intersection, spec2->list))))
        {
          if (error_logger)
            error_logger (_("format specifications in '%s' are not a subset of 
those in '%s'"),
                          pretty_msgstr, pretty_msgid);
          err = true;
        }
    }

My first thought here is that we probably need something different than the
'make_intersected_list' function. Assuming the lists have been normalized to
match (like make_intersected_list does), what are the valid shapes of
spec2->list when spec1->list is known to look like this:
   (t0 ... t_{k-1} |repeat: r_0 ... r_{l-1})           ; infinite
or
   (t0 ... t_{k-1})                                    ; finite
?

Bruno