Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Re: Efficient C++ Interfacing?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Eray Ozkural <exa@k...>
Subject: Re: [Caml-list] Re: Efficient C++ Interfacing?
On Tuesday 29 June 2004 04:35, skaller wrote:
> On Tue, 2004-06-29 at 05:58, Eray Ozkural wrote:
> >  The only sad thing about these systems is that they are not
> > written in ocaml. :)
>
> An Earley parser is easy to make, RD even easier
> although it's a bit harder in that case to get the
> grammar right.
>
> The main problem is handling the silly identifier/typename
> distinction, which is easy to do .. and hard to *undo*:
> forgetting things is vital for a functional parser.
> Tying the lexer and parser together solves this problem.
>
> I assume performance isn't as vital to you as actually
> parsing the input. Earley seems quite feasible for C++,
> since in practice there are enough 'stopping symbols'
> to restrict the O(n^3) performance problem to small
> enough n to be practical.
>
> The bottom line here is that it is a lot of work
> to elaborate all the grammar productions, especially
> if you want to take MSC/gnu extensions into account
> and handle "C" as well (since C has distinct
> rules for some things like enums and nested classes).

I'd studied Earley parsers in an NLP course. I've no idea if it would be so 
much easier than an ANTLR or OpenC++ parser, though. Is it because we 
wouldn't have to factor the grammar or some other improvement in 
specification? Would we be able to maintain semantic predicates a la ANTLR 
easily? (The lead developer of ANTLR seems to suggest writing a C++ parser is 
a crafty, difficult thing regardless of which parser technology you 
choose...)

Regards,

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project: http://www.kde.org
http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://malfunct.iuma.com
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners