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

Better understanding of camlp4 extensions #60

Closed
roshanjames opened this Issue Aug 16, 2013 · 6 comments

Comments

Projects
None yet
3 participants
@roshanjames

roshanjames commented Aug 16, 2013

merlin needs to understand camlp4 extensions. For instance, things fail in the presence of units tests where we have a "TEST =" syntax provided by pa_ounit. Soon we will have simialr extensions for micro-benchmarks.

For now, maybe one can hack in the commonly used syntax extensions. In the long term we need a better solution for this.

@let-def

This comment has been minimized.

Show comment
Hide comment
@let-def

let-def Aug 16, 2013

Contributor

There is support for ounit, if that fails then it's either a bug or a configuration issue. Can you provide a sample file?

Contributor

let-def commented Aug 16, 2013

There is support for ounit, if that fails then it's either a bug or a configuration issue. Can you provide a sample file?

@let-def

This comment has been minimized.

Show comment
Hide comment
@let-def

let-def Aug 16, 2013

Contributor

General support for camlp4 is out of scope. But supporting ppx extensions looks realistic.
Also, I would like to see the BENCHMARK grammar.

Contributor

let-def commented Aug 16, 2013

General support for camlp4 is out of scope. But supporting ppx extensions looks realistic.
Also, I would like to see the BENCHMARK grammar.

@roshanjames

This comment has been minimized.

Show comment
Hide comment
@roshanjames

roshanjames Aug 16, 2013

I agree that general support for camlp4 is largely impossible and yes ppx might be the right way to go. You can close this issue for now.

I'll send you a some notes about the pa_bench grammar tomorrow.

roshanjames commented Aug 16, 2013

I agree that general support for camlp4 is largely impossible and yes ppx might be the right way to go. You can close this issue for now.

I'll send you a some notes about the pa_bench grammar tomorrow.

@let-def let-def closed this Aug 16, 2013

@roshanjames

This comment has been minimized.

Show comment
Hide comment
@roshanjames

roshanjames Aug 18, 2013

Coming back to this issue. In the OCaml toplevel one can extend the language syntax by specifying camlp4 syntax extensions. Without this, things like "with sexp" throw an error. I don't have a deep understanding by which this works, but I wonder if this is something that can be adapted to merlin also:

$ rlwrap ocaml
        OCaml version 4.00.1
# #use "topfind";;
- : unit = ()
Findlib has been successfully loaded. Additional directives:
  #require "package";;      to load a package
  #list;;                   to list the available packages
  #camlp4o;;                to load camlp4 (standard syntax)
  #camlp4r;;                to load camlp4 (revised syntax)
  #predicates "p,q,...";;   to set these predicates
  Topfind.reset();;         to force that packages will be reloaded
  #thread;;                 to enable threads
- : unit = ()
# #camlp4o;;
/home/rosh/.opam/4.00.1/lib/ocaml/dynlink.cma: loaded
/home/rosh/.opam/4.00.1/lib/ocaml/camlp4: added to search path
/home/rosh/.opam/4.00.1/lib/ocaml/camlp4/camlp4o.cma: loaded
    Camlp4 Parsing version 4.00.1
# #require "sexplib.syntax";;
/home/rosh/.opam/4.00.1/lib/type_conv: added to search path
/home/rosh/.opam/4.00.1/lib/type_conv/pa_type_conv.cma: loaded
/home/rosh/.opam/4.00.1/lib/ocaml/unix.cma: loaded
/home/rosh/.opam/4.00.1/lib/ocaml/bigarray.cma: loaded
/home/rosh/.opam/4.00.1/lib/ocaml/nums.cma: loaded
/home/rosh/.opam/4.00.1/lib/num-top: added to search path
/home/rosh/.opam/4.00.1/lib/num-top/num_top.cma: loaded
/home/rosh/.opam/4.00.1/lib/num: added to search path
/home/rosh/.opam/4.00.1/lib/sexplib: added to search path
/home/rosh/.opam/4.00.1/lib/sexplib/sexplib.cma: loaded
/home/rosh/.opam/4.00.1/lib/sexplib/pa_sexp_conv.cma: loaded
# open Sexplib.Std;;
# type t = { x : int; y : int} with sexp;;
type t = { x : int; y : int; }
val __t_of_sexp__ : Sexplib.Sexp.t -> t = 
val t_of_sexp : Sexplib.Sexp.t -> t = 
val sexp_of_t : t -> Sexplib.Sexp.t = 

roshanjames commented Aug 18, 2013

Coming back to this issue. In the OCaml toplevel one can extend the language syntax by specifying camlp4 syntax extensions. Without this, things like "with sexp" throw an error. I don't have a deep understanding by which this works, but I wonder if this is something that can be adapted to merlin also:

$ rlwrap ocaml
        OCaml version 4.00.1
# #use "topfind";;
- : unit = ()
Findlib has been successfully loaded. Additional directives:
  #require "package";;      to load a package
  #list;;                   to list the available packages
  #camlp4o;;                to load camlp4 (standard syntax)
  #camlp4r;;                to load camlp4 (revised syntax)
  #predicates "p,q,...";;   to set these predicates
  Topfind.reset();;         to force that packages will be reloaded
  #thread;;                 to enable threads
- : unit = ()
# #camlp4o;;
/home/rosh/.opam/4.00.1/lib/ocaml/dynlink.cma: loaded
/home/rosh/.opam/4.00.1/lib/ocaml/camlp4: added to search path
/home/rosh/.opam/4.00.1/lib/ocaml/camlp4/camlp4o.cma: loaded
    Camlp4 Parsing version 4.00.1
# #require "sexplib.syntax";;
/home/rosh/.opam/4.00.1/lib/type_conv: added to search path
/home/rosh/.opam/4.00.1/lib/type_conv/pa_type_conv.cma: loaded
/home/rosh/.opam/4.00.1/lib/ocaml/unix.cma: loaded
/home/rosh/.opam/4.00.1/lib/ocaml/bigarray.cma: loaded
/home/rosh/.opam/4.00.1/lib/ocaml/nums.cma: loaded
/home/rosh/.opam/4.00.1/lib/num-top: added to search path
/home/rosh/.opam/4.00.1/lib/num-top/num_top.cma: loaded
/home/rosh/.opam/4.00.1/lib/num: added to search path
/home/rosh/.opam/4.00.1/lib/sexplib: added to search path
/home/rosh/.opam/4.00.1/lib/sexplib/sexplib.cma: loaded
/home/rosh/.opam/4.00.1/lib/sexplib/pa_sexp_conv.cma: loaded
# open Sexplib.Std;;
# type t = { x : int; y : int} with sexp;;
type t = { x : int; y : int; }
val __t_of_sexp__ : Sexplib.Sexp.t -> t = 
val t_of_sexp : Sexplib.Sexp.t -> t = 
val sexp_of_t : t -> Sexplib.Sexp.t = 
@gasche

This comment has been minimized.

Show comment
Hide comment
@gasche

gasche Aug 18, 2013

Member

The people that design domain-specific language extensions for little benefits are the one that make life difficult for tool maker of all kinds. It would be extremely hard to retain Merlin's incremental parsing and robustness if it also tried to accept arbitrary dynamic changes to the syntax. The right thing to do is to accept some specific well-defined extension points (eg. the ones of Alain's extension_points branch, or type-conv style "with ...", or camlp4 quotations), and let other users think twice before going for the "let's define a new syntax for my problem domain" route.

Member

gasche commented Aug 18, 2013

The people that design domain-specific language extensions for little benefits are the one that make life difficult for tool maker of all kinds. It would be extremely hard to retain Merlin's incremental parsing and robustness if it also tried to accept arbitrary dynamic changes to the syntax. The right thing to do is to accept some specific well-defined extension points (eg. the ones of Alain's extension_points branch, or type-conv style "with ...", or camlp4 quotations), and let other users think twice before going for the "let's define a new syntax for my problem domain" route.

@roshanjames

This comment has been minimized.

Show comment
Hide comment
@roshanjames

roshanjames Aug 18, 2013

If what you are saying amounts to saying that supporting both dynamic syntax extensions and error recovery is impossible, then I disagree. I suspect that there are several interesting design choices in this space.

If you are saying that this is a hard problem and that the immediate pragmatic approach should be to build in support for common extensions, I completely agree.

My two cents is that I feel it's worth thinking about the former to see if it has a nice solution. It seems like an interesting enough problem to warrant some curiosity.

roshanjames commented Aug 18, 2013

If what you are saying amounts to saying that supporting both dynamic syntax extensions and error recovery is impossible, then I disagree. I suspect that there are several interesting design choices in this space.

If you are saying that this is a hard problem and that the immediate pragmatic approach should be to build in support for common extensions, I completely agree.

My two cents is that I feel it's worth thinking about the former to see if it has a nice solution. It seems like an interesting enough problem to warrant some curiosity.

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