Re: [patch] i18n, l10n, gettext and something more

[Neil Jerram]

>>>>> "Daniel" == Daniel Skarda <address@hidden> writes:

    Daniel>   this mail is about guile and
    Daniel> internationalization/localization issues (it starts with
    Daniel> i18n, it ends with i18n, but most of it is not related to
    Daniel> these issues at all :). Because the patch itself may seem
    Daniel> unlogical, I try to explain patch as it evolved.

I think it's great that you're working on this.

    Daniel>      1) it does not record exact position of strings

Out of interest, what does source-properties record?  Is it just the
beginning of each parenthesized expression?

    Daniel>      2) it always interprets escape sequences (even
    Daniel> thought when you do not want to)

When do you not want it to?

    Daniel>      3) it discards comments (surprising, is not it? :-)

Why do you need to translate strings in comments?
  
    Daniel>    In some Japanese coding, Japanese part of string is
    Daniel> encoded between two escape sequences - and between them
    Daniel> there can be arbitrary characters - even #\" can be there!
    Daniel> - so scheme parser gets confused on such sequences and
    Daniel> string parsing is terminated too early.

This sounds like a serious problem!

    Daniel>    It was very entertaining to extend guile in this way. I
    Daniel> have to admit that in one moment I had to say "stop" (I
    Daniel> caught myself playing with idea about writing parser for C
    Daniel> or Perl like language... it is a shame I have not enough
    Daniel> spare time (or sponsor :))

Perhaps not; we already have ctax to embarass us.  And Thomas Bushnell
is already working on Python.

    Daniel>    - Parser extension (lookup array: char -> procedure) is
    Daniel> global. That's bad thing - IMHO each port should have one
    Daniel> such array (arrays could be shared so do not worry about
    Daniel> wasted memory)

Agreed.

    Daniel>    - It should cooperate with modules. When you write
   
    Daniel>       (use-modules (ice-9 infix))

    Daniel>      you turn on infix sub-parser for all modules/ports
    Daniel> you are working with.

At a high level, yes.  As for the details, here you're really getting
into the whole question of how modules should relate to language
translators, about which there's already a lot of discussion in the
archive.
         
    Daniel>      Modularize it. scm_lreadr now looks something like
    Daniel> this:

    Daniel>        switch (getc ()) { case '"':

    Daniel>      I think the speed would not decrease too much if we
    Daniel> write

    Daniel>        call (array [c = getc ()], c, port)

I think it would.  The biggest current Guile performance problem is
startup time on older machines, and this would be right there in the
inner loop!

    Daniel>      Another solution is to have two parsers - one basic
    Daniel> and very fast parser in libguile and second one slightly
    Daniel> slower - but very extensible in module.

Yes, I think this is more likely to be the approach that translators
take, as it will probably prove impossible to write a single reader
that is efficient enough for all languages.  (Secondary parsers can
also be in C, of course.)

    Daniel>      For example some people tend to complain that it is
    Daniel> hard to count scheme parenthesis (they have not find the
    Daniel> church of Emacs - yet :) and they would like to use
    Daniel> brackets (or braces) in the same way they use parenthesis:

    Daniel>         [+ (+ 1 (+ 1 [+ 1 (+ 1 (+ 1 (+ 1 1)))]))]

    Daniel>      But scheme hackers say - no way! So what should such
    Daniel> poor little fellow do? (right answer: change the catcode
    Daniel> of braces and brackets so they would open/close lists...)

Unless the little fellow plans never to share any of his/her code, the
right answer is to learn the prevailing conventions and the tools that
are available to help with them, IMO.

    Daniel>   * There are exactly 27 bugs (unfortunately, all of them
    Daniel> are unknown).

:-)

    Daniel>   * I know about CVS branches, feature freeze etc. But
    Daniel> patch is clean, (afaik) does not break anything (infix
    Daniel> module can be marked as experimental) and i18n/l10n
    Daniel> features can be quite important.
    
    Daniel>     Could it be included in this stable release?

In my non-maintainerly opinion... Scheme code maybe, but C changes
definitely not; the performance impact of your proposed reader changes
is just too great (or at least too uncertain at this point).

        Neil