10646 and progr.languages

This is a forward message from sc22wg20 mailing list. It shows what
SC22 people think about (at least some of them) about ISO 10 646/
natural languages.

===================================================================


Walt says:

>Short of language translation, I know of no way to make programs
>portable (at the source level) across natural languages.

If the programs were transmitted in an edited way (as we are used to exchange
texts in WP formats) and that each compiler would know that format
(i.e. ISO/IEC 10646 code), that would be portable. That was
my ideal proposal that each compiler, to conform to a language, should be
able to read source code in ISO/IEC 10646, even if the program contains only
characters from the ISO/IEC 646 repertoire...

>There are two aspects of portability that are important.  One is the
>ability to just compile a program on my machine which presumes a
>different character set than that used by the writer of the program.
>The other is to understand it sufficiently to assure myself that there
>are no trojan horses in the code or to modify it to better suit my
>needs.

I fully agree with that and the examples I gave were not trying to hide that.
But if you just want to transport your program to another machine that is
antediluvian and just want to compile it, the fallback I propose would solve
that problem. It is not my prefered solution though, it is the worst case,
just to exorcize those who show me the devils of unportability and curse
non-English programmers with that believe-or-die threat.

>Incidentally I would have transformed the example as follows.
>  A0000002=1
>  A0000001=A0000002+1 /* ABCDEFGHIJKL(A0000002) is not a portable name */

That is a good suggestion and improvement if it is feasible.

>It is really evil when comments lie.

Yes, but it is extremely frequent, particularly in patched programs.

>> >  This was just a manifest to help the reflection of those who
>> >  proclaim that portable programs should not use more than a
>> >  repertoire of about 40 characters in variable names not to affect
>> >  portability.
>
>Forty(40) is untenable.  C and C++ are case sensitive so the Abc and
>ABC are different variables.  Whats even more important is the
>conventional usage of case in C programs to remind the reader about
>additional properties of the variable, [...]

Of course for a given language the preprocessor needs adaptation to that
language. What I gave was but an example in an hypothetical language.

>but the major languages are regularly revisited by committees who are
>only beginning to look at the i18n implications. From what I have seen
>they are all diverging with different incomplete solutions.
>
>I think the answer is insist on ISO 10646 and to not adapt (or even
>waste time thinking about) partial hacks for the short term.  Such
>hacks will just be more baggage that has to be preserved forever.

If the conclusion were that I would only applaude. Then nobody would say
again that portability can't be achieve if we use rich character sets.
In fact if I were a dictator I would impose 10646 on compilers and nothing else
but I am open to compromises to avoid pacts with the devil (which, if forced,
you're morally free to break any time).

Alain LaBonte'
Minist<`e>re des Communications du Qu<e'>bec




--Boundary (ID uEbHHWxWEwCKT9wM3evJ5w)

Received on Friday, 12 November 1993 00:16:52 UTC