From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?iso-8859-1?B?VmluY2VudCBCZWxh72NoZQ==?= Newsgroups: gmane.emacs.devel Subject: RE: progmodes cc: addition of builtin def-const Date: Sat, 22 Dec 2012 23:15:54 +0100 Message-ID: References: <80boeaaor1.fsf@gmail.com>,<20121219201703.GA3618@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_89a055b8-fb0e-4449-b877-4779070e8d02_" X-Trace: ger.gmane.org 1356214583 4894 80.91.229.3 (22 Dec 2012 22:16:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Dec 2012 22:16:23 +0000 (UTC) Cc: bug-cc-mode@gnu.org, emacs-devel To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 22 23:16:38 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TmXMr-0004Ly-5w for ged-emacs-devel@m.gmane.org; Sat, 22 Dec 2012 23:16:29 +0100 Original-Received: from localhost ([::1]:52474 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TmXMd-0001Cv-4t for ged-emacs-devel@m.gmane.org; Sat, 22 Dec 2012 17:16:15 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:36258) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TmXMT-0001CZ-Lg for emacs-devel@gnu.org; Sat, 22 Dec 2012 17:16:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TmXML-0001vH-GI for emacs-devel@gnu.org; Sat, 22 Dec 2012 17:16:05 -0500 Original-Received: from dub0-omc3-s1.dub0.hotmail.com ([157.55.2.10]:34604) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TmXML-0001si-0N for emacs-devel@gnu.org; Sat, 22 Dec 2012 17:15:57 -0500 Original-Received: from DUB102-W37 ([157.55.2.8]) by dub0-omc3-s1.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 22 Dec 2012 14:15:55 -0800 X-EIP: [jaXXEU3JrutY/1SqDKFXbX3WaUSQPbSC] X-Originating-Email: [vincent.b.1@hotmail.fr] Importance: Normal In-Reply-To: <20121219201703.GA3618@acm.acm> X-OriginalArrivalTime: 22 Dec 2012 22:15:55.0194 (UTC) FILETIME=[E94279A0:01CDE091] X-detected-operating-system: by eggs.gnu.org: Windows XP X-Received-From: 157.55.2.10 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:155785 Archived-At: --_89a055b8-fb0e-4449-b877-4779070e8d02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Alan=2C Thank you for the feedback.=20 [...]>=20 > As a matter of interest=2C what is DXL? All I found on the web was a > language based on XML=2C not C-like at all. >=20 DXL stands for "Doors Extension Language". Doors is a non free data base sy= stem for requirement handling. DXL allows to extend the client for instance= to generate some report=2C to query for some requirements=2C to build some= view of the data base=2C to do some export or some import. All these exten= sions can be coded in DXL. There already quite many such stuff bundled with= Doors and source if not free is open. Here is a DXL manual: http://publib.boulder.ibm.com/infocenter/rsdp/v1r0m0/= topic/com.ibm.help.download.doors.doc/pdf/dxl_reference_manual.pdf I think that Doors was made historically by some company as a standalone t= ool and this was then bought by Telelogic to be part of their versioning | = issue management | requirement management suite. Then Telelogic was bought = by its competitor IBM who offered similar tools like rational rose=2C etc..= . Currently Doors is used in the industry as some sort of de facto standard= --- I know several other alternatives to handle requirements=2C but Doors = seems to me the most advanced tool to do that (mainly because it is so open= thanks to DXL). Probably Doors & DXL are unknown to many people because wh= at industry I am talking about is quite HW oriented: when you build things = that you cannot update easily by some SW upgrade=2C then requirement manage= ment becomes a job of its own. DXL makes it easy to script=2C although you really have to get some knack o= f it before you can use it. For instance --- as far as I remember: int i =3D 3print "i=3D" i won't work=2C you have to write int i =3D 3print "i=3D" (i "") because there is an overload of the concatenation operation (space=2C repre= sented by `..' below) with this prototype string ::.. (int i=2C string x)but not with that one string ::.. ( string x =2C int i)=20 I understand that you may feel not very enthusiastic about allowing some ex= tension for some proprietary language --- in fact neither I am ! This DXL m= ode is just a somehow quick hack which I did during working hours=2C withou= t spending very significant time on it --- in fact I was not even supposed = to do that=2C but I did it because I needed to make some scripts and I esti= mated that overall the time to make this dxl-mode hack was less than the ti= me saved by using an advanced editor like EMACS + c progmode like features= =2C and I was not wishing to learn advanced feature if any of some other ed= itor like UltraEdit or Sodius (the latter anyway was not available to me).= =20 Having said that=2C I am a bit unsure what this dxl-mode.el hack which I di= d is to become. I don't think I am allowed to disclose it without prior agr= eement of my hierarchy=2C and I am unsure whether there is really public in= terest in it. As far as I am concerned despite all its limitations it is us= able enough for the amount of DXL I need to write. Please note that DXL=2C although it looks like C code has some unique synta= x aspects- multiline strings are allowed- instruction tailing semi colon ca= n be omitted when they can be inferred from context --- a bit like in AWK= =2C but somehow more subtile- it has some specific control construct: - in= addition to `if (SOME_CONDITION) { THEN_STATEMENTS }' you can write `i= f SOME_CONDITION then { THEN_STATEMENTS }' - you have some `for SOME_VAR = in SOME_SET do { LOOP_STATEMENTS }' construct- typing is quite important=2C and you can overload functions = based on prototype --- to that extent=20 > > On the other hand DXL is more typed than AWK=2C so the 3 level > > fontification of cc-fonts.el is better to use than do a specific > > fontification like in AWK mode. >=20 > OK. >=20 > > In order to achieve this goal of reusing cc-fonts=2C I propose the > > addition of a new lang constant c-builtin-kwds. This allows the > > dxl-mode.el which I am elaborating to plug more readily on EMACS CC > > progmode. >=20 > > If nobody objects I would commit the change the patch thereof is herein > > attached. >=20 > My first reaction was negative - do we really want extensive use of > c-preprocessor-face-name for builtin functions? I know AWK Mode does > precisely this=2C but is it a good thing to encourage? >=20 Well some of the functions are in my opinion more part of the language than= library function. For instance --- in the code below I would like that `cr= eate'=2C `put' and `null' in builtin font (like preprocessor)=2C and delete= in keyword font (like `if').=20 Array my_array =3D create(3=2C1)// that is put(dest=2C src=2C pos_x=2C pos_= y)=2C awfull to state src // before pos=2C but that is the syntax.put(my_ar= ray =2C"element (0=2C0)" =2C0=2C0) put(my_array =2C3.0 =2C1=2C0)put(my_array =2C4 =2C2=2C0)=20 string s =3D get(my_array=2C0=2C0) real x =3D get(my_array=2C1=2C0) int i = =3D get(my_array=2C2=2C0) if !(null my_array) then{ delete my_array my_array =3D null } This font choice is because function Array create(int=2C int) is one of the many overloads of builtin function create. While delete is ra= ther a language keyword=2C as it can act on any dynamically allocated thing= . > Then=2C on the other hand=2C the new code does nothing which isn't alread= y > inside CC Mode. >=20 > To answer my own question=2C I don't feel we really should encourage this > use of c-preprocessor-face-name. As a matter of interest=2C have you tri= ed > using font-lock-add-keywords to get the new keywords fontified? If so=2C > how easy/neat is it to do this? Could you try to persuade me a new > general facility is better than a one-off for DXL Mode? >=20 I have not tried this=2C I was not aware that this function existed. Maybe = that can completely remove the need for the patch. > There were one or two little things about the patch which weren't quite > optimal=2C see below. >=20 Ok I also inserted replies below. > > VBR=2C > > Vincent. >=20 >=20 > > =3D=3D=3D modified file 'lisp/ChangeLog' > > --- lisp/ChangeLog 2012-12-03 17:23:42 +0000 > > +++ lisp/ChangeLog 2012-12-03 19:55:20 +0000 > > @@ -1=2C3 +1=2C12 @@ > > +2012-12-03 Vincent Bela=C3=AFche > > + > > + * progmodes/cc-fonts.el (c-basic-matchers-before): Use new lang > > + constant `c-builtin-kwds' for handling language specific keyword > > + fontification. > > + > > + * progmodes/cc-langs.el (c-builtin-kwds): New lang constant for > > + handling language specific keyword fontification. > > + > > 2012-12-03 Agust=C3=ADn Mart=C3=ADn Domingo >=20 > > * textmodes/ispell.el (ispell-init-process) >=20 > > =3D=3D=3D modified file 'lisp/progmodes/cc-langs.el' > > --- lisp/progmodes/cc-langs.el 2012-09-13 18:41:21 +0000 > > +++ lisp/progmodes/cc-langs.el 2012-12-03 17:24:59 +0000 > > @@ -649=2C6 +649=2C15 @@ > > (prefix "::") > > (left-assoc "."))) >=20 > > +(c-lang-defconst c-builtin-kwds > > + "Keywords for builtin keywords constants." > > + =3B=3B This is for functions that are not part of a library but buil= tin in the > > + =3B=3B language. AWK mode does not use this constant but could have = done > > + =3B=3B so. Currently this is used only as a hook for languages not y= es part of > > + =3B=3B cc-xxx progmode=2C like DXL. > > + t nil > > + ) > > + > > (c-lang-defconst c-opt-identifier-concat-key > > =3B=3B Appendable adorned regexp matching the operators that join > > =3B=3B symbols to fully qualified identifiers=2C or nil in languages= that >=20 > c-builtin-kwds really needs a fuller doc string=2C since unlike > c-constant-kwds=2C it doesn't have examples to guide other hackers in its > use. The comment is really too vague - nowhere does it say what is done > with the supplied functions. I don't think the offhand remark about AWK > is really helpful. Something like the following would be better: >=20 > "A list of keywords which will get fontified with c-preprocessor-face-nam= e." > =3B=3B This is intended for built-in function names in modes derived from= CC > =3B=3B Mode. >=20 I agree. > > =3D=3D=3D modified file 'lisp/progmodes/cc-fonts.el' > > --- lisp/progmodes/cc-fonts.el 2012-01-19 07:21:25 +0000 > > +++ lisp/progmodes/cc-fonts.el 2012-12-03 17:26:28 +0000 > > @@ -763=2C6 +763=2C12 @@ > > `((eval . (list =2C(concat "\\<\\(" re "\\)\\>") > > 1 c-constant-face-name)))))) >=20 > > + =3B=3B Fontify builtins keyword constants. > > + =2C@(when (c-lang-const c-builtin-kwds) > > + (let ((re (c-make-keywords-re nil (c-lang-const c-builtin-kwds)))) > > + `((eval . (list =2C(concat "\\<\\(" re "\\)\\>") > > + 1 c-preprocessor-face-name))))) > > + > > =3B=3B Fontify all keywords except the primitive types. > > =2C(if (c-major-mode-is 'pike-mode) > > =3B=3B No symbol is a keyword after "->" in Pike. >=20 > But as I said=2C I'm not quite convinced that the general facility you've > implemented is a good idea=2C as compared with each mode (how many are > therre?) which needs it implementing it specially. What is your feeling > about how many derived modes would benefit from it? >=20 Well=2C I suspect that all script languages with C-like syntax are candidat= es. AWK could be modified to use the feature. CSH shell could be another c= andidate. bc (arbitrary precision math script language) could also be anoth= er candidate. Like DXL these two languages have specific constructs (e.g. d= efine in bc) and they do probably need some more hooks in cc to make it. BT= W=2C my dxl-mode.el does not handle so properly the if ... then and for ..= in .. do constructs. Frankly speaking=2C I use neither csh (only bash is ported on msw) nor bc (= I do my maths with EMACS calc or scilab depending on what I need to do)=2C = so these are only just those which came to my mind.=20 Basically I am quite convinced that functions like put or create that come = with Array or Skip in DXL should be in builtin font=2C because these are re= ally things you could hardly implement in DXL if they were not provided wit= h it --- well in fact that would be possible to do it like DxlObject's=2C b= ut certainly would lose too much in performance .=20 > --=20 > Alan Mackenzie (Nuremberg=2C Germany). >=20 Vincent Bela=EFche (Rennes=2C France) = --_89a055b8-fb0e-4449-b877-4779070e8d02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Alan=2C

Thank you for the feedback. =3B
[...]
=
>=3B =3B
>=3B As a matter of interest=2C what is DXL? All = I found on the web was a
>=3B language based on XML=2C not C-like at a= ll.
>=3B

DXL stands for "Doors Extension Language". Doors is a non = free data base system for requirement handling. DXL allows to extend the cl= ient for instance to generate some report=2C to query for some requirements= =2C to build some view of the data base=2C to do some export or some import= . All these extensions can be coded in DXL. There already quite many such s= tuff bundled with Doors and source if not free is open.

Here is a DXL manual: http://publib.boulder.i= bm.com/infocenter/rsdp/v1r0m0/topic/com.ibm.help.download.doors.doc/pdf/dxl= _reference_manual.pdf


I think that Doors was = made historically by some company as  =3Ba standalone tool and this was= then bought by Telelogic to be part of their versioning | issue management= | requirement management suite. Then Telelogic was bought by its competito= r IBM who offered similar tools like rational rose=2C etc... Currently Door= s is used in the industry as some sort of de facto standard --- I know seve= ral other alternatives to handle requirements=2C but Doors seems to me the = most advanced tool to do that (mainly because it is so open thanks to DXL).= Probably Doors &=3B DXL are unknown to many people because what industr= y I am talking about is quite HW oriented: when you build things that you c= annot update easily by some SW upgrade=2C then requirement management becom= es a job of its own.

DXL m= akes it easy to script=2C although you really have to get some knack of it = before you can use it.

For= instance --- as far as I remember:

int i =3D 3
print "i=3D" i

won't work=2C you have to write

int i =3D 3
print "i=3D" (i "")

because there is an overload o= f the concatenation operation (space=2C represented by `..' below) with thi= s prototype

string ::.. (i= nt i=2C string x)
but not with that one

string ::.. ( string x =2C int i) =3B


I u= nderstand that you may feel not very enthusiastic about allowing some exten= sion for some proprietary language --- in fact neither I am ! This DXL mode= is just a somehow quick hack which I did during working hours=2C without s= pending very significant time on it --- in fact I was not even supposed to = do that=2C but I did it because I needed to make some scripts and I estimat= ed that overall the time to make this dxl-mode hack was less than the time = saved by using an advanced editor like EMACS + c progmode like features=2C = and I was not wishing to learn advanced feature if any of some other editor= like UltraEdit or Sodius (the latter anyway was not available to me). = =3B

Having said that=2C I = am a bit unsure what this dxl-mode.el hack which I did is to become. I don'= t think I am allowed to disclose it without prior agreement of my hierarchy= =2C and I am unsure whether there is really public interest in it. As far a= s I am concerned despite all its limitations it is usable enough for the am= ount of DXL I need to write.

Please note that DXL=2C although it looks like C code has some unique sy= ntax aspects
- multiline strings are allowed
- instruction tailing semi colon can be omitted when they can= be inferred from context --- a bit like in AWK=2C but somehow more subtile=
- it has some specific control construct:
 =3B - in addition to `if (SOME_CONDITION) { THEN_STATEMENT= S }' you can write
 =3B  =3B =3B `if SOME= _CONDITION then { THEN_STATEMENTS }' =3B
 =3B= - you have some `for SOME_VAR in SOME_SET do {  =3BLOOP_STATEMENTS  =3B}' construct
- typing is quite important=2C a= nd you can overload functions based on prototype --- to that extent =3B=

>=3B >=3B On the other hand DXL is more type= d than AWK=2C so the 3 level
>=3B >=3B fontification of cc-fonts.el = is better to use than do a specific
>=3B >=3B fontification like in = AWK mode.
>=3B
>=3B OK.
>=3B
>=3B >=3B In order to = achieve this goal of reusing cc-fonts=2C I propose the
>=3B >=3B add= ition of a new lang constant c-builtin-kwds. This allows the
>=3B >= =3B dxl-mode.el which I am elaborating to plug more readily on EMACS CC
= >=3B >=3B progmode.
>=3B
>=3B >=3B If nobody objects I wou= ld commit the change the patch thereof is herein
>=3B >=3B attached.=
>=3B
>=3B My first reaction was negative - do we really want ex= tensive use of
>=3B c-preprocessor-face-name for builtin functions? I= know AWK Mode does
>=3B precisely this=2C but is it a good thing to e= ncourage?
>=3B

Well some of the functi= ons are in my opinion more part of the language than library function. For = instance --- in the code below I would like that `create'=2C `put' and `nul= l' in builtin font (like preprocessor)=2C and delete in keyword font (like = `if'). =3B

Array my_array =3D create(3=2C1)
// that is put(dest=2C src=2C pos_x=2C pos_y)=2C awfull to state sr= c
// before pos=2C but that is the syntax.
put(my_arra= y =2C"element (0=2C0)" =2C0=2C0)
put(my_array =2C3.0 =2C1=2C0)
put(my_array =2C4 =2C2=2C0) =3B

string s =3D get(my_array=2C0=2C= 0) =3B
real x =3D get(my_array=2C1=2C0) =3B
int= i =3D get(my_array=2C2=2C0)

if !(null my_array) t= hen
{
 =3B delete my_array
 =3B my_ar= ray =3D null =3B
}

This font choice = is because function

 =3BArray create(int=2C in= t)

is one of the many overloads of builtin functio= n create. While delete is rather a language keyword=2C as it can act on any= dynamically allocated thing.

>=3B Then=2C on the other han= d=2C the new code does nothing which isn't already
>=3B inside CC Mode= .
>=3B
>=3B To answer my own question=2C I don't feel we really = should encourage this
>=3B use of c-preprocessor-face-name. As a matt= er of interest=2C have you tried
>=3B using font-lock-add-keywords to = get the new keywords fontified? If so=2C
>=3B how easy/neat is it to = do this? Could you try to persuade me a new
>=3B general facility is = better than a one-off for DXL Mode?
>=3B

I h= ave not tried this=2C I was not aware that this function existed. Maybe tha= t can completely remove the need for the patch.

>=3B There = were one or two little things about the patch which weren't quite
>=3B= optimal=2C see below.
>=3B

Ok I also insert= ed replies below.

>=3B >=3B VBR=2C
>=3B >=3B = Vincent.
>=3B
>=3B
>=3B >=3B =3D=3D=3D modified file 'l= isp/ChangeLog'
>=3B >=3B --- lisp/ChangeLog 2012-12-03 17:23:42 +000= 0
>=3B >=3B +++ lisp/ChangeLog 2012-12-03 19:55:20 +0000
>=3B &= gt=3B @@ -1=2C3 +1=2C12 @@
>=3B >=3B +2012-12-03 Vincent Bela=C3=AF= che <=3Bvincentb1@users.sourceforge.net>=3B
>=3B >=3B +
>= =3B >=3B + * progmodes/cc-fonts.el (c-basic-matchers-before): Use new lan= g
>=3B >=3B + constant `c-builtin-kwds' for handling language specif= ic keyword
>=3B >=3B + fontification.
>=3B >=3B +
>=3B &= gt=3B + * progmodes/cc-langs.el (c-builtin-kwds): New lang constant for
= >=3B >=3B + handling language specific keyword fontification.
>=3B= >=3B +
>=3B >=3B 2012-12-03 Agust=C3=ADn Mart=C3=ADn Domingo &= lt=3Bagustin.martin@hispalinux.es>=3B
>=3B
>=3B >=3B * tex= tmodes/ispell.el (ispell-init-process)
>=3B
>=3B >=3B =3D=3D= =3D modified file 'lisp/progmodes/cc-langs.el'
>=3B >=3B --- lisp/pr= ogmodes/cc-langs.el 2012-09-13 18:41:21 +0000
>=3B >=3B +++ lisp/pro= gmodes/cc-langs.el 2012-12-03 17:24:59 +0000
>=3B >=3B @@ -649=2C6 += 649=2C15 @@
>=3B >=3B (prefix "::")
>=3B >=3B (left-ass= oc ".")))
>=3B
>=3B >=3B +(c-lang-defconst c-builtin-kwds
&= gt=3B >=3B + "Keywords for builtin keywords constants."
>=3B >=3B= + =3B=3B This is for functions that are not part of a library but builtin= in the
>=3B >=3B + =3B=3B language. AWK mode does not use this con= stant but could have done
>=3B >=3B + =3B=3B so. Currently this is = used only as a hook for languages not yes part of
>=3B >=3B + =3B= =3B cc-xxx progmode=2C like DXL.
>=3B >=3B + t nil
>=3B = >=3B + )
>=3B >=3B +
>=3B >=3B (c-lang-defconst c-opt-ide= ntifier-concat-key
>=3B >=3B =3B=3B Appendable adorned regexp mat= ching the operators that join
>=3B >=3B =3B=3B symbols to fully q= ualified identifiers=2C or nil in languages that
>=3B
>=3B c-bui= ltin-kwds really needs a fuller doc string=2C since unlike
>=3B c-cons= tant-kwds=2C it doesn't have examples to guide other hackers in its
>= =3B use. The comment is really too vague - nowhere does it say what is don= e
>=3B with the supplied functions. I don't think the offhand remark = about AWK
>=3B is really helpful. Something like the following would = be better:
>=3B
>=3B "A list of keywords which will get fontifie= d with c-preprocessor-face-name."
>=3B =3B=3B This is intended for bui= lt-in function names in modes derived from CC
>=3B =3B=3B Mode.
>= =3B

I agree.

>=3B >=3B =3D=3D= =3D modified file 'lisp/progmodes/cc-fonts.el'
>=3B >=3B --- lisp/pr= ogmodes/cc-fonts.el 2012-01-19 07:21:25 +0000
>=3B >=3B +++ lisp/pro= gmodes/cc-fonts.el 2012-12-03 17:26:28 +0000
>=3B >=3B @@ -763=2C6 += 763=2C12 @@
>=3B >=3B `((eval . (list =2C(concat "\\<=3B\\= (" re "\\)\\>=3B")
>=3B >=3B 1 c-constant-face-name)))))= )
>=3B
>=3B >=3B + =3B=3B Fontify builtins keyword consta= nts.
>=3B >=3B + =2C@(when (c-lang-const c-builtin-kwds)
>= =3B >=3B + (let ((re (c-make-keywords-re nil (c-lang-const c-builtin-kw= ds))))
>=3B >=3B + `((eval . (list =2C(concat "\\<=3B\\(" re= "\\)\\>=3B")
>=3B >=3B + 1 c-preprocessor-face-name)))))<= br>>=3B >=3B +
>=3B >=3B =3B=3B Fontify all keywords exce= pt the primitive types.
>=3B >=3B =2C(if (c-major-mode-is 'pi= ke-mode)
>=3B >=3B =3B=3B No symbol is a keyword after "->=3B= " in Pike.
>=3B
>=3B But as I said=2C I'm not quite convinced th= at the general facility you've
>=3B implemented is a good idea=2C as c= ompared with each mode (how many are
>=3B therre?) which needs it impl= ementing it specially. What is your feeling
>=3B about how many deriv= ed modes would benefit from it?
>=3B

Well=2C= I suspect that all script languages with C-like syntax are candidates. AWK= could be  =3Bmodified to use the feature. CSH shell could be another c= andidate. bc (arbitrary precision math script language) could also be anoth= er candidate. Like DXL these two languages have specific constructs (e.g. d= efine in bc) and they do probably need some more hooks in cc to make it. BT= W=2C my dxl-mode.el does not handle so properly the if ... then  =3Band= for .. in .. do constructs.

Frankly speaking=2C I= use neither csh (only bash is ported on msw) nor bc (I do my maths with EM= ACS calc or scilab depending on what I need to do)=2C so these are only jus= t those which came to my mind. =3B

Basically I= am quite convinced that functions like put or create that come with Array = or Skip in DXL should be in builtin font=2C because these are really things= you could hardly implement in DXL if they were not provided with it --- we= ll in fact that would be possible to do it like DxlObject's=2C but certainl= y would lose too much in performance . =3B

>=3B --
= >=3B Alan Mackenzie (Nuremberg=2C Germany).
>=3B

=
 =3B Vincent Bela=EFche (Rennes=2C France)
= --_89a055b8-fb0e-4449-b877-4779070e8d02_--