A good day to you all!
Today and tomorrow it's holliday, here in Portugal (well, more precisely it's holliday today and tomorrow here in Lisbon and in other cities, only tomorrow it's holliday in the whole country....), so I'm going to try to use these 2 days to get a number of things done.
But, although I have to go, now, I wan't to wish you all a very good day!
See you all latter!
I've looking at a SGML parser (probably the best one available on the net for download, I think) but it doesn't solve my immedidate problem.
I don't need, right now, the whole possibilities of SGML; I just need to be able to get TAGs to carry values in their ATTRIBUTES and container tags to carry data between the start and end tags.
So I'll have to go in the same path I've already started and finish my own parser.
Latter, I might use other's code, if it will prove usefull, but right now I just have to finish it.
At this point I'm not going to have a DTD parser that will build the necessary words to conduct the main parser (giving the semanting meaning and rules for the *ML file being parsed) but I'll build them by hand, at this point.
Later I can go for a more generic solution.
So, let's go back to coding....
One thing that has come quite clear from all this work with parsers is which type of instructions one language should have to be able to efficientely manipulate and handle parsers.
One thing I like in FORTH it the easyness to build any parser, specialy if it can be expressed with tokens separated by blanks (spaces, tabs or linebreaks) as that is already the natural behaveour of the FORTH interpreter.... And due to the fact that any usual ANS FORTH has the INTERPRET word as a defered word, it's always quite easy to built any arbitrary parser and use it insteaad of the default INTERPRET word....
But I think that it sould go a little further....
I've already identified a number of words and factors always common in any parser and my Mex4th will try to incorporate them in the INTERPRETER word list....