caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* Re : [Caml-list] Ask for a more efficient way to deallocate memory (full version)
@ 2007-12-11  9:56 Matthieu Wipliez
  2007-12-12  6:54 ` Camlp4 error messages (was Re: Re : [Caml-list] Ask for a more efficient way to deallocate memory) David Teller
  0 siblings, 1 reply; 3+ messages in thread
From: Matthieu Wipliez @ 2007-12-11  9:56 UTC (permalink / raw)
  To: caml-list

[-- Attachment #1: Type: text/plain, Size: 1985 bytes --]

Error messages do are different:

> cat syntax_error.ml
let f a b =
  a + b *

> ocamlc -c syntax_error.ml
File "syntax_error.ml", line 3, characters 0-0:
Syntax error

> ocamlc -pp camlp4o.opt -c syntax_error.ml
File "syntax_error.ml", line 2, characters 6-7:
Parse error: [expr] expected after [infix operator (level 3) (start with '*', '/', '%')] (in [expr])
Preprocessor error

ocamlc standard parser gives erroneous position, and just complains about "Syntax error", while camlp4 is able to say precisely where the error occurred, and why (here because an expression is expected after the * infix operator). And this really makes the difference for tricky syntax errors (or when learning 
the language - I wish I had been taught of camlp4 back then ^^).


Matthieu Wipliez

----- Message d'origine ----
De : Yitzhak Mandelbaum <yitzhak@research.att.com>
À : caml-list <caml-list@yquem.inria.fr>
Envoyé le : Mardi, 11 Décembre 2007, 3h03mn 57s
Objet : Re: [Caml-list] Ask for a more efficient way to deallocate memory (full version)



On Dec 10, 2007, at 5:59 PM, Jon Harrop wrote:



 However, using any camlp4 macros requires using the camlp4 replacement for the 
 front-end of the compiler. That uses a different parsing technology (top-down 
 recursive descent LL rather than bottom-up LALR) so the error messages from 
 the compiler are completely different.
 


Just to clarify : the error messages from the *parser* are completely different. Everything after the parser is the same with or without camlp4. Most importantly, you don't have to learn new type-checker messages.


Yitzhak

 --------------------------------------------------
Yitzhak Mandelbaum
AT&T Labs - Research


http://www.research.att.com/~yitzhak

 







      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr

[-- Attachment #2: Type: text/html, Size: 5665 bytes --]

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

* Camlp4 error messages (was Re: Re : [Caml-list] Ask for a more efficient way to deallocate memory)
  2007-12-11  9:56 Re : [Caml-list] Ask for a more efficient way to deallocate memory (full version) Matthieu Wipliez
@ 2007-12-12  6:54 ` David Teller
  0 siblings, 0 replies; 3+ messages in thread
From: David Teller @ 2007-12-12  6:54 UTC (permalink / raw)
  To: Matthieu Wipliez; +Cc: caml-list



> Just to clarify : the error messages from the *parser* are completely different. Everything after the parser is the same with or without camlp4. Most importantly, you don't have to learn new type-checker messages.
> 
> 
> Yitzhak

Which might not always be a good thing.
That is, in the revised syntax, for instance, you write "list int"
instead of "int list" -- but the error message remains "int list".

Cheers,
 David


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

* Re : [Caml-list] Ask for a more efficient way to deallocate memory (full version)
@ 2007-12-16 12:52 Matthieu Wipliez
  0 siblings, 0 replies; 3+ messages in thread
From: Matthieu Wipliez @ 2007-12-16 12:52 UTC (permalink / raw)
  To: caml-list

Oliver Bandel <oliver@first.in-berlin.de>:
> 
> 
 > So, is it just a kind of pre-compilation?
> The core-OCaml compiler will be the same?
...
> I have not looked at the OCaml-compiler in detail,
> but from what you wrote I would assume, there
> are at least two parts.

Yes. The OCaml compilers accept a -pp option to pre-process the source code. This is how one can create a syntax extension without changing anything to the compilers. Traditionally, the pre-processor parses the code in the extended syntax, transforms it back to original syntax (where each extended construct becomes a chunk of code for example), and gives it to the compiler, as an AST.

> 
> Is the TryFinally-code slight enough, so that
> it's behaving like handwritten OCaml? Did you look
> at the TryFinally in detail?

Looking at http://martin.jambon.free.fr/pa_tryfinally.ml.html

The effect of the EXTEND ... END construct is to extend a syntax entry with rules. Here we extend "expr" (the entry for expressions) with a new [ "try"; expr; "finally"; expr ] rule. When Camlp4 parses code using this rule, it calls the "expand" function.

This function returns <:expr< code written in the revised syntax >>. This is a quotation. Even if you're not familiar with the revised syntax, I assume you can see the point there: try finally will be transformed to
"let result = try <body of the try> with ... in
let () = <body of the finally> in
match result with ...".

This syntax extension must be compiled with something like camlp4orf (original syntax in the language, revised syntax inside the quotations). camlp4 will replace each quotation by its equivalent AST representation. Note that the identifiers between $ are called antiquotations, and insert AST nodes where used.

For example, "let result = try ... in expr" is represented by something like:
ExLet (_loc, false, BiEq(_loc, PaId(_loc, IdLid(_loc, result)), ExTry(...)), expr)

You can pre-process code that uses a syntax extension and pretty-print it in original syntax: "camlp4o -parser TryFinally.cmo" file.ml
And you would see that it is exactly as if you wrote "let result = ..." everywhere instead of "try finally". The only additional cost is, as already mentioned, that the parsing is not as fast as using Yacc. Yet Yacc can hardly dynamically accept new syntaxes, so...
Compiling the code is done just by using the -pp option: ocamlc -pp "camlp4o -parser TryFinally.cmo" file.ml

 > Oh, well.... that's new to me.
> 
> I had not needed camlp4 so far. And I don't know if it makes sense to
> look at it now, because there will be (or already is?) a replacement
> (from 3.10 on?).

Camlp4 has been "partially reimplemented" by Nicolas Pouillard for 3.10 version (as said on caml.inria.fr). Most of these changes required the authors of syntax extensions to update their code so that it would compile with the new Camlp4. Daniel De Rauglaudre, the author of the original (pre 3.10) Camlp4, thus proposes Camlp5, which can be installed in a transitional mode to ensure backward compatibility.

> 
> I hope the camlp4-tutorial will be updated to the camlp4-replacement.
> Possibly later I might use it. Then it would be good to have
> introductional material.

Camlp4 3.10: http://brion.inria.fr/gallium/index.php/Camlp4
Camlp5: http://pauillac.inria.fr/~ddr/camlp5/doc/html/index.html

> Ciao,
>    Oliver


Matthieu



      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr


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

end of thread, other threads:[~2007-12-16 12:52 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-12-11  9:56 Re : [Caml-list] Ask for a more efficient way to deallocate memory (full version) Matthieu Wipliez
2007-12-12  6:54 ` Camlp4 error messages (was Re: Re : [Caml-list] Ask for a more efficient way to deallocate memory) David Teller
2007-12-16 12:52 Re : [Caml-list] Ask for a more efficient way to deallocate memory (full version) Matthieu Wipliez

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