English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Another nasty with ocamlyacc: magic needed?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-12-05 (09:05)
From: Alessandro Baretta <a.baretta@b...>
Subject: Re: [Caml-list] Another nasty with ocamlyacc: magic needed?
skaller wrote:

> I do. It is useful. But the secondary parser is an RD parser
> interpreter. The idea isn't to allow arbitrary grammar
> extensions .. only to make particular yacc productions
> open-recursive closed by the dynamically built table
> of extensions.
> Thus the RD parser calls back into yacc entry points,
> and, the yacc productions call into the RD parser entry
> points. This is organised via the lexer.

By applying the 'ocamlyacc parser.mly; rm parser.mli; ocamlc -i parser.ml' 
approach, you can enclose the code generated by ocamlyacc into a structure. I 
used this approach when I was young and inexperienced to generate a functor from 
a parser definition, whereby the parser actions called a bunch of functions 
passed as parameters to the functor. I can also imagine that, possibly with some 
help from pa_ocamllex, you can define a pair of mutually recursive lexer and 
parser modules, which is about as far as you think about going with the yacc 

All this does require some "black magic", but no Obj.magic, which is rather neat.


Baretta DE&IT
A division of Baretta SRL

tel. +39 02 370 111 55
fax. +39 02 370 111 54

Our technology:

The Application System/Xcaml (AS/Xcaml)

The FreerP Project