Mantis Bug Tracker
Main | My View | View Issues | Change Log | Roadmap
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001858OCamlOCaml generalpublic2003-09-29 23:042012-01-27 00:13
Reporteradministrator 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
StatusresolvedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0001858: ocamlyacc documentation + feature wish
DescriptionFull_Name: john skaller
Version: 3.07beta
OS: na
Submission from: proxy3.tpgi.com.au (203.26.24.213)


Ocamlyacc documentation omission:

The method of calling a generated parser is not documented. The only
clue to the calling convention is in the example of 12.6:

 let _ =
          try
            let lexbuf = Lexing.from_channel stdin in
            while true do
              let result = Parser.main Lexer.token lexbuf in
                print_int result; print_newline(); flush stdout
            done
          with Lexer.Eof ->
            exit 0

Ocamlyacc feature wish:

The calling convention is sometimes inconvenient and not
properly generalised. Please at least add a new interface

   parser_function (token_source: unit->Token.token)

which accepts a single function that is called to return tokens.
[This should be the principal interface, with the existing
interface just being a wrapper around it]

The current interface may sometimes be useful, but if the token
source is different than a lexer/lexbuf pair it is very inconvenient
to make a dummy lexbuf object (and lexer) just to satisfy the interface.

As it is the interface fails to correctly handle C,
in which #include files require a stack of lexbufs.

The existing interface also doesn't accomodate the ability to add arguments
to the lexer function. The lexbuf is just another argument: the parser
shouldn't know anything about lexbufs.






TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0000177)
administrator (administrator)
2003-10-13 18:21

 > Full_Name: john skaller

> Ocamlyacc feature wish:
>
> The calling convention is sometimes inconvenient and not
> properly generalised. Please at least add a new interface
>
> parser_function (token_source: unit->Token.token)
>
> which accepts a single function that is called to return tokens.
> [This should be the principal interface, with the existing
> interface just being a wrapper around it]

It's not that simple. The parser needs to look at the lex_start_p
and lex_curr_p fields of the lexbuf in order to update the start
and end positions for error reporting (symbol_start_pos,
symbol_end_pos, etc.)

And if you look closely, you'll notice that it needs the value of
lex_curr_p before the lexer is called for the first time.

So the change you are proposing is not as trivial as you think,
although I agree it would be a good idea to loosen the coupling
between ocamlyacc and ocamllex.

-- Damien
(0000178)
administrator (administrator)
2003-10-13 18:21

    ----- The following addresses had permanent fatal errors -----
<skaller@ozemail.com.ai>
    (reason: 550 Host unknown)

   ----- Transcript of session follows -----
550 5.1.2 <skaller@ozemail.com.ai>... Host unknown (Name server: ozemail.com.ai.: host not found)

----------------
Reporting-MTA: dns; concorde.inria.fr
Received-From-MTA: DNS; pauillac.inria.fr
Arrival-Date: Mon, 13 Oct 2003 18:21:33 +0200 (MET DST)

Final-Recipient: RFC822; skaller@ozemail.com.ai
Action: failed
Status: 5.1.2
Remote-MTA: DNS; ozemail.com.ai
Diagnostic-Code: SMTP; 550 Host unknown
Last-Attempt-Date: Mon, 13 Oct 2003 18:21:34 +0200 (MET DST)

----------------
Return-Path: <caml-bugs@pauillac.inria.fr>
Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35])
    by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h9DGLX118022
    for <skaller@ozemail.com.ai>; Mon, 13 Oct 2003 18:21:33 +0200 (MET DST)
Received: from localhost (localhost.inria.fr [127.0.0.1]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA11908 for <skaller@ozemail.com.ai>; Mon, 13 Oct 2003 18:21:32 +0200 (MET DST)
Date: Mon, 13 Oct 2003 18:21:32 +0200 (MET DST)
Message-Id: <200310131621.SAA11908@pauillac.inria.fr>
From: Damien Doligez <caml-bugs@pauillac.inria.fr>
To: skaller@ozemail.com.ai
Subject: Re: ocamlyacc documentation + feature wish (PR#1858)
X-Loop: caml-bugs@pauillac.inria.fr
MIME-Version: 1.0

> Full_Name: john skaller

> Ocamlyacc feature wish:
>
> The calling convention is sometimes inconvenient and not
> properly generalised. Please at least add a new interface
>
> parser_function (token_source: unit->Token.token)
>
> which accepts a single function that is called to return tokens.
> [This should be the principal interface, with the existing
> interface just being a wrapper around it]

It's not that simple. The parser needs to look at the lex_start_p
and lex_curr_p fields of the lexbuf in order to update the start
and end positions for error reporting (symbol_start_pos,
symbol_end_pos, etc.)

And if you look closely, you'll notice that it needs the value of
lex_curr_p before the lexer is called for the first time.

So the change you are proposing is not as trivial as you think,
although I agree it would be a good idea to loosen the coupling
between ocamlyacc and ocamllex.

-- Damien


----------------
----------------
(0000179)
administrator (administrator)
2004-02-15 11:43

 Calling conventions for ocamlyacc-generated parsers are documented in the
manual, section "Overview of ocamllex". Abstracting over the token source would
be nice indeed, but isn't obvious to do because of location tracking.
(0006816)
doligez (manager)
2012-01-27 00:13

 Moreover, it is now recommended to use Menhir instead of ocamlyacc.

- Issue History
Date Modified Username Field Change
2005-11-18 10:13 administrator New Issue
2012-01-27 00:13 doligez Note Added: 0006816
2012-01-27 00:13 doligez Status acknowledged => resolved
2012-01-27 00:13 doligez Resolution open => won't fix
2012-01-27 00:13 doligez Description Updated View Revisions

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker