[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patch] i18n, l10n, gettext and something more
From: |
Neil Jerram |
Subject: |
Re: [patch] i18n, l10n, gettext and something more |
Date: |
01 Aug 2001 20:52:45 +0100 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
>>>>> "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
- Re: [patch] i18n, l10n, gettext and something more, Thien-Thi Nguyen, 2001/08/01
- Re: [patch] i18n, l10n, gettext and something more, Daniel Skarda, 2001/08/01
- Re: [patch] i18n, l10n, gettext and something more, Marius Vollmer, 2001/08/01
- Re: [patch] i18n, l10n, gettext and something more, Daniel Skarda, 2001/08/02
- Re: [patch] i18n, l10n, gettext and something more,
Neil Jerram <=
- Re: [patch] i18n, l10n, gettext and something more, Daniel Skarda, 2001/08/02
- Re: [patch] i18n, l10n, gettext and something more, Neil Jerram, 2001/08/02
- Re: [patch] i18n, l10n, gettext and something more, Marius Vollmer, 2001/08/02
- Re: [patch] i18n, l10n, gettext and something more, Daniel Skarda, 2001/08/04
- Re: [patch] i18n, l10n, gettext and something more, Marius Vollmer, 2001/08/01