Finn Bock wrote:

I have not yet removed the properties.xsl file from CVS. I guess it should be removed since it isn't used anymore.


[J.Pietschmann]

I think you could leave the file there for now.


Ok.

It should be
sufficient to  inactivate the related task in the buildfile
(for example putting it in an XML comment).


Too late for that, but I'll reactive the lines as comments tomorrow.

Does anyone know why we wrap the datatypes instances in a property instance?


No.

Actually we should strive to use a proper parse tree for
property expressions:
1. Create a few classes for the symbols in the property
  expression grammar (section 5.9 of the spec). I think we need
 as terminals
 - AbsoluteNumeric
 - RelativeNumeric
 - Color (the #NNNNN thingy)
 - String (aka Literal)
 - NCName (everything else, basically, including enum tokens and
  "inherit")
 and for the nonterminals
 - PropertyFunction
 - Some classes for the operators
2. Write a proper parser (maybe using ANTLR, at least for bootstrap)
 which produces a proper parse tree.

With my naive understanding of parsing as a two-stage process (lexemes -> higher level constructs) I have been curious about earlier comments of yours about multi-stage parsing. Can ANTLR do this sort of thing?


3. Add methods to the objects for resolving relative numeric values
 (percentages, em) and for evaluation.
4. Perhaps add constant folding to the parser.


Interesting. What issues do we have in property parsing that is solved by this? I'm only aware of arithmetic on relative numerics which doesn't work.

Given the amount of hacking I had to do to parse everything that could legally be thrown at me, I am very surprised that these are the only issues in HEAD parsing.


Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>



Reply via email to