Re[2]: [CEDET-devel] macros in .[bw]y files

[Eric M. L. <er...@si...>]

>>> David PONCE <dav...@wa...> seems to think that:
>Hi Eric,
>
>[...]
>>>That is a good point.  Perhaps we could use something like
>>>`<package>--' as prefix?
>> 
>> 
>> That might be a good idea.
>
>I did that.

Great!

>>>The only name that the developer must see is the name of the
>>>install-parser function that must be called from a mode hook.
>> 
>> 
>> Perhaps we could define an EIEIO object for a parser, and hide all
>> that stuff as slots in an instance of that object.  We already have a
>> strong dependency on EIEIO so it might not be so bad.
>
>Sounds like a good idea.  We could replace all the buffer local
>variables used for parsing by one buffer local variable that would
>point to the current parser instance, and use methods to retrieve the
>keyword, token, and parser tables, the parser name, and the grammar
>source file name for debugging.  Also we could have abstract methods
>to install hooks and overrides.  The root abstract parser class could
>look like this:
>
>My code is probably wrong.  I miss competence in the use of EIEIO ;-)
>
>(defclass semantic-parser ()
>  ((name 
>    :accessor semantic-parser-name
>    :documentation "Parser name")
>   (keyword-table
>    :accessor semantic-parser-keyword-table
>    :documentation "Table of language keywords.")
>   (token-table
>    :accessor semantic-parser-token-table
>    :documentation "Table of language tokens.")
>   (parse-table
>    :accessor semantic-parser-parse-table
>    :documentation "Table of parser rules.")
>   (grammar-file
>    :accessor semantic-parser-grammar-file
>    :documentation "Source of the grammar used to build this parser.")
>   )
>  "A Semantic parser."
>  :abstract t)

A great start.  I rarely use the :accessor slot attribute.  CLOS needs
it as a short hand because the eieio `oset' equivalent is

(fset (slot-value obj 'field) value),

and an accessor called `foo' makes
this more readable like this:

(fset (foo obj) value)

I do use accessors to make code more readable.  You can also create
read-only slots with them, where there is an :initarg, and :accessor,
and a :protection of 'private.  I tend not to think quite that far
ahead though I probably should.

Anyway, here is a start using more slot attributes:

(defclass semantic-parser ()
  ((name
    :type string
    :accessor semantic-parser-name
    :protection private
    :allocation class
    :documentation "Parser name")
   (keyword-table
    :type list
    :protection private
    :accessor semantic-parser-keyword-table
    :allocation class
    :documentation "Table of language keywords.")
   (token-table
    :type list
    :protection private
    :accessor semantic-parser-token-table
    :allocation class
    :documentation "Table of language tokens.")
   (parse-table
    :type list
    :protection private
    :accessor semantic-parser-parse-table
    :allocation class
    :documentation "Table of parser rules.")
   (grammar-file
    :type string
    :accessor semantic-parser-grammar-file
    :allocation class
    :documentation "Source of the grammar used to build this parser.")
   )
  "A Semantic parser."
  :abstract t)

You could then subclass for a language:

(defclass java-parser (semantic-parser)
   (name :initform "java")
   (keyword-table :initform ( big list o stuff))
   (token-table :initform ( bigger list o stuff))
   ...
   (java-thingy :documentation "Useful storage while parsing java.")
   "Parser for Java.")

which would basically share all root data with a core class.  A
run-time modification of the language grammar would effect all
buffers without any additional work.

>(defmethod semantic-parser-install-overrides ((parser semantic-parser))
>  "Install parser function overrides."
>  nil)
>
>(defmethod semantic-parser-install-hooks ((parser semantic-parser))
>  "Install hooks used by this parser."
>  nil)

Good ideas here too.

>Using a such paradigm would lead to make EIEIO mandatory for Semantic.

It is already mandatory if you want to use the Makefile.  As time
moves on I worry about this less because EIEIO makes life so much
easier.

>[...]
>>>To avoid multiplication of small directories (and avoid cluttering up
>>>the `load-path' with them), maybe should I remove the %package clause
>>>and make it implicit, like bison does?  That is, a grammar foo.[wb]y
>>>could produce a library foo-[wb]y.el (an implicit foo-[wb]y package).
>>>Thus for each language "foo" we will have: foo.[wb]y, foo-[wb]y.el and
>>>a main foo.el file.
>> 
>> 
>> It seems to me that the effect would be the same.  Bison does offer
>> command line arguments to change where the output goes, however.
>> Perhaps package could just be optional.
>
>Good idea.  I made %package optional.  By default it is defined as
>proposed above.

Thanks!

>[...]
  [ ... ]
>
>In fact, what I don't clearly see is how to associate a set of
>grammar macros to a specific grammar.
>
>For example:
>
>foo-macros.el:
>
>(defmacro TAG (&rest args)
>  `(foo-something ,@args))
>
>foo.wy:
>
>%{
>  (require 'foo-macros)
>  %}
>
>rule: component
>      (TAG $1)
>      ;
>
>foo-wy.el
>
>(require 'foo-macros)
>
>(defconst foo-wy--parse-table
>  ...
>  (rule
>    ((component)
>     (TAG $1)))
>  ...)
>
>At byte-compilation/runtime TAG will be expanded to `foo-something'.
>
>However if there is a "bar" grammar defined like this:
>
>bar-macros.el:
>
>(defmacro TAG (&rest args)
>  `(bar-something ,@args))
>
>bar.wy:
>
>%{
>  (require bar-macros)
>  %}
>
>rule: component
>      (TAG $1)
>      ;
>
>bar-wy.el
>
>(require 'bar-macros)
>
>(defconst bar-wy--parse-table
>  ...
>  (rule
>    ((component)
>     (TAG $1)))
>  ...)
>
>TAG will be expanded to `bar-something' as expected, but the new TAG
>macro will override the previous definition provided by foo-macros
>(there is a name conflict).
>
>How do you think we can solve that?

I understand your question now!  The parser generator needs to
associate a string with a macro, so the macro defined in a parser
macros file may look like this:

(defmacro foo-TAG (&rest args)
  `(bar-something ,@args))

(define-macro-for-this-run-of-the-parser-generator "TAG" 'foo-TAG)

This seems problematic though.  Perhaps the association of the string
"TAG" to 'foo-tag needs to somehow be in the grammar since it is the
parser-generator which uses that string, and nothing else.

>>>There is no other change but the format.  So, I can commit my work and
>>>start to convert grammars and support files right now :)
>>>More probably, after we have closed this thread ;-)
>> 
>>   [ ... ]
>> 
>> Sounds good to me.
>
>I already converted the whole wisent directory + the bovine-grammar
>mode.  It remains to convert .by and support files. A big change in
>view ;-)
  [ ... ]

That sounds great.  I will be leaving for a short holiday this
evening, so hopefully I can investigate these tasks when I return
next week.

Thanks for your efforts!
Eric

-- 
          Eric Ludlam:                 za...@gn..., er...@si...
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org