I appreciate you taking the time to respond to my message.  Keeping the DRS of the grammar rules as simple as possible will definitely make my work easier.  I will focus on this.  The tip about using the phrase &quot;there is a n:conditions-definition C&quot; instead of &quot;C is a n:conditions-definition&quot; is something I will also keep in mind.<br>
<br>Using a sentence-external marker and using &quot;is&quot; instead of &quot;must be&quot; makes a lot of sense.  I believe in keeping things as simple as possible (the KISS principle).  As you say, this approach may also make things simpler and more obvious for the reader.  In the beginning I can simply keep the different kinds of statements in different files, each with a file extension that indicates how it should be interpreted.  This is great advice.  At a later time, if I feel it might be useful, I can experiment with trying to integrate the different sentence types into a single coherent multi-paradigm language with modules that contain mixed sentence types.<br>
<br>Any more tips/guidance you can think of will be greatly appreciated.<br><br>-- Ken<br><br><div class="gmail_quote">On Sat, Jan 2, 2010 at 10:46 AM, Norbert E. Fuchs <span dir="ltr">&lt;<a href="mailto:fuchs@ifi.uzh.ch">fuchs@ifi.uzh.ch</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
On 2 Jan 2010, at 04:40, Kenneth Jones wrote:<br>
<br>
&gt; ...<br>
<div class="im">&gt;<br>
&gt; I guess it&#39;s obvious that I&#39;m am trying to write a DRS parser in ACE.  I then want to add a back end that generates code (initially Java code).<br>
<br>
</div>I thought so and this guided me when I rephrased your sentence.<br>
<br>
May I suggest that when writing the DRS parser you keep in mind how to simply get from the DRS derived from your grammar rules to the Java code. The more verbose your grammar rules are – for instance writing &quot;C is a n:conditions-definition&quot; instead of  &quot;there is a n:conditions-definition C&quot; – the more work you have to do to get from the DRS to the Java code.<br>

<div class="im"><br>
&gt; The reason for using &quot;must be&quot; instead of &quot;is a&quot; near the end of the sentence is that I am trying to generate code from specifications that are written as statements of necessity rather than assertions or statements of facts.  In the end I want to be able to create a multi-paradigm language that uses statements of necessity to express requirements that are translated to imperative code, assertions to express business rules, constraints, pre-conditions, post-conditions, and tests in a declarative manner, and facts to express data.<br>

<br>
</div>Do I understand you correctly that you indicate the interpretation of your ACE sentences as code, or rule, or ...  by the verb form, i.e. by a sentence-internal marker? Wouldn&#39;t some sentence-external marker – for instance grouping your sentences according to their target representations –  be simpler and more obvious for the reader? Furthermore, using &quot;is&quot; instead of &quot;must be&quot; again simplifies the transformation DRS -&gt; Java.<br>

<br>
Regards.<br>
<font color="#888888"><br>
   --- nef<br>
<br>
</font></blockquote></div><br>