<p dir="ltr"></p>
<p dir="ltr">Sony Xperia™ okostelefonomról küldve</p>
<br><br>---- Eredeti üzenet ----<br>Tárgy: Re: [P4-design] C preprocessor requirement<br>Küldve: 2016.07.08. 5:25<br>Feladó: Javier Blazquez <jblazquez@riotgames.com><br>Címzett: Mihai Budiu <mbudiu@vmware.com><br>Másolatot kap: p4-design@lists.p4.org<br><br><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr">I think using cpp in p4c for expediency reasons makes a lot of sense. I would have done that too. However, thinking about source code analysis tools and the ideal choice for the language itself makes a requirement for a C preprocessor somewhat troublesome in my opinion.<div><br></div><div>In general I think the language should have the least amount of surprising behaviors as possible. You say include guards are well understood, and that's probably true for programmers with a C/C++ background, but I would expect someone with background in just, say, Python or Go to be surprised by the unintended consequences of including a given file twice. Not that they couldn't quickly learn how they work and start adding those guards, but it seems like an unnecessary burden (if small).</div><div><br></div><div>But even with the current limited supported subset of the C preprocessor you can still do some problematic things, whether intentionally or by mistake. For example, code in an included file would be affected by the current state of defines at the point of inclusion, so a piece of code in a given source file can change depending on where exactly it's included. This is a nightmare for source analysis tools and IDEs which now have to take into account all the possible contexts under which a given file is included. Also you can shoot yourself in the foot if you #define something right before an #include but it doesn't actually take effect because the included file is guarded and it was already included before (cue everyone who ever tried to define _GNU_SOURCE in code before including a system header).</div><div><br></div><div>Yes, I was proposing that the #include directive would behave as if the included source file had an implicit #pragma once directive. Perhaps the name #import would make more sense because it would match the Objective-C directive that has the same implicit guarding behavior. And I agree that #line directives would be useful, so it would make sense to support them.</div><div><br></div><div>Since you mentioned concrete fixes to the spec I went ahead and opened an issue on GitHub with my proposed wording:</div><div><br></div><div><a href="https://github.com/p4lang/p4-spec/issues/30">https://github.com/p4lang/p4-spec/issues/30</a><br></div><div><br></div><div>I did it on GitHub to have better formatting and for nicer tracking, but let me know if you think discussion should remain here.</div><div><br></div><div>I'm going to take a look at the reference compiler to see how hard the changes would be.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 7, 2016 at 4:35 PM, Mihai Budiu <span dir="ltr"><<a href="mailto:mbudiu@vmware.com" target="_blank">mbudiu@vmware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Thank you for your comments.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">The P4 preprocessor requirements are actually inspired by the C# preprocessor design. We want to make it easier to write multi-file programs while precluding
 one from using macros for writing incomprehensible programs.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">You are correct, the P4-16 spec should not mandate the usage of the C preprocessor. What the spec should do is to describe the preprocessor language supported
 by P4-16. <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Practically speaking, we have designed the P4 preprocessor language to be exactly a subset of the C preprocessor language, and in fact the P4-16 reference compiler
 implementation does invoke cpp. <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">There are two reasons we are using cpp:<u></u><u></u></span></p>
<p><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><span>-<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:"Times New Roman"">         
</span></span></span><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">For expediency; writing a preprocessor is actually a significant task. The most important piece of functionality we need is indeed the #include.<u></u><u></u></span></p>
<p><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><span>-<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:"Times New Roman"">         
</span></span></span><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">To allow P4 programs to be generated by other tools; the #line directives are the most useful in this case. We expect that P4 will be used as a target
 language in a significant number of applications, where P4 programs are generated by tools from higher-level specifications.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Regarding #include guards, this is a tricky problem. They are relatively ugly, but people understand how they work. We could use something like #pragma once,
 but this would preclude us from using cpp implementations which do not support it. Are you suggesting that “#pragma once” should be implied for any P4 source file?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Conditional compilation is a feature which could be very useful for maintaining complex programs built out of independent parts which can be configured independently.
 For example, switch.p4 <a href="https://github.com/p4lang/switch" target="_blank">https://github.com/p4lang/switch</a> has a p4features.h file which can be used to enable/disable features. (To some degree the same effect can be achieved using pure P4-16 constructs; the proper
 language support – if any – for modular P4 program construction is probably a subject for a future language revision.)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">We would welcome contributions to the p4-16 compiler reference implementation, including a new preprocessor. Also, if you can suggest concrete improvements to
 the preprocessor language, this is the right place to do it. Concrete fixes to the spec are welcome as well.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Mihai Budiu<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif"> P4-design [mailto:<a href="mailto:p4-design-bounces@lists.p4.org" target="_blank">p4-design-bounces@lists.p4.org</a>]
<b>On Behalf Of </b>Javier Blazquez<br>
<b>Sent:</b> Thursday, July 7, 2016 3:46 PM<br>
<b>To:</b> <a href="mailto:p4-design@lists.p4.org" target="_blank">p4-design@lists.p4.org</a><br>
<b>Subject:</b> [P4-design] C preprocessor requirement<u></u><u></u></span></p><div><div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Hello all,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I'm new to the group. Looking forward to virtually meeting all of you.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I just finished reading through the latest P4-16 spec and the p4-design mailing list archives. There is a five-month gap in the archives from Sep 2015 to Jan 2016 so apologies if I missed some important discussions that happened back then.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I'm very excited about the upcoming version of the language and the possibilities it opens for writing more expressible data plane programs. I particularly like the idea of greater modularity and the language-architecture separation, and
 I think the new spec is a great step towards those goals. I somewhat miss the beautiful declarative simplicity of the original P4-14 grammar but I understand that some additional complexity is unavoidable when broadening the language.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">My background is in software engineering so I'm approaching this from more of a tooling standpoint (compilers, analysis tools, IDE integration, etc) and thus one of the things that caught my attention was the requirement for (limited) C
 preprocessor support in the current spec.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The spec is careful in its wording of the "8.2 Preprocessing" section so as not to say that source files must literally be passed through a C preprocessor, but I think that's effectively what's implied right now.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">As far as I understand, the C preprocessor has the following potential uses within the context of P4:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">1. Including other source files.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">2. Conditional compilation of blocks of code.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">3. Defining constants.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">4. Mapping preprocessed source locations back to original code locations.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Other features of the preprocessor such as function macros, stringification, concatenation, etc, seem much less useful for P4 programs. You probably wouldn't want to use the Boost preprocessor in your data plane program.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Going through that list backwards:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">4. Mapping preprocessed source locations back to original code locations.<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">If there were no preprocessing requirement then the compiler wouldn't need to have a mapping back to the original code via #line directives, because it would be working with the original code directly.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">3. Defining constants.<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I don't think there's a need for using #define for constants in P4-16 given the new const keyword.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">2. Conditional compilation of blocks of code.<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">This is an important concern and I think the well-known #if/#elif/#endif directives are the best tool for the job, but you could support these directives directly in the compiler without relying on the preprocessor. That's what the C# compiler
 does, for example.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Supporting these in the compiler itself would make these blocks of code part of the actual AST, which would help with source code analysis and manipulation (e.g. refactoring).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">1. Including other source files.<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">This is the canonical example for the need for a preprocessor. Clearly dividing your code into different source files is important for many reasons, but the classic C #include directive brings some baggage with it that I think is undesirable
 in a modern language.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">My main concern is with the need for include guards[1] to prevent duplicate definitions. Modern languages provide more refined import mechanisms that prevent these problems, so I'm wondering what people's thoughts are regarding whether
 P4-16 should have a better source code inclusion system. Right now the spec doesn't define the semantics of #include and delegates to the C preprocessor definition, which has the unfortunate side effect of requiring P4 programs to use include guards.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Can we remove the need for a C preprocessor while still satisfying the uses cases above? I think we could if we made the compiler natively understand the following directives:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">- #define (for defining macros without arguments only)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">- #undef<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">- #if/#elif/#else/#endif (with simple expression support for testing defined macros)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">- #include "path/to/file.p4" (with implicit include guards)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">[1] <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_p4lang_p4-2Dspec_blob_master_p4-2D16_discussions_stdlib.p4-23L1-2D2&d=CwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=OGtcVSZ8_eIEhhYxtGXM8u910CQ0CqIhsSlILEAx_Tw&m=R-hLzyEt_zWNI1yuZuUZnzQ1ib9KBsKzkIZiacPPI7Q&s=TnJPY8DKS-oDWB4qqJ4xWP16dRoJ8JbqwdcKoFQnLes&e=" target="_blank">https://github.com/p4lang/p4-spec/blob/master/p4-16/discussions/stdlib.p4#L1-2</a><u></u><u></u></p>
</div>
</div>
</div></div></div>
</div>

</blockquote></div><br></div></div>