RE: progmodes cc: addition of builtin def-const

[Vincent Belaïche]

Dear Alan,

Thank you for the feedback. 

[...]

> 
> As a matter of interest, what is DXL? All I found on the web was a
> language based on XML, not C-like at all.
>

DXL stands for "Doors Extension Language". Doors is a non free data base system for requirement handling. DXL allows to extend the client for instance to generate some report, to query for some requirements, to build some view of the data base, to do some export or some import. All these extensions 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 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 competitor IBM who offered similar tools like rational rose, etc... Currently Doors is used in the industry as some sort of de facto standard --- I know several other alternatives to handle requirements, 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 what industry I am talking about is quite HW oriented: when you build things that you cannot update easily by some SW upgrade, then requirement management becomes a job of its own.

DXL makes it easy to script, although you really have to get some knack of it before you can use it.

For instance --- as far as I remember:

int i = 3

print "i=" i

won't work, you have to write

int i = 3

print "i=" (i "")

because there is an overload of the concatenation operation (space, represented by `..' below) with this prototype

string ::.. (int i, string x)

but not with that one

string ::.. ( string x , int i) 

I understand that you may feel not very enthusiastic about allowing some extension for some proprietary language --- in fact neither I am ! This DXL mode is just a somehow quick hack which I did during working hours, without spending very significant time on it --- in fact I was not even supposed to do that, but I did it because I needed to make some scripts and I estimated 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, 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). 

Having said that, 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, and I am unsure whether there is really public interest in it. As far as I am concerned despite all its limitations it is usable enough for the amount of DXL I need to write.

Please note that DXL, although it looks like C code has some unique syntax aspects

- multiline strings are allowed

- instruction tailing semi colon can be omitted when they can be inferred from context --- a bit like in AWK, but somehow more subtile

- it has some specific control construct:

  - in addition to `if (SOME_CONDITION) { THEN_STATEMENTS }' you can write

     `if SOME_CONDITION then { THEN_STATEMENTS }' 

  - you have some `for SOME_VAR in SOME_SET do {  LOOP_STATEMENTS  }' construct

- typing is quite important, and you can overload functions based on prototype --- to that extent 

> > On the other hand DXL is more typed than AWK, so the 3 level
> > fontification of cc-fonts.el is better to use than do a specific
> > fontification like in AWK mode.
>
> OK.
>
> > In order to achieve this goal of reusing cc-fonts, 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.
>
> > If nobody objects I would commit the change the patch thereof is herein
> > attached.
>
> 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, but is it a good thing to encourage?
>

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 `create', `put' and `null' in builtin font (like preprocessor), and delete in keyword font (like `if'). 

Array my_array = create(3,1)

// that is put(dest, src, pos_x, pos_y), awfull to state src

// before pos, but that is the syntax.

put(my_array ,"element (0,0)" ,0,0)

put(my_array ,3.0 ,1,0)

put(my_array ,4 ,2,0) 

string s = get(my_array,0,0) 

real x = get(my_array,1,0) 

int i = get(my_array,2,0)

if !(null my_array) then

{

  delete my_array

  my_array = null 

}

This font choice is because function

 Array create(int, int)

is one of the many overloads of builtin function create. While delete is rather a language keyword, as it can act on any dynamically allocated thing.

> Then, on the other hand, the new code does nothing which isn't already
> inside CC Mode.
>
> To answer my own question, I don't feel we really should encourage this
> use of c-preprocessor-face-name. As a matter of interest, have you tried
> using font-lock-add-keywords to get the new keywords fontified? If so,
> 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?
>

I have not tried this, 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, see below.
>

Ok I also inserted replies below.

> > VBR,
> > Vincent.
>
>
> > === modified file 'lisp/ChangeLog'
> > --- lisp/ChangeLog 2012-12-03 17:23:42 +0000
> > +++ lisp/ChangeLog 2012-12-03 19:55:20 +0000
> > @@ -1,3 +1,12 @@
> > +2012-12-03 Vincent Belaïche <address@hidden>
> > +
> > + * 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ín Martín Domingo <address@hidden>
>
> > * textmodes/ispell.el (ispell-init-process)
>
> > === 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,6 +649,15 @@
> > (prefix "::")
> > (left-assoc ".")))
>
> > +(c-lang-defconst c-builtin-kwds
> > + "Keywords for builtin keywords constants."
> > + ;; This is for functions that are not part of a library but builtin in the
> > + ;; language. AWK mode does not use this constant but could have done
> > + ;; so. Currently this is used only as a hook for languages not yes part of
> > + ;; cc-xxx progmode, like DXL.
> > + t nil
> > + )
> > +
> > (c-lang-defconst c-opt-identifier-concat-key
> > ;; Appendable adorned regexp matching the operators that join
> > ;; symbols to fully qualified identifiers, or nil in languages that
>
> c-builtin-kwds really needs a fuller doc string, since unlike
> c-constant-kwds, 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:
>
> "A list of keywords which will get fontified with c-preprocessor-face-name."
> ;; This is intended for built-in function names in modes derived from CC
> ;; Mode.
>

I agree.

> > === 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,6 +763,12 @@
> > `((eval . (list ,(concat "\\<\\(" re "\\)\\>")
> > 1 c-constant-face-name))))))
>
> > + ;; Fontify builtins keyword constants.
> > + ,@(when (c-lang-const c-builtin-kwds)
> > + (let ((re (c-make-keywords-re nil (c-lang-const c-builtin-kwds))))
> > + `((eval . (list ,(concat "\\<\\(" re "\\)\\>")
> > + 1 c-preprocessor-face-name)))))
> > +
> > ;; Fontify all keywords except the primitive types.
> > ,(if (c-major-mode-is 'pike-mode)
> > ;; No symbol is a keyword after "->" in Pike.
>
> But as I said, I'm not quite convinced that the general facility you've
> implemented is a good idea, 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?
>

Well, I suspect that all script languages with C-like syntax are candidates. AWK could be  modified to use the feature. CSH shell could be another candidate. bc (arbitrary precision math script language) could also be another candidate. Like DXL these two languages have specific constructs (e.g. define in bc) and they do probably need some more hooks in cc to make it. BTW, my dxl-mode.el does not handle so properly the if ... then  and for .. in .. do constructs.

Frankly speaking, 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), so these are only just those which came to my mind. 

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

> --
> Alan Mackenzie (Nuremberg, Germany).
>

  Vincent Belaïche (Rennes, France)