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

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

How would you design C's replacement?

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

Contents

  How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-04-29 17:17 +0100
    Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-04-29 18:44 +0100
      Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-04-29 22:20 +0100
      Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-29 15:32 -0700
        Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-04-30 00:37 +0100
          Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-29 18:30 -0700
            Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-04-30 13:43 +1200
            Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-04-29 23:45 -0400
              Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-29 22:12 -0700
            Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-04-30 13:06 +0100
              Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-30 08:36 -0700
        Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-01 00:17 -0700
          Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-05-01 01:05 -0700
          Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-01 07:36 -0400
          Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 13:39 +0100
          Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-01 23:06 +0100
            Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-01 18:11 -0700
      Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-04-30 21:36 +0100
        Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-01 00:24 +0100
          Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-04-30 17:08 -0700
            Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-30 19:15 -0700
          Re: How would you design C's replacement? Kaz Kylheku <kaz@kylheku.com> - 2012-05-01 03:06 +0000
            Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-30 21:18 -0700
            Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-01 12:14 +0100
          Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-01 16:53 +1200
            Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-30 22:17 -0700
              Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-01 17:24 +1200
                Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-30 22:44 -0700
            Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-01 12:18 +0100
    Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-04-29 11:10 -0700
    Re: How would you design C's replacement? Kaz Kylheku <kaz@kylheku.com> - 2012-04-29 18:27 +0000
      Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-04-30 13:54 +0100
    Re: How would you design C's replacement? "io_x" <a@b.c.invalid> - 2012-04-29 22:07 +0200
      Re: How would you design C's replacement? "io_x" <a@b.c.invalid> - 2012-04-29 22:23 +0200
        Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-04-30 00:41 -0700
          Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-04-30 07:30 -0400
            Re: How would you design C's replacement? "io_x" <a@b.c.invalid> - 2012-04-30 16:29 +0200
      Re: How would you design C's replacement? "io_x" <a@b.c.invalid> - 2012-04-29 22:26 +0200
      Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-04-29 21:27 +0100
        Re: How would you design C's replacement? "io_x" <a@b.c.invalid> - 2012-04-30 08:49 +0200
      Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-04-30 00:42 -0700
        Re: How would you design C's replacement? "io_x" <a@b.c.invalid> - 2012-04-30 19:40 +0200
          Re: How would you design C's replacement? "io_x" <a@b.c.invalid> - 2012-05-25 10:38 +0200
            Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-27 10:22 +0100
    Re: How would you design C's replacement? FireXware <none@none.invalid> - 2012-04-29 14:29 -0600
      Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-29 17:18 -0700
        Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 10:56 +0100
          Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-05-01 08:04 -0700
    Re: How would you design C's replacement? Mark Storkamp <mstorkamp@yahoo.com> - 2012-04-29 16:37 -0500
    Re: How would you design C's replacement? Kaz Kylheku <kaz@kylheku.com> - 2012-04-29 22:43 +0000
    Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-04-30 06:41 +0200
    Re: How would you design C's replacement? Robert Wessel <robertwessel2@yahoo.com> - 2012-04-30 01:33 -0500
      Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-04-30 07:26 -0400
        Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-04-30 13:30 +0200
      Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-01 11:44 +1200
        Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-30 22:25 -0700
          Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-01 18:23 +1200
            Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-05-01 06:18 -0700
        Re: How would you design C's replacement? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-05-02 20:25 +0000
        Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-05-03 01:10 -0700
          Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-03 20:34 +1200
    Re: How would you design C's replacement? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-04-30 01:01 -0700
      Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-04-30 10:08 +0200
        Re: How would you design C's replacement? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-04-30 08:22 -0700
          Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-04-30 12:09 -0400
            Re: How would you design C's replacement? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-05-01 00:23 -0700
              Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-05-03 01:40 -0700
            Re: How would you design C's replacement? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-05-02 20:15 +0000
          Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-04-30 17:17 +0100
            Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-04-30 12:44 -0400
              Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-04-30 16:28 -0700
                Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-04-30 23:50 -0400
            Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-30 13:52 -0700
          Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 13:44 +0100
            Re: How would you design C's replacement? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-05-01 08:34 -0700
      Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-04-30 21:22 +0100
      Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-05-03 01:14 -0700
        Re: How would you design C's replacement? Kenneth Brody <kenbrody@spamcop.net> - 2012-05-03 12:35 -0400
        Re: How would you design C's replacement? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-05-04 00:44 -0700
    Re: How would you design C's replacement? Leo Havmøller <rtxleh@nospam.nospam> - 2012-04-30 13:39 +0200
      Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 11:15 +0100
        Re: How would you design C's replacement? tom st denis <tom@iahu.ca> - 2012-05-01 06:15 -0700
    Re: How would you design C's replacement? Michael Angelo Ravera <maravera@prodigy.net> - 2012-04-30 12:11 -0700
      Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-04-30 21:29 +0100
        Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-04-30 16:43 -0700
          Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 10:31 +0100
            Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-01 03:11 -0700
              Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 12:32 +0100
                Re: How would you design C's replacement? tom st denis <tom@iahu.ca> - 2012-05-01 06:06 -0700
                  Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 14:11 +0100
                    Re: How would you design C's replacement? tom st denis <tom@iahu.ca> - 2012-05-01 06:29 -0700
                    Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-01 13:24 -0700
                      Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-01 16:22 -0700
                Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-05-01 06:44 -0700
                Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-01 13:22 -0700
                  Re: How would you design C's replacement? jgk@panix.com (Joe keane) - 2012-05-02 21:33 +0000
                    Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-02 17:59 -0700
                    Re: How would you design C's replacement? Robert Wessel <robertwessel2@yahoo.com> - 2012-05-02 22:16 -0500
                  Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-03 10:13 +0100
                    Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-03 13:05 -0700
            Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-01 23:36 +0100
              Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-05-03 02:40 -0700
          Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-05-02 01:37 -0700
            Re: How would you design C's replacement? "io_x" <a@b.c.invalid> - 2012-05-02 16:41 +0200
              Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-05-03 02:54 -0700
              Re: How would you design C's replacement? Kenneth Brody <kenbrody@spamcop.net> - 2012-05-03 12:18 -0400
        Re: How would you design C's replacement? 88888 Dihedral <dihedral88888@googlemail.com> - 2012-05-02 20:27 -0700
      Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-05-02 01:22 -0700
        Re: How would you design C's replacement? Michael Angelo Ravera <maravera@prodigy.net> - 2012-05-04 00:41 -0700
          Re: How would you design C's replacement? Ike Naar <ike@iceland.freeshell.org> - 2012-05-04 08:41 +0000
            Re: How would you design C's replacement? Michael Angelo Ravera <maravera@prodigy.net> - 2012-05-07 01:11 -0700
              Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-07 07:18 -0400
                Re: How would you design C's replacement? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-05-07 05:41 -0700
                  Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-07 09:24 -0400
                  Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-05-07 09:31 -0700
                    Re: How would you design C's replacement? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-05-10 15:37 -0700
          Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-05-04 08:16 -0700
          Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-05-04 09:49 -0700
    Re: How would you design C's replacement? lawrence.jones@siemens.com - 2012-04-30 14:25 -0400
      Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-04-30 22:19 +0200
        Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-04-30 14:04 -0700
          Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-05-01 00:33 +0200
            Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-04-30 15:43 -0700
              Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 10:17 +0100
          Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 10:15 +0100
            Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-05-01 07:12 -0700
          Re: How would you design C's replacement? lawrence.jones@siemens.com - 2012-05-01 10:41 -0400
          Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-01 17:39 +0100
            Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-01 12:46 -0400
        Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-04-30 21:41 -0700
        Re: How would you design C's replacement? gwowen <gwowen@gmail.com> - 2012-05-01 00:22 -0700
        Re: How would you design C's replacement? Kenneth Brody <kenbrody@spamcop.net> - 2012-05-01 15:53 -0400
        Re: How would you design C's replacement? Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2012-05-09 21:06 +0000
          Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-05-10 00:32 +0200
            Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-10 10:35 +1200
          Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-09 16:18 -0700
            Re: How would you design C's replacement? gazelle@shell.xmission.com (Kenny McCormack) - 2012-05-10 02:45 +0000
              Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-10 16:18 +0100
                Re: How would you design C's replacement? Robert Wessel <robertwessel2@yahoo.com> - 2012-05-11 03:21 -0500
                  Re: How would you design C's replacement? gazelle@shell.xmission.com (Kenny McCormack) - 2012-05-11 15:55 +0000
                    Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-13 17:39 +0100
                      Re: How would you design C's replacement? 88888 Dihedral <dihedral88888@googlemail.com> - 2012-05-14 00:08 -0700
                    Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-13 21:24 +0100
                      Re: How would you design C's replacement? Marco <prenom_nomus@yahoo.com> - 2012-05-20 06:50 -0700
              Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-05-10 00:08 -0700
              Re: How would you design C's replacement? gwowen <gwowen@gmail.com> - 2012-05-10 04:04 -0700
            Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-10 10:38 -0700
              Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-05-10 11:15 -0700
                Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-11 08:36 -0700
                  Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-05-11 17:49 +0200
                    Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-05-11 09:34 -0700
                    Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-11 09:41 -0700
                      Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-05-11 19:42 +0200
                        Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-05-11 10:50 -0700
                          Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-05-11 20:16 +0200
                            Trigraphs (was Re: How would you design C's replacement?) Kenneth Brody <kenbrody@spamcop.net> - 2012-05-14 11:49 -0400
                              Re: Trigraphs (was Re: How would you design C's replacement?) James Kuyper <jameskuyper@verizon.net> - 2012-05-14 12:21 -0400
                                Re: Trigraphs Ben Pfaff <blp@cs.stanford.edu> - 2012-05-14 09:50 -0700
                                  Re: Trigraphs James Kuyper <jameskuyper@verizon.net> - 2012-05-14 13:05 -0400
                                    Re: Trigraphs Ben Pfaff <blp@cs.stanford.edu> - 2012-05-14 10:24 -0700
                                      Re: Trigraphs Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-14 11:56 -0700
                                        Re: Trigraphs jacob navia <jacob@spamsink.net> - 2012-05-14 21:00 +0200
                                          Re: Trigraphs Robert Wessel <robertwessel2@yahoo.com> - 2012-05-14 16:37 -0500
                                            Re: Trigraphs James Kuyper <jameskuyper@verizon.net> - 2012-05-14 17:58 -0400
                                              Re: Trigraphs Keith Thompson <kst-u@mib.org> - 2012-05-14 21:05 -0700
                                                Re: Trigraphs Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-17 13:19 -0700
                                          Re: Trigraphs Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-17 13:05 -0700
                                          Re: Trigraphs jgk@panix.com (Joe keane) - 2012-05-17 22:04 +0000
                                        Re: Trigraphs Walter Banks <walter@bytecraft.com> - 2012-05-14 16:22 -0400
                                          Re: Trigraphs "BartC" <bc@freeuk.com> - 2012-05-14 22:05 +0100
                                            Re: Trigraphs Walter Banks <walter@bytecraft.com> - 2012-05-14 22:31 -0400
                                              Re: Trigraphs Ben Pfaff <blp@cs.stanford.edu> - 2012-05-14 21:17 -0700
                                          Re: Trigraphs Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-17 13:42 -0700
                                    Re: Trigraphs Keith Thompson <kst-u@mib.org> - 2012-05-14 13:33 -0700
                                      Re: Trigraphs Jens Gustedt <jens.gustedt@loria.fr> - 2012-05-14 23:02 +0200
                                        Re: Trigraphs James Kuyper <jameskuyper@verizon.net> - 2012-05-14 17:35 -0400
                        Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-11 18:49 -0700
                      Re: How would you design C's replacement? Gareth Owen <gwowen@gmail.com> - 2012-05-11 18:49 +0100
                        Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-05-11 20:14 +0200
                          Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-11 18:56 -0700
              Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-10 11:31 -0700
                Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-11 08:38 -0700
                  Re: How would you design C's replacement? Ben Pfaff <blp@cs.stanford.edu> - 2012-05-11 09:36 -0700
                    Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-11 19:12 -0700
                      Re: How would you design C's replacement? Kenneth Brody <kenbrody@spamcop.net> - 2012-05-14 11:56 -0400
                        Re: How would you design C's replacement? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-14 11:34 -0700
        Re: How would you design C's replacement? jgk@panix.com (Joe keane) - 2012-05-10 20:05 +0000
          Re: How would you design C's replacement? "J. J. Farrell" <jjf@bcs.org.uk> - 2012-05-11 06:19 +0100
      Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 10:33 +0100
    Re: How would you design C's replacement? jgk@panix.com (Joe keane) - 2012-04-30 22:38 +0000
    Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-01 17:43 +1200
      Re: How would you design C's replacement? Jens Gustedt <jens.gustedt@loria.fr> - 2012-05-01 09:39 +0200
        Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-01 20:21 +1200
          Re: How would you design C's replacement? Jens Gustedt <jens.gustedt@loria.fr> - 2012-05-01 10:39 +0200
            Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-01 20:47 +1200
              Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-01 08:10 -0400
              Re: How would you design C's replacement? Jens Gustedt <jens.gustedt@loria.fr> - 2012-05-01 14:37 +0200
            Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-01 08:17 -0400
        Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-01 07:48 -0400
          Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-01 13:32 -0700
            Re: How would you design C's replacement? Jens Gustedt <jens.gustedt@loria.fr> - 2012-05-01 23:07 +0200
              Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-02 18:02 +1200
                Re: How would you design C's replacement? Jens Gustedt <jens.gustedt@loria.fr> - 2012-05-02 14:40 +0200
                  Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-02 10:35 -0400
                    Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-05-02 16:51 +0200
                      Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-05-02 11:44 -0700
                        Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-02 17:23 -0700
                        Re: How would you design C's replacement? jacob navia <jacob@spamsink.net> - 2012-05-03 12:14 +0200
                          Re: How would you design C's replacement? Jens Gustedt <jens.gustedt@loria.fr> - 2012-05-03 13:38 +0200
                      Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-03 07:28 +1200
                        Re: How would you design C's replacement? ImpalerCore <jadill33@gmail.com> - 2012-05-02 13:28 -0700
                          Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-03 18:44 +1200
                      Re: How would you design C's replacement? gwowen <gwowen@gmail.com> - 2012-05-03 00:56 -0700
                  Re: How would you design C's replacement? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-02 16:04 +0100
            Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-01 17:14 -0400
              Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-01 16:10 -0700
              Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-02 17:52 +1200
                Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-02 02:37 -0700
                Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-02 07:29 -0400
    Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-01 12:19 +0100
    Re: How would you design C's replacement? Lanarcam <lanarcam1@yahoo.fr> - 2012-05-01 18:02 +0200
      Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-01 13:43 -0700
        Re: How would you design C's replacement? Lanarcam <lanarcam1@yahoo.fr> - 2012-05-01 22:52 +0200
          Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-01 16:12 -0700
            Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-05-01 20:59 -0700
            Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-05-02 02:09 -0700
            Re: How would you design C's replacement? Kenneth Brody <kenbrody@spamcop.net> - 2012-05-03 12:08 -0400
              Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-05-03 16:05 -0700
      Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-05-02 02:04 -0700
        Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-02 10:36 +0100
          Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-02 07:36 -0400
            Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-02 16:21 +0100
              Re: How would you design C's replacement? Kenneth Brody <kenbrody@spamcop.net> - 2012-05-03 12:26 -0400
                Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-05-03 16:08 -0700
          Re: How would you design C's replacement? Rui Maciel <rui.maciel@gmail.com> - 2012-05-02 16:16 +0100
            Re: How would you design C's replacement? Dr Nick <3-nospam@temporary-address.org.uk> - 2012-05-02 19:46 +0100
            Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-05-02 12:12 -0700
              Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-02 20:26 +0100
                Re: How would you design C's replacement? BGB <cr88192@hotmail.com> - 2012-05-02 12:59 -0700
                Re: How would you design C's replacement? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-05-02 14:32 -0700
                Re: How would you design C's replacement? Keith Thompson <kst-u@mib.org> - 2012-05-02 17:09 -0700
                Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-03 18:45 +1200
                  Re: How would you design C's replacement? James Kuyper <jameskuyper@verizon.net> - 2012-05-03 08:13 -0400
                    Re: How would you design C's replacement? Ian Collins <ian-news@hotmail.com> - 2012-05-04 07:18 +1200
              Re: How would you design C's replacement? David Thompson <dave.thompson2@verizon.net> - 2012-05-13 00:15 -0400
            Re: How would you design C's replacement? Kenneth Brody <kenbrody@spamcop.net> - 2012-05-03 12:22 -0400
          Re: How would you design C's replacement? nick_keighley_nospam@hotmail.com - 2012-05-03 03:09 -0700
            Re: How would you design C's replacement? 88888 Dihedral <dihedral88888@googlemail.com> - 2012-05-03 03:55 -0700
            Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-03 12:45 +0100
            Re: How would you design C's replacement? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-03 13:15 +0100
              Re: How would you design C's replacement? "BartC" <bc@freeuk.com> - 2012-05-03 13:41 +0100
                Re: How would you design C's replacement? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-03 17:51 +0100
            Re: How would you design C's replacement? Kenneth Brody <kenbrody@spamcop.net> - 2012-05-03 12:37 -0400

Page 2 of 13 — ← Prev page 1 [2] 3 4 … 13  Next page →

#20126

On 4/30/2012 5:08 PM, Keith Thompson wrote:
> "BartC"<bc@freeuk.com>  writes:
> [...]
>> OK, let's start with something obvious: C's type-declaration syntax. I find
>> its inside-out convoluted form completely impossible.
>>
>> I've often had to resort to CDECL to sort out complex declarations. There
>> must be something seriously wrong in a language if I have to use external
>> tools to help understand it!  And every time I've discussed this in this
>> group, I get step-by-step lessons on how to decode, or construct, such a
>> declaration! Nothing about fixing the language.
>
> Probably because this newsgroup isn't really about "fixing the
> language".
>

agreed.

I personally see little problem with the syntax in-general, except in a 
few cases.


>> Outside of C, I use a type-declaration syntax that reads pretty much like
>> the English output of CDECL. And I once proposed, in clc, such a
>> left-to-right syntax for C that could just about co-exist with the old-style
>> type syntax.
>
> If you wanted to add a new declaration syntax to C, it would have to
> *completely* coexist with the existing syntax.  Breaking existing code
> is not an option.  (Yes, each new C standard has broken *some* existing
> code, at least theoretically, but breaking every declaration more
> complex than "int i;" would not be acceptable.)
>
> And while I agree that a better syntax for a hypothetical new language
> (the "C's replacement" we're discussing in this thread) would be great,
> I'm not sure that a C-like language supporting both the existing syntax
> and a new syntax would be better than one that just supports the
> existing syntax.
>

my own language (BGBScript) has an issue similar to this.


given its ECMAScript heritage, it has ECMAScript-style declarations.
given other reasons (mostly related to inter-language copy/paste), it 
also has a more Java/C# style declaration syntax.

it is kind of annoying, as there is an issue as to which syntax is more 
canonical.

I am mostly leaning more towards the ES-style being more canonical, more 
because the language is technically an ES variant (it is largely 
ECMA-262 conformant), and so it makes more sense if the language uses as 
its canonical syntax, the one defined in the standard on which it is based.


example:
var x;
var i:int;
var a:int[];
var pv:*void;
vs:
variant x; //(1)
int i;
int[] a;
*void pv; //(2)

1: this syntax is longer and not strictly equivalent to "var x;", 
however "var x;" is technically the other syntax given that var is a 
declaration keyword. "variant x" is technically equivalent to "var 
x:variant;". there is currently little functional difference though.

note that, given how the declaration parser works, it is also 
technically possible to create double-typed variables, as in:
"int x:long, y:double;"

however, these currently have little practical use, and should be 
considered an error (as-is, the later types will override the base type).

function declaration syntax is also partly redundant:
function foo(x:int):void { ... }
vs:
void foo(int x) { ... }


as-is, closures can only be declared with an ES-like form (sort of), 
given that there are syntax problems otherwise.

function(x) { ... }
function(i:int):void { ... }

however:
function(int i) { ... }
function(int i):void { ... }
will probably work...

things like getters/setters, ... also have redundant syntax.

function get x():int { ... }
vs:
int get x() { ... }

...


2: "*type" was used instead of "type*" in my language due to there being 
several cases in which the later would be syntactically ambiguous. 
although declaring pointers this way may look strange, as-is it is a 
fairly trivial change, and doesn't particularly hinder converting C code 
to BGBScript, or at least not nearly as much as the differences in the 
cast syntax.


a recent set of (fairly fundamental) changes in my interpreter has made 
many of these types more canonical, as now declaring a variable as "int" 
will actually store the variable as a 32-bit integer internally, rather 
than, say, as a fixnum.

these changes have introduced a lot of bugs, so it is still an ongoing 
transition.


I was also recently thinking and considering if my interpreter would be 
fast enough to allow porting Quake to my Script VM. if some recent 
benchmarks are representative, my interpreter is performing comparably 
to the sorts of hardware Quake 1 and 2 were developed for, and so should 
be sufficiently fast to run these games (even without a JIT).

granted, I would likely need a C front-end for this VM (sadly, doesn't 
currently exist, 3), as it would probably be too much effort to port the 
entire Quake 1 or Quake 2 engine to BGBScript.

not sure yet if I will actually attempt a thing, since as-is, this would 
still be a fairly big project given the present state of the VM.


3: my existing C compiler targeted a different back-end, which is no 
longer in operation. I would either need to modify this front-end to 
target the current Script VM, or very possibly create a new C front-end, 
or possibly a combination (keeping the existing parser, but write a new 
AST->bytecode stage).


> But something that might be interesting, not as a language change but as
> a development tool, would be integrating something like cdecl into the
> build process.  You could write code in a C-like dialect, with
> declarations written in your new syntax, and your build tool would
> automatically generate syntactically correct C.  Another tool could
> translate C declarations into your syntax.  It would let you use your
> preferred syntax while still being able to share C code with others who
> don't have your tools.
>

it is possible...


>> And while we're dealing with the type-system, let's standardise on an
>> unsigned char type, and have separate signed/unsigned int types of the same
>> width as char (ie. bytes).  There's loads more tidying of the type system
>> that can be done, but just one more thing for now: I'd also get rid of
>> struct name-spaces; they're just a source of confusion.
>
> I presume you mean requiring plain "char" to be unsigned (we already
> have "unsigned char").  I tend to agree; permitting plain char to be
> signed causes a lot of conceptual problems.  I wonder what kind of
> performance problems it might introduce, though; char expressions are
> frequently promoted to int, and that promotion might be more expensive
> on some systems if plain char is signed.  (I presume that's why so many
> compilers make plain char signed, when making it unsigned would be
> perfectly legal.)
>

in my language, I split them up, so these types are more like:
byte: 8-bit unsigned byte;
sbyte: 8-bit signed byte;
short: 16-bit signed short;
ushort: 16-bit unsigned short;
char8: 8-bit unsigned char;
char/char16: 16-bit unsigned char.

char is not strictly equivalent to ushort, as they will have slightly 
different semantics.

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

#20127

On 2012-04-30, BartC <bc@freeuk.com> wrote:
> "Rui Maciel" <rui.maciel@gmail.com> wrote in message
> news:jnmt3p$jro$1@speranza.aioe.org...
>> BartC wrote:
>>
>>> Perhaps the problems and shortcomings should be summarised first. Then
>>> they need to be agreed to be shortcomings;
>>
>> These tend to be more subjective than objective.  I believe it's more
>> interesting if we get people to point out what they perceive to be a
>> problem, why it's a problem and how they would fix it.
>
> OK, let's start with something obvious: C's type-declaration syntax. I find
> its inside-out convoluted form completely impossible.

The problem with any major changes to C's type declaration syntax is that
they break "declaration follows use".

A declarator like (*p[3])(double) gives us a p which can actually be used by
means of the syntax (*p[0])(3.0).

If you change how it is declared, but don't make a parallel change to the
expression syntax then you still have (*p[0])(3.0) /and/ the new syntax which
is inconsistent with this.

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

#20130

On 4/30/2012 8:06 PM, Kaz Kylheku wrote:
> On 2012-04-30, BartC<bc@freeuk.com>  wrote:
>> "Rui Maciel"<rui.maciel@gmail.com>  wrote in message
>> news:jnmt3p$jro$1@speranza.aioe.org...
>>> BartC wrote:
>>>
>>>> Perhaps the problems and shortcomings should be summarised first. Then
>>>> they need to be agreed to be shortcomings;
>>>
>>> These tend to be more subjective than objective.  I believe it's more
>>> interesting if we get people to point out what they perceive to be a
>>> problem, why it's a problem and how they would fix it.
>>
>> OK, let's start with something obvious: C's type-declaration syntax. I find
>> its inside-out convoluted form completely impossible.
>
> The problem with any major changes to C's type declaration syntax is that
> they break "declaration follows use".
>
> A declarator like (*p[3])(double) gives us a p which can actually be used by
> means of the syntax (*p[0])(3.0).
>
> If you change how it is declared, but don't make a parallel change to the
> expression syntax then you still have (*p[0])(3.0) /and/ the new syntax which
> is inconsistent with this.


to be fair though, something like:
void (*fooptr)(double x);

is usually called using something like:
fooptr(3.0);


and so some change to the function pointer syntax could still be 
justifiable, say if people would instead have to write:
typedef void fooptr_t(double x);
fooptr_t *fooptr;

or, OTOH, use some sort of funky QuakeC-style syntax:
void(double x) *fooptr;


this later option would change a declaration from something like:
void (*foo())(int x)
	{ ... }
into something like:
void(int x) *foo()
	{ ... }


or such...

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

#20154

"Kaz Kylheku" <kaz@kylheku.com> wrote in message
news:20120430194830.577@kylheku.com...
> On 2012-04-30, BartC <bc@freeuk.com> wrote:
>> "Rui Maciel" <rui.maciel@gmail.com> wrote in message
>> news:jnmt3p$jro$1@speranza.aioe.org...
>>> BartC wrote:
>>>
>>>> Perhaps the problems and shortcomings should be summarised first. Then
>>>> they need to be agreed to be shortcomings;
>>>
>>> These tend to be more subjective than objective.  I believe it's more
>>> interesting if we get people to point out what they perceive to be a
>>> problem, why it's a problem and how they would fix it.
>>
>> OK, let's start with something obvious: C's type-declaration syntax. I
>> find
>> its inside-out convoluted form completely impossible.
>
> The problem with any major changes to C's type declaration syntax is that
> they break "declaration follows use".

So what? That was a crazy idea that never really worked.

A lot of people *do* have trouble with C's type-declarations; they *do* need
to employ an algorithm to understand a complex one; many have to resort to
layers of typedefs to make them simpler to read and write; and some decided
to write the  Cdecl utility to help read and write them! To me, that
suggests that there is an issue.

And declaration-follows-use breaks down in many cases; inside casts for
example, where the absence of a name from the type-spec makes it even harder
to know where to start; you just end up with a mess of parentheses and
asterisks.

How does it work here:

int a; a

It seems that any type-spec is broken down into two parts: the resultant
type (eg. 'int') and anything else (ie. mix of pointer, array, function
signtature). It is this 'anything else' that needs to be literally wrapped
around individual names, resulting in this confusing syntax:

int* a, b, c;

Where you do want all names with the same type, you have to duplicate the
type-spec:

 int *a[10], *b[10], *c[10];

or start creating typedefs. (BTW declaration-follows-use also breaks down
when you try and write *a[10]...)

> A declarator like (*p[3])(double) gives us a p which can actually be used
> by
> means of the syntax (*p[0])(3.0).

(Your example gives an error in Cdecl unless something like 'int' is added
in front. See, I didn't even know that from looking!)

> If you change how it is declared, but don't make a parallel change to the
> expression syntax then you still have (*p[0])(3.0) /and/ the new syntax
> which
> is inconsistent with this.

Part of the problem is that C's dereference syntax is also back-to-front:
*p[0] instead of p[0]*.

But, if you have to design a new language that was fully-typed like C, would
you still use this type syntax or not?

(I would write your example, in another language, as follows (where 'real'
means double, and ^ means dereference):

[3]ref function(real)int p

p[1]^(3.0)

This was written directly using Cdecl's output as a guide: "declare p as
array 3 of pointer to function (double) returning int". The only difference
is I put "p" at the end rather than at the start.)

-- 
Bartc 

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

#20132

On 05/ 1/12 11:24 AM, BartC wrote:
>
>
> "Rui Maciel"<rui.maciel@gmail.com>  wrote in message
> news:jnmt3p$jro$1@speranza.aioe.org...
>> BartC wrote:
>>
>>> Perhaps the problems and shortcomings should be summarised first. Then
>>> they need to be agreed to be shortcomings;
>>
>> These tend to be more subjective than objective.  I believe it's more
>> interesting if we get people to point out what they perceive to be a
>> problem, why it's a problem and how they would fix it.
>
> OK, let's start with something obvious: C's type-declaration syntax. I find
> its inside-out convoluted form completely impossible.
>
> I've often had to resort to CDECL to sort out complex declarations. There
> must be something seriously wrong in a language if I have to use external
> tools to help understand it!  And every time I've discussed this in this
> group, I get step-by-step lessons on how to decode, or construct, such a
> declaration! Nothing about fixing the language.

More often than not there's something wrong with the programmer who 
conjurers up such a convoluted declaration!  Seriously, 99.9% of the 
time complex type declarations are unnecessary.

One simplification that would help not break (much!) code would be to 
adopt C++'s reuse of "auto".  It would be very handy for those cases 
where the compiler knows the type an expression and the programmer 
doesn't really care.  I have my own C++ Auto object type I use with my 
JSON library and I've found it extremely useful in such cases.

-- 
Ian Collins

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

#20133

On 4/30/2012 9:53 PM, Ian Collins wrote:
> On 05/ 1/12 11:24 AM, BartC wrote:
>>
>>
>> "Rui Maciel"<rui.maciel@gmail.com> wrote in message
>> news:jnmt3p$jro$1@speranza.aioe.org...
>>> BartC wrote:
>>>
>>>> Perhaps the problems and shortcomings should be summarised first. Then
>>>> they need to be agreed to be shortcomings;
>>>
>>> These tend to be more subjective than objective. I believe it's more
>>> interesting if we get people to point out what they perceive to be a
>>> problem, why it's a problem and how they would fix it.
>>
>> OK, let's start with something obvious: C's type-declaration syntax. I
>> find
>> its inside-out convoluted form completely impossible.
>>
>> I've often had to resort to CDECL to sort out complex declarations. There
>> must be something seriously wrong in a language if I have to use external
>> tools to help understand it! And every time I've discussed this in this
>> group, I get step-by-step lessons on how to decode, or construct, such a
>> declaration! Nothing about fixing the language.
>
> More often than not there's something wrong with the programmer who
> conjurers up such a convoluted declaration! Seriously, 99.9% of the time
> complex type declarations are unnecessary.
>
> One simplification that would help not break (much!) code would be to
> adopt C++'s reuse of "auto". It would be very handy for those cases
> where the compiler knows the type an expression and the programmer
> doesn't really care. I have my own C++ Auto object type I use with my
> JSON library and I've found it extremely useful in such cases.
>

yeah, auto would be nice...


placing restrictions on declaration keyword orderings is also possible 
and not likely to break all that much code (probably 95% would still 
work), and could allow faster parsers (as well as allow eliminating 
context dependency), such as by allowing switching to a C#-style parsing 
strategy.

there are drawbacks though, namely that not all code or headers would 
parse correctly, meaning it would likely involve a compiler option or 
similar to enable it.

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

#20134

On 05/ 1/12 05:17 PM, BGB wrote:
> On 4/30/2012 9:53 PM, Ian Collins wrote:
>> On 05/ 1/12 11:24 AM, BartC wrote:
>>>
>>>
>>> "Rui Maciel"<rui.maciel@gmail.com>  wrote in message
>>> news:jnmt3p$jro$1@speranza.aioe.org...
>>>> BartC wrote:
>>>>
>>>>> Perhaps the problems and shortcomings should be summarised first. Then
>>>>> they need to be agreed to be shortcomings;
>>>>
>>>> These tend to be more subjective than objective. I believe it's more
>>>> interesting if we get people to point out what they perceive to be a
>>>> problem, why it's a problem and how they would fix it.
>>>
>>> OK, let's start with something obvious: C's type-declaration syntax. I
>>> find
>>> its inside-out convoluted form completely impossible.
>>>
>>> I've often had to resort to CDECL to sort out complex declarations. There
>>> must be something seriously wrong in a language if I have to use external
>>> tools to help understand it! And every time I've discussed this in this
>>> group, I get step-by-step lessons on how to decode, or construct, such a
>>> declaration! Nothing about fixing the language.
>>
>> More often than not there's something wrong with the programmer who
>> conjurers up such a convoluted declaration! Seriously, 99.9% of the time
>> complex type declarations are unnecessary.
>>
>> One simplification that would help not break (much!) code would be to
>> adopt C++'s reuse of "auto". It would be very handy for those cases
>> where the compiler knows the type an expression and the programmer
>> doesn't really care. I have my own C++ Auto object type I use with my
>> JSON library and I've found it extremely useful in such cases.
>>
>
> yeah, auto would be nice...
>
>
> placing restrictions on declaration keyword orderings is also possible
> and not likely to break all that much code (probably 95% would still
> work), and could allow faster parsers (as well as allow eliminating
> context dependency), such as by allowing switching to a C#-style parsing
> strategy.
>
> there are drawbacks though, namely that not all code or headers would
> parse correctly, meaning it would likely involve a compiler option or
> similar to enable it.

Unlike incorporating C++'s "auto" which could be seamless.

-- 
Ian Collins

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

#20137

On 4/30/2012 10:24 PM, Ian Collins wrote:
> On 05/ 1/12 05:17 PM, BGB wrote:
>> On 4/30/2012 9:53 PM, Ian Collins wrote:
>>> On 05/ 1/12 11:24 AM, BartC wrote:
>>>>
>>>>
>>>> "Rui Maciel"<rui.maciel@gmail.com> wrote in message
>>>> news:jnmt3p$jro$1@speranza.aioe.org...
>>>>> BartC wrote:
>>>>>
>>>>>> Perhaps the problems and shortcomings should be summarised first.
>>>>>> Then
>>>>>> they need to be agreed to be shortcomings;
>>>>>
>>>>> These tend to be more subjective than objective. I believe it's more
>>>>> interesting if we get people to point out what they perceive to be a
>>>>> problem, why it's a problem and how they would fix it.
>>>>
>>>> OK, let's start with something obvious: C's type-declaration syntax. I
>>>> find
>>>> its inside-out convoluted form completely impossible.
>>>>
>>>> I've often had to resort to CDECL to sort out complex declarations.
>>>> There
>>>> must be something seriously wrong in a language if I have to use
>>>> external
>>>> tools to help understand it! And every time I've discussed this in this
>>>> group, I get step-by-step lessons on how to decode, or construct,
>>>> such a
>>>> declaration! Nothing about fixing the language.
>>>
>>> More often than not there's something wrong with the programmer who
>>> conjurers up such a convoluted declaration! Seriously, 99.9% of the time
>>> complex type declarations are unnecessary.
>>>
>>> One simplification that would help not break (much!) code would be to
>>> adopt C++'s reuse of "auto". It would be very handy for those cases
>>> where the compiler knows the type an expression and the programmer
>>> doesn't really care. I have my own C++ Auto object type I use with my
>>> JSON library and I've found it extremely useful in such cases.
>>>
>>
>> yeah, auto would be nice...
>>
>>
>> placing restrictions on declaration keyword orderings is also possible
>> and not likely to break all that much code (probably 95% would still
>> work), and could allow faster parsers (as well as allow eliminating
>> context dependency), such as by allowing switching to a C#-style parsing
>> strategy.
>>
>> there are drawbacks though, namely that not all code or headers would
>> parse correctly, meaning it would likely involve a compiler option or
>> similar to enable it.
>
> Unlike incorporating C++'s "auto" which could be seamless.
>

pretty much, but they do different things.


auto allows simpler-looking declarations.

alternate declaration parsing allows for a potentially somewhat faster 
parser and compiler (combined with other tricks). I am not promoting 
here making "obvious syntax changes", rather using a different parsing 
strategy (with the restrictions being mostly a side cost).

like, wouldn't it be nice if, say, a person could compile about 100 kloc 
of code in, say, 250ms or 500ms or so?... (vs maybe 10-20 seconds, most 
due to endlessly re-parsing things like "windows.h" and similar...).

granted, it may be all a bit domain-specific, hence probably why it 
would be a command-line option to enable it.


so, either way...

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

#20155

"Ian Collins" <ian-news@hotmail.com> wrote in message
news:a098icFkabU5@mid.individual.net...
> On 05/ 1/12 11:24 AM, BartC wrote:

>> I've often had to resort to CDECL to sort out complex declarations.

> More often than not there's something wrong with the programmer who
> conjurers up such a convoluted declaration!  Seriously, 99.9% of the time
> complex type declarations are unnecessary.

But when it is, it tends to be crucial.

> One simplification that would help not break (much!) code would be to
> adopt C++'s reuse of "auto".

C++ is so complicated, that it's probably necessary. (In fact, when you 
spend even a short time looking at C++ and at *its* quirks, you start to
think that perhaps there's nothing much wrong with C after all!)

-- 
Bartc 

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

#20058

Rui Maciel <rui.maciel@gmail.com> writes:
> If you were given the task to design a replacement for the C programming 
> language intended to fix all its problems and shortcomings, what would you 
> propopose?

Just about every post-1978 language that uses curly braces to delimit
code blocks, and many that don't, is *somebody's* answer to that
question.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#20059

On 2012-04-29, Rui Maciel <rui.maciel@gmail.com> wrote:
> If you were given the task to design a replacement for the C programming 
> language intended to fix all its problems and shortcomings, what would you 
> propopose?

void. I would get rid of void. No "void func()", no (void) argument list, no
void * pointers.  Functions with no return value could be declared/defined with
the "proc" keyword.  Generic pointer would be "byte *", where byte would be a
type built in to the language, exactly like unsigned char, and explicit
conversion by cast would be required in both directions.

More consistent syntax. For instance function parameter decls separated
by semicolons, not commas, allowing:

   proc foo(int a, b, c; double *p)

I would smear the distinction between statements and expressions. Statements
would be allowed to return values, so for instance, this would be valid:

  int x = if (a > b) c; else d;

Conformance. I would distinguish warning and error diagnostics in the spec,
and forbid required diagnostics from being mere errors. Implementations which
translate a unit that requires a diagnostic, allowing it to be linked and
executed, would be considered nonconforming.

Introspection. The language would have an API for run time introspection.
I don't want to start writing details about this, but suffice it to say that
the introspection would be sufficient that it could allow a program in the
language to implement a precisely tracing garbage collector (even in the
presence of threads) without resorting to any platform-specific assembly
language or other hacks. Introspection would allow the GC to walk stacks and
know exactly where the live variable values are.

I would strengthen arrays without the disadvantages of making them more
encapsulated. There would a way to define an integral object which indicates
the size of an array referenced by a pointer:

   struct vec {
     double *dynamic : int size;
     double *fixed : 1; /* pointer to just one double */
   };

Such a definition introduces two objects, so that struct vec above has
a member called size of type int.  The compiler understands  that the
size of the array pointed at by v->dynamic is given by int size.

This would be in function parameters also:

   double dotproduct(double *v1 : int size_v1, *v2 : int size_v2);

Now when we have a sized vector, we can do this:

   dotproduct(v1->dynamic, v2->fixed);

The compiler knows that the size of v1->dynamic (where v1 points to a struct
vec) is given by v1->size. So, automatically, it passes v1->size as
the value for the size_v1 formal parameter. For size_v2, it passes 1.

If you pass an unsized pointer to a sized parameter, the size parameter is not
filled in. It must be specified explicitly:

   dotprodut(some_pointer : 4, v2->fixed);

If a pointer is derived from an array, its size is inferred from the array.

All dataflows involving pointers would automatically carry the size
information, if any, propgating it between the size objects:

   v1->dynamic = v2->dynamic; /* v1->size = v2->size is implicit! */

I would drop variable length arrays. They could be replaced by sized pointers
which are initialized using a notation:

   int *p : int s = [42];

This [42] is an initializer which means dynamically allocate automatic
storage, returning null if it is not possible, and the size is 42 times the
size of the pointer being initialized.  The variable s receives the value 42 if
the allocation succeeds, otherwise zero.

Of course, the s is optional:

   {
     int *p = [42]; // make auto array of 42 ints, or fail with null
   }
   // out of scope: array is now gone

The nice thing is that we can now pass p into functions, and using the
size-propagation logic, functions can know the size. This is even if we wrap p
inside a data structure:

  struct obj {
     int *ptr : int size;
  };

  proc foo(struct obj);
  int bar(int *ptr : int size);

  /* ... */

  {
    int *p = [42];
    struct obj;
    obj.ptr = p; // implicit: obj.size = 42;
    foo(obj); // foo knows size
    bar(p);  // bar receives size
  }

Pointer arithmetic would also propagate the size, if possible. (Which is part
of the point.)

If p is a size-attributed pointer of constant size s, then p + n is either
erroneous, if this is out of bounds, or it produces a new pointer displaced
by n, whose size attribute is the value s - n.

If p is a size-attributed pointer with a variable size stored in object s, then
p + n evaluates s to determine whether p + n is out of bounds.
If it is not out of bounds, then the displaced pointer p + n is produced,
and its size attribute is the rvalue s - n.  (No provision for safety for
negative displacements would be provided.)

Example:  

  {
    int *p : int size = [42];

    p++; /* size is now 41 */

    p -= 2; /* UB. */
  }


Arrays would be first class citizens: passed into functions, returned from
functions.  Array syntax in a function argument list would not denote a
pointer.  Size mismatches would diagnose. An explicit cast would override the
size mismatch, resulting in truncating or zero-padding semantics.

   /* funct takes one int, returns array of 3 int. */

   int (func[3])(int a)
   {
     int x[2] = { 1, 2 };

     return x; /* error, size mismatch */

     return (int[3]) x; /* return value is padded with zero */
   }

I would provide a simple namespacing scheme based on textual gluing of prefixes
onto identifiers.

On the definition side:

   prefix mylib_ {
     int open(char *);
     int close(int);
   };

The above is precisely equivalent to:

   int mylib_open(char *);
   int mylib_close(int);

On the use side:

   prefix mylib_ open, close;

This means that if the names mylib_open and mylib_close are visible in this
scope, the short names open and close now stand for mylib_open and mylib_close.
If no such names are visible, it is erroneous.

Something similar would be provided for preprocessor symbols (if I actually
kept the preprocessor as such).

Control flow.  I would provide a non-local dynamic return mechanism with
cleanup (unwind protect). Any function or block would be able to execute
cleanup code if it is terminated by a nonlocal transfer.
Some kind of exception handling would be provided.
Named blocks for breaking out of nested constructs.

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

#20098

"Kaz Kylheku" <kaz@kylheku.com> wrote in message 
news:20120429094636.81@kylheku.com...
> On 2012-04-29, Rui Maciel <rui.maciel@gmail.com> wrote:
>> If you were given the task to design a replacement for the C programming
>> language intended to fix all its problems and shortcomings, what would 
>> you
>> propopose?

> I would strengthen arrays without the disadvantages of making them more
> encapsulated.

What are the disadvantages of an encapsulated array (assuming there are 
still regular arrays too)?

> There would a way to define an integral object which indicates
> the size of an array referenced by a pointer:

>     double *dynamic : int size;

I recently created a similar feature, I just called it a 'slice', but it is 
simply an encapsulated (pointer, length) object.  This is handy for passing 
to functions (passing a regular array as a slice parameter, the length is 
automatically filled in and the caller knows then the size of the array). 
But is not suitable for proper dynamic arrays where the language looks after 
the memory side.

This opens the way to slicing operations in the language, and works with 
char arrays too! (Ie. you get counted strings for free.)

-- 
Bartc 

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

#20061

"Rui Maciel" <rui.maciel@gmail.com> ha scritto nel messaggio 
news:jnjpil$ek2$1@speranza.aioe.org...
> If you were given the task to design a replacement for the C programming
> language intended to fix all its problems and shortcomings, what would you
> propopose?
>
>
> Rui Maciel

i propose assembly: 8 32 bits registers and 20 - 30 instruction on them ...

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

#20062

"io_x" <a@b.c.invalid> ha scritto nel messaggio 
news:4f9d9e5f$0$1384$4fafbaef@reader2.news.tin.it...
>
> "Rui Maciel" <rui.maciel@gmail.com> ha scritto nel messaggio 
> news:jnjpil$ek2$1@speranza.aioe.org...
>> If you were given the task to design a replacement for the C programming
>> language intended to fix all its problems and shortcomings, what would you
>> propopose?
>>
>>
>> Rui Maciel
>
> i propose assembly: 8 32 bits registers and 20 - 30 instruction on them ...

here i not find the google sys for NG
so google not support NG?

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

#20089

On Sunday, April 29, 2012 9:23:08 PM UTC+1, io_x wrote:

> here i not find the google sys for NG
> so google not support NG?

if you want a proper reply make it clearer what you are asking.

this was posted from Google Groups. Does that answer your question?

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

#20095

On 04/30/2012 03:41 AM, nick_keighley_nospam@hotmail.com wrote:
> On Sunday, April 29, 2012 9:23:08 PM UTC+1, io_x wrote:
> 
>> here i not find the google sys for NG
>> so google not support NG?
> 
> if you want a proper reply make it clearer what you are asking.

You're talking to io_x; clarity is not an available option.
-- 
James Kuyper

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

#20099

"James Kuyper" <jameskuyper@verizon.net> ha scritto nel messaggio 
news:jnlt4j$4vp$2@dont-email.me...
> On 04/30/2012 03:41 AM, nick_keighley_nospam@hotmail.com wrote:
>> On Sunday, April 29, 2012 9:23:08 PM UTC+1, io_x wrote:
>>
>>> here i not find the google sys for NG
>>> so google not support NG?
>>
>> if you want a proper reply make it clearer what you are asking.
>
> You're talking to io_x; clarity is not an available option.

yes, i find the link in the II page of www.google.it ...

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

#20063

"io_x" <a@b.c.invalid> ha scritto nel messaggio 
news:4f9d9e5f$0$1384$4fafbaef@reader2.news.tin.it...
>
> "Rui Maciel" <rui.maciel@gmail.com> ha scritto nel messaggio 
> news:jnjpil$ek2$1@speranza.aioe.org...
>> If you were given the task to design a replacement for the C programming
>> language intended to fix all its problems and shortcomings, what would you
>> propopose?
>>
>>
>> Rui Maciel
>
> i propose assembly: 8 32 bits registers and 20 - 30 instruction on them ...

and some instruction on 8 bit unsigned char too

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

#20065

io_x wrote:

> i propose assembly: 8 32 bits registers and 20 - 30 instruction on them
> ...

Why?  What's wrong with writing routines in assembly and then calling those 
routines from C?


Rui Maciel

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

#20085

"Rui Maciel" <rui.maciel@gmail.com> ha scritto nel messaggio 
news:jnk87q$pu4$1@speranza.aioe.org...
> io_x wrote:
>
>> i propose assembly: 8 32 bits registers and 20 - 30 instruction on them
>> ...
>
> Why?  What's wrong with writing routines in assembly and then calling those
> routines from C?

my macro assembly is easier than C because not has undefinite behaviour
and it is as it has to be... the loop-if build with gotos

> Rui Maciel 

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

Page 2 of 13 — ← Prev page 1 [2] 3 4 … 13  Next page →

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

csiph-web