Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #103912 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2017-02-14 15:37 -0800 |
| Last post | 2017-04-26 09:58 -0700 |
| Articles | 20 on this page of 147 — 26 participants |
Back to article view | Back to comp.lang.c
What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-14 15:37 -0800
Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-15 00:05 -0800
Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-15 00:57 -0800
Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-15 07:21 -0800
Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-15 07:24 -0800
Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-15 08:10 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 03:05 -0800
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-15 11:38 +0000
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 04:28 -0800
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-15 13:22 +0000
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 05:47 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 10:06 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 05:24 -0800
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-15 13:57 +0000
Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-19 10:27 -0800
Re: What if pre-processor was moved to parser? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-15 15:16 +0000
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 08:14 -0800
Re: What if pre-processor was moved to parser? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-15 18:01 +0000
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-15 18:25 +0000
Re: What if pre-processor was moved to parser? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-15 19:14 +0000
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-15 10:25 -0800
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-15 18:45 +0000
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-15 20:03 +0100
Re: What if pre-processor was moved to parser? jameskuyper@verizon.net - 2017-02-15 10:12 -0800
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-15 10:51 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 12:14 -0800
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-15 20:25 +0000
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 12:50 -0800
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-16 11:50 +0000
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-16 04:44 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-16 05:28 -0800
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-16 14:32 +0000
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-16 09:13 -0800
Re: What if pre-processor was moved to parser? Keith Thompson <kst-u@mib.org> - 2017-02-16 10:38 -0800
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-16 11:55 -0800
Re: What if pre-processor was moved to parser? Keith Thompson <kst-u@mib.org> - 2017-02-16 12:24 -0800
Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-16 21:32 +0100
Re: What if pre-processor was moved to parser? Keith Thompson <kst-u@mib.org> - 2017-02-16 12:55 -0800
Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-16 22:41 +0100
Re: What if pre-processor was moved to parser? Keith Thompson <kst-u@mib.org> - 2017-02-16 14:02 -0800
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-16 15:08 -0800
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-16 13:32 -0800
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-17 21:19 +1300
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-17 12:01 +0100
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-17 09:16 -0800
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-17 18:55 +0100
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 08:07 +1300
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-17 20:12 +0100
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 11:04 +1300
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-17 22:38 +0000
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 11:47 +1300
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-17 14:55 -0800
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 12:11 +1300
Re: What if pre-processor was moved to parser? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-02-17 15:26 -0800
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-17 16:15 -0800
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 13:22 +1300
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-17 16:37 -0800
Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-18 11:57 +0100
Re: What if pre-processor was moved to parser? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-18 07:13 +0000
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 20:26 +1300
Re: What if pre-processor was moved to parser? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-18 09:17 +0000
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-18 01:18 +0100
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 13:23 +1300
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-18 01:45 +0100
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 16:18 +1300
Re: What if pre-processor was moved to parser? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-18 07:19 +0000
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 20:30 +1300
Re: What if pre-processor was moved to parser? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-18 09:18 +0000
Re: What if pre-processor was moved to parser? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-18 07:15 -0800
Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-24 09:24 -0800
Re: What if pre-processor was moved to parser? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-24 17:51 +0000
Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-24 10:08 -0700
Re: What if pre-processor was moved to parser? Richard Heathfield <rjh@cpax.org.uk> - 2017-04-24 18:58 +0100
Re: What if pre-processor was moved to parser? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-04-26 05:03 +0000
Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 11:21 -0700
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-25 09:15 +1300
Re: What if pre-processor was moved to parser? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-24 17:29 -0800
Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-26 06:19 -0700
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-26 16:04 +0200
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-04-26 07:08 -0700
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-26 16:46 +0200
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-04-26 09:32 -0700
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-26 20:19 +0200
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-04-26 11:29 -0700
Re: What if pre-processor was moved to parser? scott@slp53.sl.home (Scott Lurndal) - 2017-04-26 18:51 +0000
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-04-27 09:32 +1200
Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-04-27 11:01 +0200
Re: What if pre-processor was moved to parser? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-04-27 02:23 -0700
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-04-27 21:31 +1200
Re: What if pre-processor was moved to parser? Ike Naar <ike@iceland.freeshell.org> - 2017-04-27 16:15 +0000
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-04-27 09:35 -0700
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-28 15:12 +0200
Re: What if pre-processor was moved to parser? Gareth Owen <gwowen@gmail.com> - 2017-04-27 19:13 +0100
Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-04-27 11:37 +0200
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-27 15:18 +0200
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-18 08:43 +0100
Re: What if pre-processor was moved to parser? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-18 09:22 +0000
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-18 09:44 -0800
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-18 11:33 +0000
Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-18 13:25 +0100
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-18 13:47 +0000
Re: What if pre-processor was moved to parser? Jean-Marc Bourguet <jm@bourguet.org> - 2017-02-18 15:23 +0100
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-18 14:53 +0000
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-18 16:56 +0000
Re: What if pre-processor was moved to parser? Robert Wessel <robertwessel2@yahoo.com> - 2017-02-18 22:50 -0600
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-19 09:45 +0100
Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-19 13:35 +0100
Re: What if pre-processor was moved to parser? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-18 11:24 -0500
Re: What if pre-processor was moved to parser? Robert Wessel <robertwessel2@yahoo.com> - 2017-02-18 22:48 -0600
Re: What if pre-processor was moved to parser? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-18 10:04 -0800
Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-19 17:12 +0100
Re: What if pre-processor was moved to parser? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-19 11:11 -0800
Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-19 21:14 +0100
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-19 21:22 +0100
Re: What if pre-processor was moved to parser? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-19 12:33 -0800
Re: What if pre-processor was moved to parser? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-19 12:31 -0800
Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-19 13:14 -0800
Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-19 14:50 -0800
Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-19 15:04 -0800
Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-20 10:13 +0100
Re: What if pre-processor was moved to parser? Gareth Owen <gwowen@gmail.com> - 2017-02-19 21:09 +0000
Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-23 15:32 -0800
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-24 12:44 +1300
Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-19 21:04 -0800
Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-19 21:14 -0800
Re: What if pre-processor was moved to parser? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-02-16 14:48 -0800
Re: What if pre-processor was moved to parser? Keith Thompson <kst-u@mib.org> - 2017-02-16 15:46 -0800
Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-23 16:16 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-20 04:18 -0800
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-20 06:47 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-20 09:50 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-21 04:33 -0800
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-21 15:41 +0100
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-21 09:39 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-21 09:59 -0800
Re: What if pre-processor was moved to parser? TickleMe Elmo <tmelmosfire@gmail.com> - 2017-02-21 10:22 -0800
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-20 15:49 +0000
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-20 09:43 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 12:31 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-16 03:33 -0800
Re: What if pre-processor was moved to parser? jameskuyper@verizon.net - 2017-02-15 12:47 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 13:06 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 13:15 -0800
Re: What if pre-processor was moved to parser? "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-02-18 12:36 +0100
Re: What if pre-processor was moved to parser? "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-02-18 12:41 +0100
Re: What if pre-processor was moved to parser? John Bode <jfbode1029@gmail.com> - 2017-04-26 09:42 -0700
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-04-26 09:58 -0700
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2017-02-14 15:37 -0800 |
| Subject | What if pre-processor was moved to parser? |
| Message-ID | <11c906d6-9be0-44df-82b4-157fdba3b91c@googlegroups.com> |
I was wondering how to eliminate pre-processor keeping compatibility with existing C code. Let's say we move the pre-processor for parser in a new C2 language. (file extensions .h2 and .c2) I want to keep the original includes of system headers as it is: Let's say there is a flag inside the compiler classic pre-processor ON or OFF. So in a file.c2 that is "C2" the pre-processor mode starts as OFF //When we include a extension .h //the c pre-processor flat is ON //normal C pre-processor using DEBUG, WIN32 etc.. //include itself is not normal in this file. #include <stdio.h> //pre-processor flag is OFF after include //The include here is not pre-processor command // pre-processor still OF because the file is .h2 #include "myfile.h2" Now, let's see the new rules #define is inside the C grammar. If must be used in some specific places. The same for #if #else... The defined symbol is no more a macro. It's a symbol inside the AST. The #if is branch inside the AST like normal if / else. The #define in pre-processor ON it's not the same (don't mix) with #define when pre-processor is OFF. sizeof and other new features can be added to #if expressions. For instance, we can ask if the function F was defined or some variable. Macro expansion? Besides simple macros I don't have idea the new rules. So I don't known what would be allowed. For the worst case, only simple #define would work. Why to do this? For many reasons. For safer code, for refactoring tools, better tools etc. What do you think?
[toc] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-02-15 00:05 -0800 |
| Message-ID | <c7ff1363-8fe1-4c9b-bb9c-7f39ffc800d1@googlegroups.com> |
| In reply to | #103912 |
W dniu środa, 15 lutego 2017 00:37:48 UTC+1 użytkownik Thiago Adams napisał: > I was wondering how to eliminate pre-processor > keeping compatibility with existing C code. > > Let's say we move the pre-processor for parser in > a new C2 language. (file extensions .h2 and .c2) > i am using C2 name for my improved c witm my set of extensions and improvements, i use it like 10 years, recently thinked though if it is best name i can know.. d would be maybe not bad (logicl consequence is d) but it is already used, still dont know; (will it be illegal to use d name then?) C2 i use more like codeneme i chosen also a sign for that - slaine be that sign http://minddetonator.htw.pl/c2.jpg (slaine has an axe which looks like c, also slaine afair was old irish who was fighting with fomorians, (same as firbolgs maybe) - on old irish fir means men/people and i recently get know my firish nick has old irish connotations it seem fits fine) > I want to keep the original includes of system headers > as it is: > > Let's say there is a flag inside the compiler > classic pre-processor ON or OFF. > > So in a file.c2 that is "C2" the pre-processor mode starts as OFF > > //When we include a extension .h > //the c pre-processor flat is ON > //normal C pre-processor using DEBUG, WIN32 etc.. > > //include itself is not normal in this file. > #include <stdio.h> > > //pre-processor flag is OFF after include > > //The include here is not pre-processor command > // pre-processor still OF because the file is .h2 > #include "myfile.h2" > > Now, let's see the new rules > > > #define is inside the C grammar. > If must be used in some specific places. > The same for #if #else... > The defined symbol is no more a macro. It's a symbol inside > the AST. > The #if is branch inside the AST like normal if / else. > The #define in pre-processor ON it's not the same (don't mix) with > #define when pre-processor is OFF. > > > sizeof and other new features can be added to #if expressions. > For instance, we can ask if the function F was defined or some variable. > > Macro expansion? > Besides simple macros I don't have idea the new rules. > So I don't known what would be allowed. For the worst case, only > simple #define would work. > Why to do this? For many reasons. > For safer code, for refactoring tools, better tools etc. > > > > What do you think?
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-02-15 00:57 -0800 |
| Message-ID | <1924856c-2ffc-47f2-91cb-6c1946483058@googlegroups.com> |
| In reply to | #103919 |
W dniu środa, 15 lutego 2017 09:05:41 UTC+1 użytkownik fir napisał:
> W dniu środa, 15 lutego 2017 00:37:48 UTC+1 użytkownik Thiago Adams napisał:
> > I was wondering how to eliminate pre-processor
> > keeping compatibility with existing C code.
> >
> > Let's say we move the pre-processor for parser in
> > a new C2 language. (file extensions .h2 and .c2)
> >
>
> i am using C2 name for my improved c witm my set of extensions and improvements, i use it like 10 years, recently thinked though if it
> is best name i can know..
>
> d would be maybe not bad (logicl consequence is d) but it is already used, still dont know; (will it be illegal to use d name then?)
>
> C2 i use more like codeneme i chosen also a sign for that - slaine be that sign
>
> http://minddetonator.htw.pl/c2.jpg
>
> (slaine has an axe which looks like c, also slaine afair was old irish who was fighting
> with fomorians, (same as firbolgs maybe) - on old irish fir means men/people and i recently
> get know my firish nick has old irish connotations it seem fits fine)
>
recent additions was resizable local arrays
in heap/stack way, optionall ommiting type declarations for locals and those parent
pathes of parent functions;
before it was automatic chunk support an syntax for multimodule methods* (also some
smaller things)
*maybe good that i refreshed thet coz it
seems to dim in my memory and this is interesting
[Character a] void hit() [Character b]
{
b hp -= a hit;
}
void mian()
{
Character jim, alan;
jim hit alan;
printf("alan health %d", alan.hp)
}
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-02-15 07:21 -0800 |
| Message-ID | <84e34fd6-473c-4cb7-85b1-4befe5f377cc@googlegroups.com> |
| In reply to | #103923 |
W dniu środa, 15 lutego 2017 09:57:58 UTC+1 użytkownik fir napisał:
>
> before it was automatic chunk support an syntax for multimodule methods* (also some
> smaller things)
>
> *maybe good that i refreshed thet coz it
> seems to dim in my memory and this is interesting
>
>
> [Character a] void hit() [Character b]
> {
> b hp -= a hit;
> }
>
>
>
> void mian()
> {
> Character jim, alan;
> jim hit alan;
>
> printf("alan health %d", alan.hp)
> }
this above was very interesting remark (to me)
but still i though this example was not fully understood (by me)
some claryfication would be to rematk that in
such C2 function could be a method and a function at once - here above hit(5) would be function call alan hit jim would be a method -way call (alan hit(5) jim would be both at once)
such distinguishment on two categories/families could be usefull (and still needs some understanding)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-02-15 07:24 -0800 |
| Message-ID | <1a9e56cb-d992-4c59-a1b2-a6d052bb7e1c@googlegroups.com> |
| In reply to | #103937 |
W dniu środa, 15 lutego 2017 16:21:44 UTC+1 użytkownik fir napisał:
> W dniu środa, 15 lutego 2017 09:57:58 UTC+1 użytkownik fir napisał:
> >
> > before it was automatic chunk support an syntax for multimodule methods* (also some
> > smaller things)
> >
> > *maybe good that i refreshed thet coz it
> > seems to dim in my memory and this is interesting
> >
> >
> > [Character a] void hit() [Character b]
> > {
> > b hp -= a hit;
> > }
> >
> >
> >
> > void mian()
> > {
> > Character jim, alan;
> > jim hit alan;
> >
> > printf("alan health %d", alan.hp)
> > }
>
> this above was very interesting remark (to me)
> but still i though this example was not fully understood (by me)
>
> some claryfication would be to rematk that in
> such C2 function could be a method and a function at once - here above hit(5) would be function call alan hit jim would be a method -way call (alan hit(5) jim would be both at once)
> such distinguishment on two categories/families could be usefull (and still needs some understanding)
with this view alos clasical c functions are methods (If function reads or changes module variables it is a method, if it takes or returns values it is a function - if both it is both)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-02-15 08:10 -0800 |
| Message-ID | <e72acd4b-4db4-480e-9495-649609bb8236@googlegroups.com> |
| In reply to | #103938 |
W dniu środa, 15 lutego 2017 16:24:21 UTC+1 użytkownik fir napisał:
> W dniu środa, 15 lutego 2017 16:21:44 UTC+1 użytkownik fir napisał:
> > W dniu środa, 15 lutego 2017 09:57:58 UTC+1 użytkownik fir napisał:
> > >
> > > before it was automatic chunk support an syntax for multimodule methods* (also some
> > > smaller things)
> > >
> > > *maybe good that i refreshed thet coz it
> > > seems to dim in my memory and this is interesting
> > >
> > >
> > > [Character a] void hit() [Character b]
> > > {
> > > b hp -= a hit;
> > > }
> > >
> > >
> > >
> > > void mian()
> > > {
> > > Character jim, alan;
> > > jim hit alan;
> > >
> > > printf("alan health %d", alan.hp)
> > > }
> >
> > this above was very interesting remark (to me)
> > but still i though this example was not fully understood (by me)
> >
> > some claryfication would be to rematk that in
> > such C2 function could be a method and a function at once - here above hit(5) would be function call alan hit jim would be a method -way call (alan hit(5) jim would be both at once)
> > such distinguishment on two categories/families could be usefull (and still needs some understanding)
>
> with this view alos clasical c functions are methods (If function reads or changes module variables it is a method, if it takes or returns values it is a function - if both it is both)
and if touches more modules is multimethod
(at least i call it this name 2-method 3-method n-method)
//
it can be maybe noted that c supports modules but in weak form/partially (if it can be said
that way 'support' becouse c seen it i think other way, so what c supports is something and this something only mesh with modules maybe)
i personally was describing how one can add
more modular supprt to c (it was a pack of notices, possibly not finished, (i am also
no 100% sure if this just need to go in,
and no other way is better, but at some level seem probably ok) , maybe later i will add
yet more to this) [it will be no doubt interesting to really/fully understood it]
//
i once ago had written about what i call f/s
unificiation (idea of uniffying two main families you got in c functions and structures
(entities)) now this m/f division seem also curious (interesting) to me - (as modules was expected this m/f was somewhat unexpected)
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2017-02-15 03:05 -0800 |
| Message-ID | <dd3ed896-e224-4263-ab5c-ea782b3c84f5@googlegroups.com> |
| In reply to | #103912 |
Some interesting links about refactoring of C programs and about the difficulties caused by pre-processing. PROGRAM REFACTORING IN THE PRESENCE OF PREPROCESSOR DIRECTIVES http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.1012.294&rep=rep1&type=pdf Refactoring C with Conditional Compilation http://www.informatik.uni-bremen.de/st/lehre/Arte-fakt/Seminar/papers/17/Refactoring%20C%20with%20Conditional%20Compilation.pdf Challenges of Refactoring C Programs https://www.researchgate.net/profile/Alejandra_Garrido2/publication/234805773_Challenges_of_Refactoring_C_Programs/links/0c96051cc23aaa9dd1000000.pdf (My interest is also source-to-source transformation.) >Macro expansion? >Besides simple macros I don't have idea the new rules. >So I don't known what would be allowed. For the worst case, only >simple #define would work. MISRA C has this rule: "Rule 19.4 (required): C macros shall only expand to a braced initialiser, a constant,a string literal, a parenthesized expression, a type qualifier, a storage class specifier, or a do-while-zero construct." This is interesting and this rule (or something similar) could be applied for the grammar that include "pre-processing".
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-15 11:38 +0000 |
| Message-ID | <o81egc$b6q$1@dont-email.me> |
| In reply to | #103924 |
On 15/02/2017 11:05, Thiago Adams wrote: > > Some interesting links about refactoring of C programs and about > the difficulties caused by pre-processing. > > PROGRAM REFACTORING IN THE PRESENCE OF PREPROCESSOR DIRECTIVES > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.1012.294&rep=rep1&type=pdf OK, 220 pages to tell us what everyone knows. (Did the author succeed in re-factoring arbitrary C code that may be full of conditionals and that may depend on a specific compiler?) > Refactoring C with Conditional Compilation > http://www.informatik.uni-bremen.de/st/lehre/Arte-fakt/Seminar/papers/17/Refactoring%20C%20with%20Conditional%20Compilation.pdf > > Challenges of Refactoring C Programs > https://www.researchgate.net/profile/Alejandra_Garrido2/publication/234805773_Challenges_of_Refactoring_C_Programs/links/0c96051cc23aaa9dd1000000.pdf > (My interest is also source-to-source transformation.) > >> Macro expansion? >> Besides simple macros I don't have idea the new rules. >> So I don't known what would be allowed. For the worst case, only >> simple #define would work. > > MISRA C has this rule: > > "Rule 19.4 (required): C macros shall only expand to a braced > initialiser, a constant,a string literal, a parenthesized expression, > a type qualifier, a storage class specifier, or a do-while-zero > construct." > > This is interesting and this rule (or something similar) > could be applied for the grammar that include "pre-processing". So your proposal was to forget the existing CPP, and create a new one that is properly integrated into the main syntax. MISRA's approach is to restrict the use of macros to a small set of well-structured common uses. My approach, in my own languages, was to not to have such powerful preprocessor as C's at all. And that hasn't presented any particular problems in decades of coding. (I have used include files; I have very rarely used conditional code; and I occasionally use a simple parameterless macro: just a straight text replacement.) I think, if there was a pressing need for something, then I would introduce a new language feature for it without resorting to macros as seems to be the C solution for everything. And programs full of macros, as well as being less readable and causing problems for refactoring, are slower to compile. Since it seems you are thinking of creating a C replacement, you can start by investigating existing uses of macros, which may have to go further then MISRA, and seeing how they would look as proper features directly in the language. (Include files I don't see as problematical; a re-factor program can read the the file and make use of the information; then the include file is re-factored separately. The end result will still use #include.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2017-02-15 04:28 -0800 |
| Message-ID | <0759d62a-eda6-4725-9625-e0d01f944ca8@googlegroups.com> |
| In reply to | #103925 |
On Wednesday, February 15, 2017 at 9:38:51 AM UTC-2, Bart wrote: > On 15/02/2017 11:05, Thiago Adams wrote: > > > > Some interesting links about refactoring of C programs and about > > the difficulties caused by pre-processing. > > > > PROGRAM REFACTORING IN THE PRESENCE OF PREPROCESSOR DIRECTIVES > > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.1012.294&rep=rep1&type=pdf > > OK, 220 pages to tell us what everyone knows. (Did the author succeed in > re-factoring arbitrary C code that may be full of conditionals and that > may depend on a specific compiler?) > > > Refactoring C with Conditional Compilation > > http://www.informatik.uni-bremen.de/st/lehre/Arte-fakt/Seminar/papers/17/Refactoring%20C%20with%20Conditional%20Compilation.pdf > > > > Challenges of Refactoring C Programs > > https://www.researchgate.net/profile/Alejandra_Garrido2/publication/234805773_Challenges_of_Refactoring_C_Programs/links/0c96051cc23aaa9dd1000000.pdf > > > (My interest is also source-to-source transformation.) > > > >> Macro expansion? > >> Besides simple macros I don't have idea the new rules. > >> So I don't known what would be allowed. For the worst case, only > >> simple #define would work. > > > > MISRA C has this rule: > > > > "Rule 19.4 (required): C macros shall only expand to a braced > > initialiser, a constant,a string literal, a parenthesized expression, > > a type qualifier, a storage class specifier, or a do-while-zero > > construct." > > > > This is interesting and this rule (or something similar) > > could be applied for the grammar that include "pre-processing". > > > So your proposal was to forget the existing CPP, and create a new one > that is properly integrated into the main syntax. Yes, but at same time being compatible when including system header or normal C code. (Activates "CPP ON" for compatibility) > MISRA's approach is to restrict the use of macros to a small set of > well-structured common uses. > > My approach, in my own languages, was to not to have such powerful > preprocessor as C's at all. And that hasn't presented any particular > problems in decades of coding. > > (I have used include files; I have very rarely used conditional code; > and I occasionally use a simple parameterless macro: just a straight > text replacement.) > > I think, if there was a pressing need for something, then I would > introduce a new language feature for it without resorting to macros as > seems to be the C solution for everything. And programs full of macros, > as well as being less readable and causing problems for refactoring, are > slower to compile. > > Since it seems you are thinking of creating a C replacement, you can > start by investigating existing uses of macros, which may have to go > further then MISRA, and seeing how they would look as proper features > directly in the language. > > (Include files I don't see as problematical; a re-factor program > can read the the file and make use of the information; then the include > file is re-factored separately. The end result will still use #include.) > My suggestion was to make C' work without pre-processing in a way that most of people would not notice. Nothing new to learn. I don't see #include and #if, #else .. as problem for a parser. The C# language, for instance, which has a lot of refactoring tools, has #if etc. C# Preprocessor Directives https://msdn.microsoft.com/en-us/library/ed8yd1ha.aspx "Although the compiler does not have a separate preprocessor, the directives described in this section are processed as if there were one. " The grammar of C# : http://www.cs.vu.nl/grammarware/browsable/CSharp/grammar.html The use of #define is limited.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-15 13:22 +0000 |
| Message-ID | <o81kin$347$1@dont-email.me> |
| In reply to | #103926 |
On 15/02/2017 12:28, Thiago Adams wrote:
> On Wednesday, February 15, 2017 at 9:38:51 AM UTC-2, Bart wrote:
>> So your proposal was to forget the existing CPP, and create a new one
>> that is properly integrated into the main syntax.
> My suggestion was to make C' work without pre-processing in a way
> that most of people would not notice. Nothing new to learn.
>
> I don't see #include and #if, #else .. as problem for a parser.
How does it interact with normal 'if'?
Both ifs have a well-formed nested structure but what happens if these
two lots of structure conflict? Would the following be OK for example:
#if X
if (cond) {
#endif
stmt1;
}
I can see difficulties with supporting this in a recursive-descent parser.
If you stipulate that what's in each #if branch must be a
self-contained, well-formed bit of code, then it becomes harder to tell
the difference between #if and if.
I suppose one difference might be that the contents of a false #if
branch need not compile, beyond having to contain valid syntax. But that
just brings up the issue of what is allowed in a #if 0 branch and what
isn't.
> The grammar of C# : http://www.cs.vu.nl/grammarware/browsable/CSharp/grammar.html
>
> The use of #define is limited.
You can say that. A #define symbol is either defined or undefined; there
is no replacement text associated with it. That's even simpler than what
I use!
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2017-02-15 05:47 -0800 |
| Message-ID | <99b5b753-9503-441e-86a9-736210ecfc37@googlegroups.com> |
| In reply to | #103928 |
On Wednesday, February 15, 2017 at 11:22:30 AM UTC-2, Bart wrote:
> On 15/02/2017 12:28, Thiago Adams wrote:
> > On Wednesday, February 15, 2017 at 9:38:51 AM UTC-2, Bart wrote:
>
> >> So your proposal was to forget the existing CPP, and create a new one
> >> that is properly integrated into the main syntax.
>
> > My suggestion was to make C' work without pre-processing in a way
> > that most of people would not notice. Nothing new to learn.
> >
> > I don't see #include and #if, #else .. as problem for a parser.
>
> How does it interact with normal 'if'?
>
> Both ifs have a well-formed nested structure but what happens if these
> two lots of structure conflict? Would the following be OK for example:
>
> #if X
> if (cond) {
> #endif
> stmt1;
> }
>
> I can see difficulties with supporting this in a recursive-descent parser.
>
> If you stipulate that what's in each #if branch must be a
> self-contained, well-formed bit of code, then it becomes harder to tell
> the difference between #if and if.
>
> I suppose one difference might be that the contents of a false #if
> branch need not compile, beyond having to contain valid syntax. But that
> just brings up the issue of what is allowed in a #if 0 branch and what
> isn't.
>
> > The grammar of C# : http://www.cs.vu.nl/grammarware/browsable/CSharp/grammar.html
> >
> > The use of #define is limited.
>
> You can say that. A #define symbol is either defined or undefined; there
> is no replacement text associated with it. That's even simpler than what
> I use!
>
> --
I tried in C#:
class Program
{
static void Main(string[] args)
{
#if DEBUG
int i = 0;
if (i != 0)
{
#else
int i = 1;
#endif
}
}
}
I was not expecting this to compile. But it compiled.
So the region inside #if doesn't need to be valid.
The grammar at
http://www.cs.vu.nl/grammarware/browsable/CSharp/grammar.html
has (conditional-section:)
So, some problems of macros still there in C#.
For refactoring for instance,
class Program
{
#if DEBUG
static void f2()
{
#else
static void f2()
{
#endif
}
static void Main(string[] args)
{
f2();
}
}
When I rename f2, only the active branch (DEBUG) was renamed.
But the problem of "rebuild" the font is not there because
the #if is inside the AST.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2017-02-15 10:06 -0800 |
| Message-ID | <c40cb3a8-ff82-4767-a4bd-23f30e3e74f2@googlegroups.com> |
| In reply to | #103926 |
On Wednesday, February 15, 2017 at 10:28:15 AM UTC-2, Thiago Adams wrote:
[...]
> Yes, but at same time being compatible when including system header or
> normal C code. (Activates "CPP ON" for compatibility)
More details about this idea:
Let's say I have "my.c" that includes "sqlite.h"
#include <sqlite.h>
When including sqlite.h c preprocessor will work normally.
So, my.c will not see any macro during this expansion.
After sqlite.h inclusion we still have the macro definitions
present. (hash table of defines)
If I include other file.h the macro definitions will be there.
#include <sqlite.h>
#include "file.h"
When I return to my.c (file being compiled) then I am
in the "preprocessor off" mode.
Let's say I have:
int main()
{
int i = 2 * A;
}
and A was defined inside "file.h"
#define A 1 + 2
When the parser see A it will check if A is a macro.
If it is, the parser will check if A is "compatible"
macro (constant, constant-expression ...)
If not the code will not compile.
Note that when are including file.h we are not going to see
the definition (#define) of A. This definition will be "eat".
But we see the result of definition. (hash map of defines after inclusion)
#defines out of the #include that are parsed by a new grammar.
#define inside of includes are parsed normally (as it is today).
So, what is the advantage?
I can rebuild my.c from AST and I have safer macros.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2017-02-15 05:24 -0800 |
| Message-ID | <436a6e24-df32-45d9-b24e-c1e135c32c24@googlegroups.com> |
| In reply to | #103925 |
On Wednesday, February 15, 2017 at 9:38:51 AM UTC-2, Bart wrote:
...
> I think, if there was a pressing need for something, then I would
> introduce a new language feature for it without resorting to macros as
> seems to be the C solution for everything. And programs full of macros,
> as well as being less readable and causing problems for refactoring, are
> slower to compile.
>
> Since it seems you are thinking of creating a C replacement, you can
> start by investigating existing uses of macros, which may have to go
> further then MISRA, and seeing how they would look as proper features
> directly in the language.
Some samples to make the idea clear:
I will allow empty define, constant or constant-expression with ()
C' Grammar:
define-declaration:
#define identifier
#define identifier constant
#define identifier ( constant-expression )
Here #define is no more preprocessor.
The constant-expression can be evaluated and the value
is used as a constant. (Like enum constant)
Sample C' language with no preprocessor:
#define DEBUG
//This will not compile (missing ( ) )
//#define A 1 + 2
//This will compile
#define A (1 + 2)
#ifdef DEBUG
int i = 2 * A;
printf("%d", i); //prints 6
#endif
Today I use macros for initializers.
To cover this case I would have to add
some macro-initializer without "designator".
define-declaration:
#define identifier
#define identifier constant
#define identifier ( constant-expression )
#define identifier macro-initializer
Sample:
#define POINT_INIT {0, 0}
Point pt = POINT_INIT;
So macros could be:
- Simple named identifier for #if usage
- Constants (like enums)
- Macro-Initializer
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-15 13:57 +0000 |
| Message-ID | <o81mks$9sv$1@dont-email.me> |
| In reply to | #103929 |
On 15/02/2017 13:24, Thiago Adams wrote:
> On Wednesday, February 15, 2017 at 9:38:51 AM UTC-2, Bart wrote:
>> Since it seems you are thinking of creating a C replacement, you can
>> start by investigating existing uses of macros, which may have to go
>> further then MISRA, and seeing how they would look as proper features
>> directly in the language.
>
>
> Some samples to make the idea clear:
> I will allow empty define, constant or constant-expression with ()
>
> C' Grammar:
>
> define-declaration:
> #define identifier
> #define identifier constant
> #define identifier ( constant-expression )
>
> Here #define is no more preprocessor.
> The constant-expression can be evaluated and the value
> is used as a constant. (Like enum constant)
>
> Sample C' language with no preprocessor:
>
> #define DEBUG
>
> //This will not compile (missing ( ) )
> //#define A 1 + 2
>
> //This will compile
> #define A (1 + 2)
>
> So macros could be:
> - Simple named identifier for #if usage
> - Constants (like enums)
> - Macro-Initializer
If I concentrate on the use of #define for constant values. This is a
feature that does not have to be in any sort of preprocessor at all.
For years I've had named constants as a feature of my languages.
Examples (I use 'const' but 'constant' is shown here to avoid confusion
with C's 'const'):
constant maxlevel = 50 # type is int
constant pi = 3.14159265359 # type is double
constant x = pi*maxlevel+1 # 158.08, type double
constant real fsix = 6 # type is double
constant infile = "input" # type is char*
(Type is optional and picked up from the expression.)
This declares a fully typed, fully scoped named constant, unlike normal
#define, but a bit like C's enums. These names can't be used as lvalues.
They can be used for array bounds and switch-case values.
A very easy feature to support, and eliminates half the uses of #define.
And probably much more efficient than how C uses #define:
#define x (pi*maxlevel+1)
First, the "(...)" are necessary here because you don't know how the
surrounding code, when the macro is invoked, will interact with the *
and + operators.
Second, if 'x' is used 100 times, then it is necessary to expand, parse,
type-analyse and reduce (to a single constant) "(pi*maxlevel+1)" 100 times.
Compare that with using my 'constant x' which (once resolved) is just
replaced by 158.08 of known type double.
It's one of these no-brainer features that some languages stubbornly
refuse to adopt.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-19 10:27 -0800 |
| Message-ID | <kfntw7qvxxk.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #103931 |
BartC <bc@freeuk.com> writes: > On 15/02/2017 13:24, Thiago Adams wrote: >> On Wednesday, February 15, 2017 at 9:38:51 AM UTC-2, Bart wrote: >> >>> Since it seems you are thinking of creating a C replacement, you can >>> start by investigating existing uses of macros, which may have to go >>> further then MISRA, and seeing how they would look as proper features >>> directly in the language. >> >> Some samples to make the idea clear: >> [...] >> So macros could be: >> - Simple named identifier for #if usage >> - Constants (like enums) >> - Macro-Initializer > > If I concentrate on the use of #define for constant values. This is a > feature that does not have to be in any sort of preprocessor at all. It does if the symbols being defined are used in #if or other preprocessor conditionals.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-15 15:16 +0000 |
| Message-ID | <87lgt7qyan.fsf@bsb.me.uk> |
| In reply to | #103929 |
Thiago Adams <thiago.adams@gmail.com> writes: > On Wednesday, February 15, 2017 at 9:38:51 AM UTC-2, Bart wrote: > ... >> I think, if there was a pressing need for something, then I would >> introduce a new language feature for it without resorting to macros as >> seems to be the C solution for everything. And programs full of macros, >> as well as being less readable and causing problems for refactoring, are >> slower to compile. >> >> Since it seems you are thinking of creating a C replacement, you can >> start by investigating existing uses of macros, which may have to go >> further then MISRA, and seeing how they would look as proper features >> directly in the language. > > > Some samples to make the idea clear: > I will allow empty define, constant or constant-expression with () > > C' Grammar: > > define-declaration: > #define identifier > #define identifier constant > #define identifier ( constant-expression ) See below... > Here #define is no more preprocessor. > The constant-expression can be evaluated and the value > is used as a constant. (Like enum constant) > > Sample C' language with no preprocessor: > > #define DEBUG > > //This will not compile (missing ( ) ) > //#define A 1 + 2 > > //This will compile > #define A (1 + 2) If you make this a part of the language, then there is no need to insist on parentheses. But I would urge the use of something other the #define (#substitute?). In fact, there would no longer be any need the use the clumsy line-oriented syntax of the preprocessor. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2017-02-15 08:14 -0800 |
| Message-ID | <f46b1213-9af2-4a44-9e4e-2f2772d3d438@googlegroups.com> |
| In reply to | #103936 |
On Wednesday, February 15, 2017 at 1:16:55 PM UTC-2, Ben Bacarisse wrote: > Thiago Adams writes: > > > On Wednesday, February 15, 2017 at 9:38:51 AM UTC-2, Bart wrote: > > ... > >> I think, if there was a pressing need for something, then I would > >> introduce a new language feature for it without resorting to macros as > >> seems to be the C solution for everything. And programs full of macros, > >> as well as being less readable and causing problems for refactoring, are > >> slower to compile. > >> > >> Since it seems you are thinking of creating a C replacement, you can > >> start by investigating existing uses of macros, which may have to go > >> further then MISRA, and seeing how they would look as proper features > >> directly in the language. > > > > > > Some samples to make the idea clear: > > I will allow empty define, constant or constant-expression with () > > > > C' Grammar: > > > > define-declaration: > > #define identifier > > #define identifier constant > > #define identifier ( constant-expression ) > > See below... > > > Here #define is no more preprocessor. > > The constant-expression can be evaluated and the value > > is used as a constant. (Like enum constant) > > > > Sample C' language with no preprocessor: > > > > #define DEBUG > > > > //This will not compile (missing ( ) ) > > //#define A 1 + 2 > > > > //This will compile > > #define A (1 + 2) > > If you make this a part of the language, then there is no need to insist > on parentheses. The idea is that if you have a valid code in C that works I want to copy-paste it to C' and get the same result. If #define X 1 + 2 was allowed, a big surprise would happen in the final result. Incompatibilities should be caught in compile time. -- One difference between #define and enuns, is that double types would be allowed. #define PI 3.1415
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-15 18:01 +0000 |
| Message-ID | <87a89nqqo0.fsf@bsb.me.uk> |
| In reply to | #103944 |
Thiago Adams <thiago.adams@gmail.com> writes: > On Wednesday, February 15, 2017 at 1:16:55 PM UTC-2, Ben Bacarisse wrote: >> Thiago Adams writes: <snip> >> > Some samples to make the idea clear: >> > I will allow empty define, constant or constant-expression with () >> > >> > C' Grammar: >> > >> > define-declaration: >> > #define identifier >> > #define identifier constant >> > #define identifier ( constant-expression ) >> >> See below... >> >> > Here #define is no more preprocessor. >> > The constant-expression can be evaluated and the value >> > is used as a constant. (Like enum constant) >> > >> > Sample C' language with no preprocessor: >> > >> > #define DEBUG >> > >> > //This will not compile (missing ( ) ) >> > //#define A 1 + 2 >> > >> > //This will compile >> > #define A (1 + 2) >> >> If you make this a part of the language, then there is no need to insist >> on parentheses. > > The idea is that if you have a valid code in C that works > I want to copy-paste it to C' and get the same result. > > If > #define X 1 + 2 > was allowed, a big surprise would happen in the final result. Right. But my point is that if you restrict #define to permit only certai forms, you can (and should) also restrict what it means. You can simple say that after #define X 1 + 2 X means (1 + 2). And then you notice don't need the special line oriented syntax and you can use a more comfortable syntax. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-15 18:25 +0000 |
| Message-ID | <o826an$3hp$1@dont-email.me> |
| In reply to | #103949 |
On 15/02/2017 18:01, Ben Bacarisse wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
> Right. But my point is that if you restrict #define to permit only
> certai forms, you can (and should) also restrict what it means. You can
> simple say that after
>
> #define X 1 + 2
>
> X means (1 + 2). And then you notice don't need the special line
> oriented syntax and you can use a more comfortable syntax.
That's the best part of the preprocessor, in that it is line-oriented
(no semicolons) and mandates consistent block delimiters (no {,} in a
dozen placement styles, or often none at all).
In that respect it's higher level than C.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-15 19:14 +0000 |
| Message-ID | <87zihnp8q1.fsf@bsb.me.uk> |
| In reply to | #103953 |
BartC <bc@freeuk.com> writes:
> On 15/02/2017 18:01, Ben Bacarisse wrote:
>> Thiago Adams <thiago.adams@gmail.com> writes:
>
>> Right. But my point is that if you restrict #define to permit only
>> certai forms, you can (and should) also restrict what it means. You can
>> simple say that after
>>
>> #define X 1 + 2
>>
>> X means (1 + 2). And then you notice don't need the special line
>> oriented syntax and you can use a more comfortable syntax.
>
> That's the best part of the preprocessor, in that it is line-oriented
> (no semicolons) and mandates consistent block delimiters (no {,} in a
> dozen placement styles, or often none at all).
You've become so tribal that you are prepared to argue against yourself!
I was echoing your thoughts -- that with a sufficiently restricted
#define you might as well have a "constant" definition.
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web