From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?iso-8859-1?Q?Vincent_Bela=EFche?= Newsgroups: gmane.emacs.devel Subject: DXL mode Date: Mon, 14 Feb 2011 23:05:09 +0100 Message-ID: <80k4h25l2i.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1297721125 7328 80.91.229.12 (14 Feb 2011 22:05:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 14 Feb 2011 22:05:25 +0000 (UTC) Cc: =?iso-8859-1?Q?Vincent_Bela=EFche?= To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 14 23:05:21 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Pp6Xn-0001Af-Vz for ged-emacs-devel@m.gmane.org; Mon, 14 Feb 2011 23:05:20 +0100 Original-Received: from localhost ([127.0.0.1]:40829 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pp6Xn-0002Yx-9t for ged-emacs-devel@m.gmane.org; Mon, 14 Feb 2011 17:05:19 -0500 Original-Received: from [140.186.70.92] (port=42425 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pp6Xi-0002Vw-Na for emacs-devel@gnu.org; Mon, 14 Feb 2011 17:05:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pp6Xh-0004C3-HQ for emacs-devel@gnu.org; Mon, 14 Feb 2011 17:05:14 -0500 Original-Received: from smtp07.smtpout.orange.fr ([80.12.242.129]:40551 helo=smtp.smtpout.orange.fr) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pp6Xh-0004Bz-82 for emacs-devel@gnu.org; Mon, 14 Feb 2011 17:05:13 -0500 Original-Received: from CHOUNEK ([92.139.230.211]) by mwinf5d14 with ME id 7y5B1g0044aJoCC03y5Bhq; Mon, 14 Feb 2011 23:05:12 +0100 X-Antivirus: avast! (VPS 110214-0, 14/02/2011), Outbound message X-Antivirus-Status: Clean X-detected-operating-system: by eggs.gnu.org: Linux 2.6? (barebone, rare!) X-Received-From: 80.12.242.129 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:136026 Archived-At: Dear all, I could not find any edit mode for DXL, if this does not exist, I will probably create one. I am wondering what is the best way to start from. DXL is Doors(TM) eXtension Language. Doors is a data base system used in the industry to write specifications with easier requirement management. DXL looks like C to many aspects, and I thought that it may be a good idea to add one more C dialects to the list in the cc-mode package. However by some other aspects its syntax can be made quite different.=20 This is why I am seeking guidance on this forum before starting anything. Currently I am using the C mode to write DXL code, which obliges me to write it as much in a C-like manner (for instance I need to end all statements by a semi-colon), but I would like to get rid of these constraints, and have some programming mode that would indent correctly any kind of DXL code. The main differences from C syntaxe are the following ones: Predefined types ---------------- you don't have any `float' or `double' or `long int', but there are a number of predefined types like `bool', `int', `real', `string', `Array', `Skip', `Link', `Object', etc... Qualidiers ---------- the only one is `const', and AFAIK it must be always in the first position: const int i =3D 3 // OK int const i =3D 3 // not OK End of statements ----------------- In DXL statements do not need a tailing semi-colon, an end-of-line is sufficient. You may have several statements in a line provided that they are separated by a semi-colon, and statements can also span over several lines: the DXL interprete detects that an end-of-line does not terminate a statement if one of the following two conditions is fulfilled: + the line is ended by an empty comment `//', or by a comment with a tailing `-' like `// blah blah -' + the statement would otherwise contain some incomplete construct (e.g. opening bracket that is not closed, or stuff like that) Ranges ------ there is a range construct like this `FROM : TO by STEP' or `FROM : TO' Functions --------- Function calls do not need necessarilly brackets, the 3 following expression give the same result: real f0 =3D sqrt 2 // naked real f1 =3D sqrt(2) // =E0 la C real f3 =3D (sqrt 2) // =E0 la Lisp The brackets are needed when there are more than one argument, so you cannot always write things =E0-la-Lisp. Personnally when a function call with a single argument is within an expression I prefer the =E0-la-Lisp way to avoid any precedence issues, but when it is the rightwing of a `=3D', then I let it naked. An example why I prefer to do this way is for instance 1: string a=3D"xxx" 2: print length(a) "!" "\n" 3: print (length a) "!\n" =3D=3D> 4 =3D=3D> 3! On the second row you take the length of `a' concatenated with `"!"', so it makes `4' which is then stringized and concatenated with `"\n"'. This is quite confusing if written this way. Special construct ----------------- you have this: for ... in ... do ...=20 and also=20 if ... then ... is possible in addition to if ... { ... } in the case that the expression following `if' does not start with a `(' ----------------------------------------------------------------------- I am seeking guidance, based on the preceding information, on whether I would meet any dead-end issues if I try to add a C dialect to cc-mode (like awk which also does not always need ending semi-colons), or if it seems feasible with a reasonable effort. If adding a dialect to cc-mode is not the good way, then I would rather re-start from scratch by reworking some simple existing mode, like the visual-basic-mode which is the one I know best. VBR, Vincent. =20=20 =20