Re: Writing a scanner and parser in Ada

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2017-12-25 19:57, Yves Cloutier wrote:
> On Monday, December 25, 2017 at 12:08:38 PM UTC-5, Dmitry A. Kazakov wrote:
>> On 2017-12-25 17:35, Yves Cloutier wrote:
>>
>>> Yes my Perl version does all that in 1 pass, but one of the things I
>>> want to do is have it generate for different targets. Groff was my
>>> initial one. I wan't creating any kind of AST but I think I'll want to
>>> do that in my rewrite to make things simpler and allow for generating
>>> for other targets like maybe Latex, or epub etc...
>>
>> You don't need AST for that. Simply define code generator interface
>> (tagged) with abstract operations generating pieces of code. For each
>> target have a derived type implementing these operations. Pass a
>> class-wide Target object as a parameter to the parser. If the actual is
>> of Groff_Target the result is groff etc.
>>
> haha I'm quite new to Ada so most of what you just explained I don't
> quite understand. But will get there. Baby steps.

It is not that complicated when you get into Ada's OO model. The idea is 
that you abstract away code generator (as well as the code source) fro 
the parser. Then you can use the same parser with all back-ends and all 
types of sources (file, string, stream, text-buffer etc)

> I see that you created a SNOBOL-like pattern matcher. This looks
> really useful for processing text.

Not really. Pattern matching is rarely useful. There are few cases like 
searching and skipping parts of text, partial and error-tolerant parsing 
(like in text coloring). But even then simple wildcard patterns (like * 
and %) often work better because they are easier to understand.

The rationale is this. More powerful the formal language of patterns is, 
more difficult it becomes for the user to foresee and understand what 
the pattern will match and what not. Regular expressions are already too 
complex. SNOBOL patterns are even more powerful, so that anything beyond 
trivial quickly becomes not understandable.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de