Re: [CEDET-devel] macros in .[bw]y files
Brought to you by:
zappo
From: David P. <dav...@wa...> - 2003-08-01 10:54:37
|
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. >>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) (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) Using a such paradigm would lead to make EIEIO mandatory for Semantic. [...] >>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. [...] >>I am afraid but I don't clearly see your point here. Could you please >>give a short example on how these different parsers would work? > > > Here is an example from semantic-grammar-2.wy: > > token_decl: > TOKEN token_type_opt SYMBOL string_value > `(TAG ',$3 ',(if $2 'token 'keyword) :type ',$2 :value ',$4) > | TOKEN token_type_opt symbols > `(TAG ',(car $3) 'token :type ',$2 :rest ',(cdr $3)) > ; > > This create s tags. Font lock might look like this: > > token_decl: > TOKEN token_type_opt SYMBOL string_value > `(progn (FACE keyword $1) > (FACE type $2) > (FACE variable $3) > (FACE string $4)) > | TOKEN token_type_opt symbols > ... > ; > > As macros, they do macro things just like TAG. You probably don't > want a FACE macro available while tagging, nor a TAG macro available > while font locking. 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? >>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 ;-) David |