Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #7258 > unrolled thread

Typography of programs

Back to article view | Back to comp.lang.c

Contents

  Typography of programs jacob navia <jacob@spamsink.net> - 2011-06-30 02:06 +0200
    Re: Typography of programs Robert Wessel <robertwessel2@yahoo.com> - 2011-06-29 19:57 -0500
      Re: Typography of programs jacob navia <jacob@spamsink.net> - 2011-06-30 07:19 +0200
        Re: Typography of programs Robert Wessel <robertwessel2@yahoo.com> - 2011-06-30 01:08 -0500
          Re: Typography of programs jacob navia <jacob@spamsink.net> - 2011-06-30 08:16 +0200
            Re: Typography of programs Robert Wessel <robertwessel2@yahoo.com> - 2011-06-30 01:56 -0500
              Re: Typography of programs jacob navia <jacob@spamsink.net> - 2011-06-30 09:06 +0200
                Re: Typography of programs Robert Wessel <robertwessel2@yahoo.com> - 2011-06-30 02:25 -0500
                  Re: Typography of programs jacob navia <jacob@spamsink.net> - 2011-06-30 10:21 +0200
    Re: Typography of programs China Blue Dolls <chine.bleu@yahoo.com> - 2011-06-29 21:43 -0700
      Re: Typography of programs jacob navia <jacob@spamsink.net> - 2011-06-30 07:21 +0200
        Re: Typography of programs China Blue Dolls <chine.bleu@yahoo.com> - 2011-06-29 22:49 -0700
    Re: Typography of programs Ian Collins <ian-news@hotmail.com> - 2011-06-30 16:59 +1200
      Re: Typography of programs jacob navia <jacob@spamsink.net> - 2011-06-30 07:23 +0200
        Re: Typography of programs Ian Collins <ian-news@hotmail.com> - 2011-06-30 17:25 +1200
          Re: Typography of programs China Blue Dolls <chine.bleu@yahoo.com> - 2011-06-29 22:52 -0700
            Re: Typography of programs Ian Collins <ian-news@hotmail.com> - 2011-06-30 17:53 +1200
              Re: Typography of programs China Blue Dolls <chine.bleu@yahoo.com> - 2011-06-29 22:58 -0700
                Re: Typography of programs Ian Collins <ian-news@hotmail.com> - 2011-06-30 21:11 +1200
                  Re: Typography of programs jacob navia <jacob@spamsink.net> - 2011-06-30 11:17 +0200
                    Re: Typography of programs Angel <angel+news@spamcop.net> - 2011-06-30 12:19 +0000
                      Re: Typography of programs jacob navia <jacob@spamsink.net> - 2011-06-30 17:30 +0200
                        Re: Typography of programs Angel <angel+news@spamcop.net> - 2011-06-30 15:40 +0000
                          Re: Typography of programs China Blue Dolls <chine.bleu@yahoo.com> - 2011-06-30 12:02 -0700
                        Re: Typography of programs Ralf Damaschke <rwspam@gmx.de> - 2011-06-30 20:13 +0000
                        Re: Typography of programs "Herbert Rosenau" <os2guy@pc-rosenau.de> - 2011-07-02 22:21 +0000
                          Re: Typography of programs jacob navia <jacob@spamsink.net> - 2011-07-03 01:22 +0200
                      Re: Typography of programs China Blue Dolls <chine.bleu@yahoo.com> - 2011-06-30 11:43 -0700
        Re: Typography of programs Angel <angel+news@spamcop.net> - 2011-06-30 08:20 +0000
        Re: Typography of programs Nobody <nobody@nowhere.com> - 2011-06-30 17:13 +0100
        Re: Typography of programs "Herbert Rosenau" <os2guy@pc-rosenau.de> - 2011-07-01 08:52 +0000
          Re: Typography of programs jacob navia <jacob@spamsink.net> - 2011-07-01 10:58 +0200
            Re: Typography of programs Angel <angel+news@spamcop.net> - 2011-07-01 09:27 +0000
              Re: Typography of programs jacob navia <jacob@spamsink.net> - 2011-07-01 12:04 +0200
                Re: Typography of programs Angel <angel+news@spamcop.net> - 2011-07-01 12:42 +0000
          Re: Typography of programs China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-01 02:05 -0700
      Re: Typography of programs "Wolfgang.Draxinger" <Wolfgang.Draxinger@physik.uni-muenchen.de> - 2011-07-01 18:10 +0200
        Re: Typography of programs Ben Pfaff <blp@cs.stanford.edu> - 2011-07-01 09:21 -0700
          Re: Typography of programs China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-01 14:36 -0700
            Re: Typography of programs Joe Wright <joewwright@comcast.net> - 2011-07-01 19:29 -0400
              Re: Typography of programs Michael Press <rubrum@pacbell.net> - 2011-07-02 11:22 -0700
            Re: Typography of programs cri@tiac.net (Richard Harter) - 2011-07-01 23:59 +0000
    Re: Typography of programs Ike Naar <ike@iceland.freeshell.org> - 2011-06-30 07:48 +0000
      Re: Typography of programs "Joachim Schmitz" <nospam.jojo@schmitz-digital.de> - 2011-06-30 10:03 +0200
      Re: Typography of programs jacob navia <jacob@spamsink.net> - 2011-06-30 10:32 +0200
      Re: Typography of programs China Blue Dolls <chine.bleu@yahoo.com> - 2011-06-30 01:34 -0700
        Re: Typography of programs Chris H <chris@phaedsys.org> - 2011-06-30 11:06 +0100
          Re: Typography of programs Michael Press <rubrum@pacbell.net> - 2011-06-30 16:05 -0700
        Re: Typography of programs Seebs <usenet-nospam@seebs.net> - 2011-06-30 14:52 +0000
          Re: Typography of programs China Blue Dolls <chine.bleu@yahoo.com> - 2011-06-30 11:39 -0700
            Re: Typography of programs Seebs <usenet-nospam@seebs.net> - 2011-06-30 20:55 +0000
              Re: Typography of programs "Herbert Rosenau" <os2guy@pc-rosenau.de> - 2011-07-02 22:21 +0000
    Re: Typography of programs Ben Pfaff <blp@cs.stanford.edu> - 2011-06-30 09:11 -0700
      Re: Typography of programs jacob navia <jacob@spamsink.net> - 2011-06-30 21:50 +0200
        Re: Typography of programs Ian Collins <ian-news@hotmail.com> - 2011-07-01 08:26 +1200
          Re: Typography of programs "Herbert Rosenau" <os2guy@pc-rosenau.de> - 2011-07-02 22:21 +0000
        Re: Typography of programs Ben Pfaff <blp@cs.stanford.edu> - 2011-06-30 13:38 -0700
    Re: Typography of programs gordonb.9z4n8@burditt.org (Gordon Burditt) - 2011-07-01 23:16 -0500
      Re: Typography of programs Ben Pfaff <blp@cs.stanford.edu> - 2011-07-01 21:46 -0700
      Re: Typography of programs China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-01 21:52 -0700
        Re: Typography of programs gordonb.e78ud@burditt.org (Gordon Burditt) - 2011-07-02 02:14 -0500
          Re: Typography of programs China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-02 00:38 -0700
            Re: Typography of programs Keith Thompson <kst-u@mib.org> - 2011-07-02 15:00 -0700
            Re: Typography of programs Seebs <usenet-nospam@seebs.net> - 2011-07-04 00:20 +0000
              Re: Typography of programs China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-03 18:28 -0700
                Re: Typography of programs Seebs <usenet-nospam@seebs.net> - 2011-07-04 04:42 +0000
                  Re: Typography of programs Stephen Sprunk <stephen@sprunk.org> - 2011-07-04 01:01 -0500
                    Re: Typography of programs Dr Nick <3-nospam@temporary-address.org.uk> - 2011-07-04 08:15 +0100
                      Re: Typography of programs China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-04 00:40 -0700
                        Re: Typography of programs gordonb.3nbmk@burditt.org (Gordon Burditt) - 2011-07-04 07:42 -0500
                          Re: Typography of programs China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-04 07:15 -0700
                            Re: Typography of programs Seebs <usenet-nospam@seebs.net> - 2011-07-05 20:21 +0000
                      Re: Typography of programs Stephen Sprunk <stephen@sprunk.org> - 2011-07-04 09:56 -0500
                        Re: Typography of programs Seebs <usenet-nospam@seebs.net> - 2011-07-05 20:21 +0000
                    Re: Typography of programs Angel <angel+news@spamcop.net> - 2011-07-04 08:04 +0000
                      Re: Typography of programs Stephen Sprunk <stephen@sprunk.org> - 2011-07-04 09:22 -0500
                    Re: Typography of programs Seebs <usenet-nospam@seebs.net> - 2011-07-05 20:21 +0000
                      Re: Typography of programs jacob navia <jacob@spamsink.net> - 2011-07-05 22:45 +0200
                        Re: Typography of programs Willem <willem@turtle.stack.nl> - 2011-07-05 21:52 +0000
                        Re: Typography of programs Squeamizh <squeamz@hotmail.com> - 2011-07-05 20:03 -0700
                          Re: Typography of programs jacob navia <jacob@spamsink.net> - 2011-07-06 08:46 +0200
                            Re: Typography of programs China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-06 00:08 -0700
                            Re: Typography of programs Willem <willem@turtle.stack.nl> - 2011-07-06 12:12 +0000
                            Re: Typography of programs Stephen Sprunk <stephen@sprunk.org> - 2011-07-06 11:10 -0500
                        Re: Typography of programs Dr Nick <3-nospam@temporary-address.org.uk> - 2011-07-06 07:42 +0100
      Re: Typography of programs jacob navia <jacob@spamsink.net> - 2011-07-02 11:02 +0200
        Re: Typography of programs Dr Nick <3-nospam@temporary-address.org.uk> - 2011-07-02 10:22 +0100
          Re: Typography of programs jacob navia <jacob@spamsink.net> - 2011-07-02 13:51 +0200
            Re: Typography of programs Dr Nick <3-nospam@temporary-address.org.uk> - 2011-07-02 15:45 +0100
        Re: Typography of programs gordonb.piror@burditt.org (Gordon Burditt) - 2011-07-02 07:31 -0500
          Re: Typography of programs Michael Press <rubrum@pacbell.net> - 2011-07-03 01:47 -0700
        Re: Typography of programs Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-03 03:10 -0700
          Re: Typography of programs superpollo <superpollo@tznvy.pbz> - 2011-07-04 15:19 +0200
        Re: Typography of programs "Herbert Rosenau" <os2guy@pc-rosenau.de> - 2011-07-03 19:39 +0000
          Re: Typography of programs "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-07-03 14:01 -0700
            Re: Typography of programs Keith Thompson <kst-u@mib.org> - 2011-07-03 14:26 -0700
              Re: Typography of programs "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-07-04 01:19 -0700
                Re: Typography of programs Keith Thompson <kst-u@mib.org> - 2011-07-04 14:19 -0700
          Re: Typography of programs Michael Press <rubrum@pacbell.net> - 2011-07-03 20:46 -0700
            Re: Typography of programs Seebs <usenet-nospam@seebs.net> - 2011-07-04 04:42 +0000
            Re: Typography of programs Stephen Sprunk <stephen@sprunk.org> - 2011-07-04 00:43 -0500
              Re: Typography of programs China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-03 23:03 -0700
                Re: Typography of programs James Kuyper <jameskuyper@verizon.net> - 2011-07-04 06:32 -0400
                Re: Typography of programs Stephen Sprunk <stephen@sprunk.org> - 2011-07-04 09:08 -0500
            Re: Typography of programs Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-07-07 18:01 +0300
    Re: Typography of programs Dr Nick <3-nospam@temporary-address.org.uk> - 2011-07-02 16:28 +0100
    Re: Typography of programs pacman@kosh.dhis.org (Alan Curry) - 2011-07-02 20:52 +0000
      Re: Typography of programs Stephen Sprunk <stephen@sprunk.org> - 2011-07-04 00:50 -0500
    Re: Typography of programs "io_x" <a@b.c.invalid> - 2011-07-03 10:04 +0200
      Re: Typography of programs "io_x" <a@b.c.invalid> - 2011-07-03 10:27 +0200
    Re: Typography of programs Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-03 03:19 -0700
    Re: Typography of programs "BartC" <bc@freeuk.com> - 2011-07-06 10:14 +0100
      Re: Typography of programs China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-06 02:48 -0700
        Re: Typography of programs "BartC" <bc@freeuk.com> - 2011-07-06 11:47 +0100
          Re: Typography of programs jacob navia <jacob@spamsink.net> - 2011-07-06 14:46 +0200
            Re: Typography of programs China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-06 07:44 -0700
            Re: Typography of programs Ian Collins <ian-news@hotmail.com> - 2011-07-07 07:50 +1200

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#7258 — Typography of programs

I am learning the Macintosh environment with the idea of porting the IDE 
of lcc-win to the mac.

What is nice in the mac is how easily you can set up a text display
and integrate images and other data into the text. It supports RTF text
(as windows too, by the way) and I was again wondering at implementing
an old idea that I wanted to implement already into wedit some years ago.

Actually, when C was conceived there weren't any bit mapped graphics
or any such hardware that we now consider common place.

The typography of C remained the same, as all other computer languages,
obsessed with the character sets from 32 to 127 ASCII codes. Then, we
write != instead of the inequality sign, = instead of the assignment
arrow, "&&" instead of /\,  "||" instead of \/.

Programs would be clearer if we would use today's hardware to show
the usual signs, instead of constructs adapted to the teletype
typewriter of the seventies.

Unicode now offers all possible signs for displaying in our programs,
and it would be a progress if C would standardize some codes to be
used isnstead of the usual != and &&, etc.

We have in iso646.h
#define and     &&
#define and_eq  &=
#define bitand  &
#define bitor   |
#define compl   ~

We could have in some isoXXX.h
#define ≠ !=
#define ⋀ and
#define ⋁ or
#define ≤ <=
#define ≥ >=

etc.

Using ← for assignment would avoid the common beginner's error of using 
= instead of == and programs would look less horrible.

All this would be done first in output only to avoid requiring a new C
keyboard even though that can be done later. You would still type !=
but you would obtain ≠ in output in the same way that you type first the
accent, then the later under the accent and you obtain one character.

The standardization committee would be crucial in making this change 
smooth but... I fear the won't be so enthusiastic...

Just some thoughts


jacob

[toc] | [next] | [standalone]

#7259

On Thu, 30 Jun 2011 02:06:26 +0200, jacob navia <jacob@spamsink.net>
wrote:

>I am learning the Macintosh environment with the idea of porting the IDE 
>of lcc-win to the mac.
>
>What is nice in the mac is how easily you can set up a text display
>and integrate images and other data into the text. It supports RTF text
>(as windows too, by the way) and I was again wondering at implementing
>an old idea that I wanted to implement already into wedit some years ago.
>
>Actually, when C was conceived there weren't any bit mapped graphics
>or any such hardware that we now consider common place.
>
>The typography of C remained the same, as all other computer languages,
>obsessed with the character sets from 32 to 127 ASCII codes. Then, we
>write != instead of the inequality sign, = instead of the assignment
>arrow, "&&" instead of /\,  "||" instead of \/.
>
>Programs would be clearer if we would use today's hardware to show
>the usual signs, instead of constructs adapted to the teletype
>typewriter of the seventies.
>
>Unicode now offers all possible signs for displaying in our programs,
>and it would be a progress if C would standardize some codes to be
>used isnstead of the usual != and &&, etc.
>
>We have in iso646.h
>#define and     &&
>#define and_eq  &=
>#define bitand  &
>#define bitor   |
>#define compl   ~
>
>We could have in some isoXXX.h
>#define ? !=
>#define ? and
>#define ? or
>#define ? <=
>#define ? >=
>
>etc.
>
>Using ? for assignment would avoid the common beginner's error of using 
>= instead of == and programs would look less horrible.
>
>All this would be done first in output only to avoid requiring a new C
>keyboard even though that can be done later. You would still type !=
>but you would obtain ? in output in the same way that you type first the
>accent, then the later under the accent and you obtain one character.
>
>The standardization committee would be crucial in making this change 
>smooth but... I fear the won't be so enthusiastic...



You'd have a hard time exchanging programs with
non-extended-character-set implementations (not limiting things to
Unicode implementations, on the assumption that some extended, but
non-Unicode implementations would be plausible).

I'm afraid you'd end up with more di/trigraphs.  The horror of that
will probably send anyone running.

FWIW, Java allows the use of Unicode (in fact it's specified), and you
can use Unicode characters in names (so you can assign the value 3.14
to a variable named U+03C0).  But they didn't use any of the extended
characters for operators.

Nor is this a particularly new concept - APL (circa 1964 for the first
implementations, although the initial papers, with most of the
symbology, date to about 1961) required/could use a extended character
set.  IBM (and others) manufactured terminals and printers with the
APL character set available for output and on the keyboard.  IBM even
had Selectric typewriter balls with the APL set.

[toc] | [prev] | [next] | [standalone]

#7269

Le 30/06/11 02:57, Robert Wessel a écrit :
>
> You'd have a hard time exchanging programs with
> non-extended-character-set implementations (not limiting things to
> Unicode implementations, on the assumption that some extended, but
> non-Unicode implementations would be plausible).

Hard time?

It would mean just #include isoXXX.h. That would transform those codes
into Ascii again. A pass through the preprocessor and that would be
done!

>
> I'm afraid you'd end up with more di/trigraphs.  The horror of that
> will probably send anyone running.
>

We have NOW digraphs!!! What else is != than a digraph for ≠ ?????
Those digraphs would stay of course.

> FWIW, Java allows the use of Unicode (in fact it's specified), and you
> can use Unicode characters in names (so you can assign the value 3.14
> to a variable named U+03C0).  But they didn't use any of the extended
> characters for operators.
>

Does Java have Big problems because of Unicode? I would bet not!

> Nor is this a particularly new concept - APL (circa 1964 for the first
> implementations, although the initial papers, with most of the
> symbology, date to about 1961) required/could use a extended character
> set.  IBM (and others) manufactured terminals and printers with the
> APL character set available for output and on the keyboard.  IBM even
> had Selectric typewriter balls with the APL set.
>

It was my first programming language. It is great still today.

[toc] | [prev] | [next] | [standalone]

#7277

On Thu, 30 Jun 2011 07:19:59 +0200, jacob navia <jacob@spamsink.net>
wrote:

>Le 30/06/11 02:57, Robert Wessel a écrit :
>>
>> You'd have a hard time exchanging programs with
>> non-extended-character-set implementations (not limiting things to
>> Unicode implementations, on the assumption that some extended, but
>> non-Unicode implementations would be plausible).
>
>Hard time?
>
>It would mean just #include isoXXX.h. That would transform those codes
>into Ascii again. A pass through the preprocessor and that would be
>done!


That doesn't help.  You'd have to convert the extended characters
before you were able to run the preprocessor on the new
implementation.

And no, you can't run the preprocessor to "undo" the macros, since
that'll preprocess the whole program, which most assuredly is *not*
what anyone wants to transfer to the new system.

Nor is a simple character-by-character translation really plausible
(something you'd run before transferring the code).  It would need to
tokenize at least as well as the C program.



>>
>> I'm afraid you'd end up with more di/trigraphs.  The horror of that
>> will probably send anyone running.
>>
>
>We have NOW digraphs!!! What else is != than a digraph for ? ?????
>Those digraphs would stay of course.
>
>> FWIW, Java allows the use of Unicode (in fact it's specified), and you
>> can use Unicode characters in names (so you can assign the value 3.14
>> to a variable named U+03C0).  But they didn't use any of the extended
>> characters for operators.
>>
>
>Does Java have Big problems because of Unicode? I would bet not!


It is the way *all* implementations work - so by definition it
wouldn't.  My point was that they still avoided the extended
characters in predefined operators, while allowing programmers to use
them.

[toc] | [prev] | [next] | [standalone]

#7278

Le 30/06/11 08:08, Robert Wessel a écrit :
>
> Nor is a simple character-by-character translation really plausible
> (something you'd run before transferring the code).  It would need to
> tokenize at least as well as the C program.
>

????
Can you elaborate?

Why a simple preprocessor that transforms a small set of
Unicode characters into Ascii equivalents would not work?

Again: What I propose is that a small set of Unicode characters,
fixed by ISO is accepted instead of the digraphs in use today.

This means that !=, &&, ||, and other digraphs are translated into ONE
character, that's all.

>>
>> Does Java have Big problems because of Unicode? I would bet not!
>
>
> It is the way *all* implementations work - so by definition it
> wouldn't.  My point was that they still avoided the extended
> characters in predefined operators, while allowing programmers to use
> them.

Well, if ISO would do this, all C implementations would use the same
characters.

[toc] | [prev] | [next] | [standalone]

#7279

On Thu, 30 Jun 2011 08:16:50 +0200, jacob navia <jacob@spamsink.net>
wrote:

>Le 30/06/11 08:08, Robert Wessel a écrit :
>>
>> Nor is a simple character-by-character translation really plausible
>> (something you'd run before transferring the code).  It would need to
>> tokenize at least as well as the C program.
>>
>
>????
>Can you elaborate?
>
>Why a simple preprocessor that transforms a small set of
>Unicode characters into Ascii equivalents would not work?


What happens when you translate:

(a) if (a \U+2260 b)
(b) strcpy(s, "a\U+2260b")

from Unicode to ASCII?  With or with or without isoXXX.h defined?  And
then back to Unicode?

And what about <<= in ASCII?  You had better not translate that to
U+003C, U+2264 in Unicode.


>Again: What I propose is that a small set of Unicode characters,
>fixed by ISO is accepted instead of the digraphs in use today.
>
>This means that !=, &&, ||, and other digraphs are translated into ONE
>character, that's all.
>
>>>
>>> Does Java have Big problems because of Unicode? I would bet not!
>>
>>
>> It is the way *all* implementations work - so by definition it
>> wouldn't.  My point was that they still avoided the extended
>> characters in predefined operators, while allowing programmers to use
>> them.
>
>Well, if ISO would do this, all C implementations would use the same
>characters.


Except for the C implementations not using Unicode.

Just translating C source from ASCII to EBCDIC is more pain than most
of us want to go through already.  This would be worse.

[toc] | [prev] | [next] | [standalone]

#7280

Le 30/06/11 08:56, Robert Wessel a écrit :
> On Thu, 30 Jun 2011 08:16:50 +0200, jacob navia<jacob@spamsink.net>
> wrote:
>
>> Le 30/06/11 08:08, Robert Wessel a écrit :
>>>
>>> Nor is a simple character-by-character translation really plausible
>>> (something you'd run before transferring the code).  It would need to
>>> tokenize at least as well as the C program.
>>>
>>
>> ????
>> Can you elaborate?
>>
>> Why a simple preprocessor that transforms a small set of
>> Unicode characters into Ascii equivalents would not work?
>
>
> What happens when you translate:
>
> (a) if (a \U+2260 b)
> (b) strcpy(s, "a\U+2260b")
>
> from Unicode to ASCII?  With or with or without isoXXX.h defined?  And
> then back to Unicode?
>


You have completely misunderstood. You would never see
\U+2260
That is 7 chars.

You would see ONE Unicode character in the input!

Only THOSE characters would be translated into digraphs.

Conceptually, it is exactly like digraphs and trigraphs
revisited but in the OTHER direction: starting with today's digraphs
!= etc you would get SINGLE characters.

> And what about<<= in ASCII?  You had better not translate that to
> U+003C, U+2264 in Unicode.
>

Yes but that would never happen, see above.

>
>> Again: What I propose is that a small set of Unicode characters,
>> fixed by ISO is accepted instead of the digraphs in use today.
>>
>> This means that !=,&&, ||, and other digraphs are translated into ONE
>> character, that's all.
>>
>>>>
>>>> Does Java have Big problems because of Unicode? I would bet not!
>>>
>>>
>>> It is the way *all* implementations work - so by definition it
>>> wouldn't.  My point was that they still avoided the extended
>>> characters in predefined operators, while allowing programmers to use
>>> them.
>>
>> Well, if ISO would do this, all C implementations would use the same
>> characters.
>
>
> Except for the C implementations not using Unicode.
>
> Just translating C source from ASCII to EBCDIC is more pain than most
> of us want to go through already.  This would be worse.


Why?

In environments where this is not desired, we could keep the digraphs.
A very long transition period of 25 years could be used to slowly
move to Unicode. You can still program in digraphs and trigraphs TODAY
if you wish so. This would be the same.

[toc] | [prev] | [next] | [standalone]

#7281

On Thu, 30 Jun 2011 09:06:21 +0200, jacob navia <jacob@spamsink.net>
wrote:

>Le 30/06/11 08:56, Robert Wessel a écrit :
>> On Thu, 30 Jun 2011 08:16:50 +0200, jacob navia<jacob@spamsink.net>
>> wrote:
>>
>>> Le 30/06/11 08:08, Robert Wessel a écrit :
>>>>
>>>> Nor is a simple character-by-character translation really plausible
>>>> (something you'd run before transferring the code).  It would need to
>>>> tokenize at least as well as the C program.
>>>>
>>>
>>> ????
>>> Can you elaborate?
>>>
>>> Why a simple preprocessor that transforms a small set of
>>> Unicode characters into Ascii equivalents would not work?
>>
>>
>> What happens when you translate:
>>
>> (a) if (a \U+2260 b)
>> (b) strcpy(s, "a\U+2260b")
>>
>> from Unicode to ASCII?  With or with or without isoXXX.h defined?  And
>> then back to Unicode?
>>
>
>
>You have completely misunderstood. You would never see
>\U+2260
>That is 7 chars.
>
>You would see ONE Unicode character in the input!


Since this is Usenet, and I can't type Unicode here, I used a common
representation of the Unicode character assuming that it would be
totally obvious to anyone what I had done to represent the single
character.  *Sheesh*


>Only THOSE characters would be translated into digraphs.


BTW, I meant digraphs in the C sense, not the meaning you made up.


>Conceptually, it is exactly like digraphs and trigraphs
>revisited but in the OTHER direction: starting with today's digraphs
>!= etc you would get SINGLE characters.
>
>> And what about<<= in ASCII?  You had better not translate that to
>> U+003C, U+2264 in Unicode.
>>
>
>Yes but that would never happen, see above.
>
>>
>>> Again: What I propose is that a small set of Unicode characters,
>>> fixed by ISO is accepted instead of the digraphs in use today.
>>>
>>> This means that !=,&&, ||, and other digraphs are translated into ONE
>>> character, that's all.
>>>
>>>>>
>>>>> Does Java have Big problems because of Unicode? I would bet not!
>>>>
>>>>
>>>> It is the way *all* implementations work - so by definition it
>>>> wouldn't.  My point was that they still avoided the extended
>>>> characters in predefined operators, while allowing programmers to use
>>>> them.
>>>
>>> Well, if ISO would do this, all C implementations would use the same
>>> characters.
>>
>>
>> Except for the C implementations not using Unicode.
>>
>> Just translating C source from ASCII to EBCDIC is more pain than most
>> of us want to go through already.  This would be worse.
>
>
>Why?


Because the character sets are not consistent, and depending on which
EBCDIC code pages you're using you end up having to use trigraphs or
digraphs.  And the collating sequence issues do bite on an awful lot
of real code.


>In environments where this is not desired, we could keep the digraphs.
>A very long transition period of 25 years could be used to slowly
>move to Unicode. You can still program in digraphs and trigraphs TODAY
>if you wish so. This would be the same.


The transition period *is* the problem.  During that time if you have
code that uses the Unicode characters, you need to be able to move
that to/from ASCII implementations.  There would appear to be
translation issues.

[toc] | [prev] | [next] | [standalone]

#7285

Le 30/06/11 09:25, Robert Wessel a écrit :
> On Thu, 30 Jun 2011 09:06:21 +0200, jacob navia<jacob@spamsink.net>
> wrote:
>
>> Le 30/06/11 08:56, Robert Wessel a écrit :
>>> On Thu, 30 Jun 2011 08:16:50 +0200, jacob navia<jacob@spamsink.net>
>>> wrote:
>>>
>>>> Le 30/06/11 08:08, Robert Wessel a écrit :
>>>>>
>>> What happens when you translate:
>>>
>>> (a) if (a \U+2260 b)
>>> (b) strcpy(s, "a\U+2260b")
>>>
>>> from Unicode to ASCII?  With or with or without isoXXX.h defined?  And
>>> then back to Unicode?
>>>
>>
>>
>> You have completely misunderstood. You would never see
>> \U+2260
>> That is 7 chars.
>>
>> You would see ONE Unicode character in the input!
>
>
> Since this is Usenet, and I can't type Unicode here, I used a common
> representation of the Unicode character assuming that it would be
> totally obvious to anyone what I had done to represent the single
> character.  *Sheesh*
>

But then why you would insert a SINGLE Unicode character into
a character string? You could insert \Uwhatever and avoid
any problems.

This is no different than the situation now where
strcpy(a,"??/");

will get translated into something completely different but in the
OTHER direction.

>
>> Only THOSE characters would be translated into digraphs.
>
>
> BTW, I meant digraphs in the C sense, not the meaning you made up.
>
>

The meaning I "made up" is THE SAME as the "C" sense: a di-graph is a
combination of two characters that represent a single character!

>>> Just translating C source from ASCII to EBCDIC is more pain than most
>>> of us want to go through already.  This would be worse.
>>
>>
>> Why?
>
>
> Because the character sets are not consistent, and depending on which
> EBCDIC code pages you're using you end up having to use trigraphs or
> digraphs.  And the collating sequence issues do bite on an awful lot
> of real code.
>

Then, do not use this feature until IBM gets its act together. If you 
use a crippled environment this is NOT a reason that everyone else
is affected. You would go on using your programs as before. When
you import foreign programs you pass them through the translator and
that's all.

>
>> In environments where this is not desired, we could keep the digraphs.
>> A very long transition period of 25 years could be used to slowly
>> move to Unicode. You can still program in digraphs and trigraphs TODAY
>> if you wish so. This would be the same.
>
>
> The transition period *is* the problem.  During that time if you have
> code that uses the Unicode characters, you need to be able to move
> that to/from ASCII implementations.  There would appear to be
> translation issues.

Maybe, but is nothing that can't be done with a general purpose CPU
excuse me. IBM produces computers powerful enough to be able to do that

:-)


P.S. Note that the above trigraph is translated correctly into a single
char

:-) :-)
`

[toc] | [prev] | [next] | [standalone]

#7267

In article <iugem2$np3$1@speranza.aioe.org>, jacob navia <jacob@spamsink.net> 
wrote:

> I am learning the Macintosh environment with the idea of porting the IDE 
> of lcc-win to the mac.
> 
> What is nice in the mac is how easily you can set up a text display
> and integrate images and other data into the text. It supports RTF text
> (as windows too, by the way) and I was again wondering at implementing
> an old idea that I wanted to implement already into wedit some years ago.

I've been doing that for a few years now. I have a macro processor that can 
parse RTF and uses Tcl for its metalanguage. The macro names are C style 
identifiers, but it also can have string mappings like
        <= ｲ <= >       <= ﾂ ! >

It's set up to ignore Palatino font and only include Helvetica. That means I can 
interspersed comments, images, and movies in the text.

-- 
I remember finding out about you,  |A free Thai dyed shirt in every box.
Everyday my mind is all around you,|      I'm whoever you want me to be.
Looking out from my lonely room    | Annoying Usenet one post at a time.
Day after day.                     |   At least I can stay in character.

[toc] | [prev] | [next] | [standalone]

#7270

Le 30/06/11 06:43, China Blue Dolls a écrit :
> In article<iugem2$np3$1@speranza.aioe.org>, jacob navia<jacob@spamsink.net>
> wrote:
>
>> I am learning the Macintosh environment with the idea of porting the IDE
>> of lcc-win to the mac.
>>
>> What is nice in the mac is how easily you can set up a text display
>> and integrate images and other data into the text. It supports RTF text
>> (as windows too, by the way) and I was again wondering at implementing
>> an old idea that I wanted to implement already into wedit some years ago.
>
> I've been doing that for a few years now. I have a macro processor that can
> parse RTF and uses Tcl for its metalanguage. The macro names are C style
> identifiers, but it also can have string mappings like
>          <= ｲ<=>        <= ﾂ !>
>
> It's set up to ignore Palatino font and only include Helvetica. That means I can
> interspersed comments, images, and movies in the text.
>

I think that would be great. If iso would standardize the characters 
used and the operators needed then we could write comments in another
font, etc etc.

[toc] | [prev] | [next] | [standalone]

#7273

In article <iuh14q$pjn$2@speranza.aioe.org>, jacob navia <jacob@spamsink.net> 
wrote:

> Le 30/06/11 06:43, China Blue Dolls a écrit :
> > In article<iugem2$np3$1@speranza.aioe.org>, jacob navia<jacob@spamsink.net>
> > wrote:
> >
> >> I am learning the Macintosh environment with the idea of porting the IDE
> >> of lcc-win to the mac.
> >>
> >> What is nice in the mac is how easily you can set up a text display
> >> and integrate images and other data into the text. It supports RTF text
> >> (as windows too, by the way) and I was again wondering at implementing
> >> an old idea that I wanted to implement already into wedit some years ago.
> >
> > I've been doing that for a few years now. I have a macro processor that can
> > parse RTF and uses Tcl for its metalanguage. The macro names are C style
> > identifiers, but it also can have string mappings like
> >          <= ï1Ž22<=>        <= ï3Ž4’ !>
> >
> > It's set up to ignore Palatino font and only include Helvetica. That means 
> > I can
> > interspersed comments, images, and movies in the text.
> >
> 
> I think that would be great. If iso would standardize the characters 
> used and the operators needed then we could write comments in another
> font, etc etc.

RTF can include any Unicode character, so I just deliver a stream of those.

-- 
I remember finding out about you,  |A free Thai dyed shirt in every box.
Everyday my mind is all around you,|      I'm whoever you want me to be.
Looking out from my lonely room    | Annoying Usenet one post at a time.
Day after day.                     |   At least I can stay in character.

[toc] | [prev] | [next] | [standalone]

#7268

On 06/30/11 12:06 PM, jacob navia wrote:
> I am learning the Macintosh environment with the idea of porting the IDE
> of lcc-win to the mac.
>
> What is nice in the mac is how easily you can set up a text display
> and integrate images and other data into the text. It supports RTF text
> (as windows too, by the way) and I was again wondering at implementing
> an old idea that I wanted to implement already into wedit some years ago.
>
> Actually, when C was conceived there weren't any bit mapped graphics
> or any such hardware that we now consider common place.
>
> The typography of C remained the same, as all other computer languages,
> obsessed with the character sets from 32 to 127 ASCII codes. Then, we
> write != instead of the inequality sign, = instead of the assignment
> arrow, "&&" instead of /\,  "||" instead of \/.
>
> Programs would be clearer if we would use today's hardware to show
> the usual signs, instead of constructs adapted to the teletype
> typewriter of the seventies.
>
> Unicode now offers all possible signs for displaying in our programs,
> and it would be a progress if C would standardize some codes to be
> used isnstead of the usual != and&&, etc.
>
> We have in iso646.h
> #define and&&
> #define and_eq&=
> #define bitand&
> #define bitor   |
> #define compl   ~
>
> We could have in some isoXXX.h
> #define ≠ !=
> #define ⋀ and
> #define ⋁ or
> #define ≤<=
> #define ≥>=

Another way to generate non-portable code!  Not much fun for those of us 
who use command line text processing tools in the C locale!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#7271

Le 30/06/11 06:59, Ian Collins a écrit :
>
> Another way to generate non-portable code!

If isoXXX.h exists then it is 100% portable. You would just need to
#include that file or pass the code through a small preprocessor
and that's all.


> Not much fun for those of us
> who use command line text processing tools in the C locale!
>

It is not very difficult to adapt those tools to accept unicode
anyway... We could use a small subset of Unicode

[toc] | [prev] | [next] | [standalone]

#7272

On 06/30/11 05:23 PM, jacob navia wrote:
> Le 30/06/11 06:59, Ian Collins a écrit :
>>
>> Another way to generate non-portable code!
>
> If isoXXX.h exists then it is 100% portable. You would just need to
> #include that file or pass the code through a small preprocessor
> and that's all.
>
>
>> Not much fun for those of us
>> who use command line text processing tools in the C locale!
>>
>
> It is not very difficult to adapt those tools to accept unicode
> anyway... We could use a small subset of Unicode

Well it is difficult if the tool ere built into the OS!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#7274

In article <972fnnFnfiU2@mid.individual.net>,
 Ian Collins <ian-news@hotmail.com> wrote:

> On 06/30/11 05:23 PM, jacob navia wrote:
> > Le 30/06/11 06:59, Ian Collins a écrit :
> >>
> >> Another way to generate non-portable code!
> >
> > If isoXXX.h exists then it is 100% portable. You would just need to
> > #include that file or pass the code through a small preprocessor
> > and that's all.
> >
> >
> >> Not much fun for those of us
> >> who use command line text processing tools in the C locale!
> >>
> >
> > It is not very difficult to adapt those tools to accept unicode
> > anyway... We could use a small subset of Unicode
> 
> Well it is difficult if the tool ere built into the OS!

Your C compiler is built into the OS?

-- 
I remember finding out about you,  |A free Thai dyed shirt in every box.
Everyday my mind is all around you,|      I'm whoever you want me to be.
Looking out from my lonely room    | Annoying Usenet one post at a time.
Day after day.                     |   At least I can stay in character.

[toc] | [prev] | [next] | [standalone]

#7275

On 06/30/11 05:52 PM, China Blue Dolls wrote:
> In article<972fnnFnfiU2@mid.individual.net>,
>   Ian Collins<ian-news@hotmail.com>  wrote:
>
>> On 06/30/11 05:23 PM, jacob navia wrote:
>>> Le 30/06/11 06:59, Ian Collins a écrit :
>>>>
>>>> Another way to generate non-portable code!
>>>
>>> If isoXXX.h exists then it is 100% portable. You would just need to
>>> #include that file or pass the code through a small preprocessor
>>> and that's all.
>>>
>>>
>>>> Not much fun for those of us
>>>> who use command line text processing tools in the C locale!
>>>>
>>>
>>> It is not very difficult to adapt those tools to accept unicode
>>> anyway... We could use a small subset of Unicode
>>
>> Well it is difficult if the tool ere built into the OS!
>
> Your C compiler is built into the OS?

Read my first post!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#7276

In article <972hb8FfpqU12@mid.individual.net>,
 Ian Collins <ian-news@hotmail.com> wrote:

> On 06/30/11 05:52 PM, China Blue Dolls wrote:
> > In article<972fnnFnfiU2@mid.individual.net>,
> >   Ian Collins<ian-news@hotmail.com>  wrote:
> >
> >> On 06/30/11 05:23 PM, jacob navia wrote:
> >>> Le 30/06/11 06:59, Ian Collins a écrit :
> >>>>
> >>>> Another way to generate non-portable code!
> >>>
> >>> If isoXXX.h exists then it is 100% portable. You would just need to
> >>> #include that file or pass the code through a small preprocessor
> >>> and that's all.
> >>>
> >>>
> >>>> Not much fun for those of us
> >>>> who use command line text processing tools in the C locale!
> >>>>
> >>>
> >>> It is not very difficult to adapt those tools to accept unicode
> >>> anyway... We could use a small subset of Unicode
> >>
> >> Well it is difficult if the tool ere built into the OS!
> >
> > Your C compiler is built into the OS?
> 
> Read my first post!

That argued that if a few people have to work on a crippled system, everyone 
must as well.

-- 
I remember finding out about you,  |A free Thai dyed shirt in every box.
Everyday my mind is all around you,|      I'm whoever you want me to be.
Looking out from my lonely room    | Annoying Usenet one post at a time.
Day after day.                     |   At least I can stay in character.

[toc] | [prev] | [next] | [standalone]

#7289

On 06/30/11 05:58 PM, China Blue Dolls wrote:
> In article<972hb8FfpqU12@mid.individual.net>,
>   Ian Collins<ian-news@hotmail.com>  wrote:
>
>> On 06/30/11 05:52 PM, China Blue Dolls wrote:
>>> In article<972fnnFnfiU2@mid.individual.net>,
>>>    Ian Collins<ian-news@hotmail.com>   wrote:
>>>
>>>> On 06/30/11 05:23 PM, jacob navia wrote:
>>>>> Le 30/06/11 06:59, Ian Collins a écrit :
>>>>>>
>>>>>> Another way to generate non-portable code!
>>>>>
>>>>> If isoXXX.h exists then it is 100% portable. You would just need to
>>>>> #include that file or pass the code through a small preprocessor
>>>>> and that's all.
>>>>>
>>>>>
>>>>>> Not much fun for those of us
>>>>>> who use command line text processing tools in the C locale!
>>>>>>
>>>>>
>>>>> It is not very difficult to adapt those tools to accept unicode
>>>>> anyway... We could use a small subset of Unicode
>>>>
>>>> Well it is difficult if the tool ere built into the OS!
>>>
>>> Your C compiler is built into the OS?
>>
>> Read my first post!
>
> That argued that if a few people have to work on a crippled system, everyone
> must as well.

Read it again, the local is the choice of the user.  I have no reason to 
use a local other than "C".  Why should a programming language dictate 
mu locale?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#7290

Le 30/06/11 11:11, Ian Collins a écrit :
> On 06/30/11 05:58 PM, China Blue Dolls wrote:
>> In article<972hb8FfpqU12@mid.individual.net>,
>> Ian Collins<ian-news@hotmail.com> wrote:
>>
>>> On 06/30/11 05:52 PM, China Blue Dolls wrote:
>>>> In article<972fnnFnfiU2@mid.individual.net>,
>>>> Ian Collins<ian-news@hotmail.com> wrote:
>>>>
>>>>> On 06/30/11 05:23 PM, jacob navia wrote:
>>>>>> Le 30/06/11 06:59, Ian Collins a écrit :
>>> Read my first post!
>>
>> That argued that if a few people have to work on a crippled system,
>> everyone
>> must as well.
>
> Read it again, the local is the choice of the user. I have no reason to
> use a local other than "C". Why should a programming language dictate mu
> locale?
>

Of course not. You can go on using digraphs (!=, ==, etc) and nothing
will change. It is only if you want to import a foreign program that
uses those characters, THEN you would need a simple translator to
convert them into digraphs.

jacob

[toc] | [prev] | [next] | [standalone]

Page 1 of 6  [1] 2 3 4 5 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web