Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ocamlyacc documentation + feature wish #8305

Closed
vicuna opened this issue Sep 29, 2003 · 4 comments
Closed

ocamlyacc documentation + feature wish #8305

vicuna opened this issue Sep 29, 2003 · 4 comments

Comments

@vicuna
Copy link

vicuna commented Sep 29, 2003

Original bug ID: 1858
Reporter: administrator
Status: closed (set by @xavierleroy on 2013-08-31T10:46:13Z)
Resolution: won't fix
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_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.

@vicuna
Copy link
Author

vicuna commented Oct 13, 2003

Comment author: administrator

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

@vicuna
Copy link
Author

vicuna commented Oct 13, 2003

Comment author: administrator

----- 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 (#8305)
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



@vicuna
Copy link
Author

vicuna commented Feb 15, 2004

Comment author: administrator

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.

@vicuna
Copy link
Author

vicuna commented Jan 26, 2012

Comment author: @damiendoligez

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant