caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* a parsing question
@ 2000-05-04 14:49 knotwell
  2000-05-04 16:57 ` Jean-Yves Moyen
  2000-05-04 17:29 ` John Prevost
  0 siblings, 2 replies; 3+ messages in thread
From: knotwell @ 2000-05-04 14:49 UTC (permalink / raw)
  To: caml-list

Hello all--

I've been writing a configuration file parser using ocaml's lex and
yacc.  So far, I've run into two things (actually they both grow out
of the same problem) that seem like there should be a better way
(NOTE: since I'm new the example will seem pretty contrived):

Let's say I have the following data:
      <yoyo-time>
          40
      </yoyo-time>

and I want to parse out the 40 and stuff it into a data structure
usable *outside* of parser (assume lexer.mll, parser.mly, and
config_test.ml).  What I've currently done is the following:

(* parser.mly *)
(* NOTE:  I tried creating a yoyo_time object, but ocamlyacc
          apparently doesn't like the yoyo_time#set_time syntax *)
%{
let yoyo_time = ref 10;;
let set_yoyo_time newtime = yoyo_time := (int_of_string newtime);;
%}

%token YOYO_TIME_BEGIN YOYO_TIME_END INT
%start <string> main
%type <string> INT
%%

main: YOYO_TIME_BEGIN INT YOYO_TIME_END { set_yoyo_time $2; $2 }
%%

=============================

Unfortunately, I don't know how to "export" yoyo_time to parser.mli.
My Makefile currently does the following:  

    echo "val yoyo_time: int ref" >> parser.mli

While this works fine, I'd like to avoid using Make as a post-processor.

I wondered about defining numerous entry points, but I presumed this
would force me to be extremely careful about the ordering in my config
file.

Put another way, am I incorrect in assuming the lexer discards
previously unmatched data?

Since this is so long, I'll skip the second question--macros.

Thanks.
 
--Brad




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: a parsing question
  2000-05-04 14:49 a parsing question knotwell
@ 2000-05-04 16:57 ` Jean-Yves Moyen
  2000-05-04 17:29 ` John Prevost
  1 sibling, 0 replies; 3+ messages in thread
From: Jean-Yves Moyen @ 2000-05-04 16:57 UTC (permalink / raw)
  To: Caml mailing list

On Thu, 4 May 2000 knotwell@f5.com wrote:

> Unfortunately, I don't know how to "export" yoyo_time to parser.mli.
> My Makefile currently does the following:  

I guess a solution could be to have yoyo_time defined in another module,
and in the parser, you could make explicit use of Yoyo.yoyo_time (or open
Yoyo).

Hypocoristiquement,
Jym.



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: a parsing question
  2000-05-04 14:49 a parsing question knotwell
  2000-05-04 16:57 ` Jean-Yves Moyen
@ 2000-05-04 17:29 ` John Prevost
  1 sibling, 0 replies; 3+ messages in thread
From: John Prevost @ 2000-05-04 17:29 UTC (permalink / raw)
  To: knotwell; +Cc: caml-list

>>>>> "kn" == knotwell  <knotwell@f5.com> writes:

        {...}

    kn> Unfortunately, I don't know how to "export" yoyo_time to
    kn> parser.mli.  My Makefile currently does the following:

    kn>     echo "val yoyo_time: int ref" >> parser.mli

    kn> While this works fine, I'd like to avoid using Make as a
    kn> post-processor.

The right solution is to define yoyo_time in another module:

blah.ml ------------

let yoyo_time = ref 10
let set_yoyo_time newtime = yoyo_time := (int_of_string newtime)

blah.mli ------------

val yoyo_time : int ref
val set_yoyo_time : string -> unit

parser.mly ----------

%{
open Blah
%}

This way you can stay away from touching the scary .mli file generated
by ocamlyacc.

John.  



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2000-05-04 18:11 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-05-04 14:49 a parsing question knotwell
2000-05-04 16:57 ` Jean-Yves Moyen
2000-05-04 17:29 ` John Prevost

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).