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

directive 'remove_directory' was not supported in camlp4 #5716

Closed
vicuna opened this issue Aug 3, 2012 · 9 comments
Closed

directive 'remove_directory' was not supported in camlp4 #5716

vicuna opened this issue Aug 3, 2012 · 9 comments

Comments

@vicuna
Copy link

vicuna commented Aug 3, 2012

Original bug ID: 5716
Reporter: @bobzhang
Status: closed (set by @damiendoligez on 2015-01-13T18:28:01Z)
Resolution: suspended
Priority: normal
Severity: minor
Target version: undecided
Category: -for Camlp4 use https://github.com/ocaml/camlp4/issues

Bug description

camlp4o -str '#remove_directory "ahah"' -printer o
File "/var/folders/ty/p2nh7m4x55977ghj1zq2z1qm0000gn/T/from_string0eee06.ml", line 1, characters 0-24:
Parse error: bad directive

camlp4o -v
Camlp4 version 4.01.0+dev6_2012-07-30

@vicuna
Copy link
Author

vicuna commented Aug 3, 2012

Comment author: @lefessan

What were you expecting ?

Directives are only usable from the toplevel, and they work for me:

ocaml -I +camlp4
OCaml version 4.00.0

#load "dynlink.cma";;

#load "camlp4o.cma";;

Camlp4 Parsing version 4.00.0

#remove_directory "ahah";;

@vicuna
Copy link
Author

vicuna commented Aug 3, 2012

Comment author: @bobzhang

I think camlp4 should accept it as valid input. it's inconsistent with other directives,
e.g
camlp4o -str '#directory "haha"' -printer o
is ok

My suggestions: emit warnings for both cases.
Can you explain a bit why toplevel accept it, did they not share the same parser? Many thanks

@vicuna
Copy link
Author

vicuna commented Aug 3, 2012

Comment author: @bobzhang

actually directives are also used in sources.
like #load; #default_quotaion ...

@vicuna
Copy link
Author

vicuna commented Aug 3, 2012

Comment author: @lefessan

Directives like "#load" or "#default_quotation" are camlp4 directives, while "#remove_directory" is an ocaml directive. Only camlp4 directives can be parsed directly by camlp4o (they are understood by the Camlp4Bin module, which drives most camlp4 binaries). The ones that are in the toplevel are either understood by camlp4, or sent back to the toplevel who can handle them.

@vicuna
Copy link
Author

vicuna commented Aug 3, 2012

Comment author: @bobzhang

then why directives 'directory', 'remove_directory' are handled differently?

@vicuna
Copy link
Author

vicuna commented Aug 3, 2012

Comment author: @gasche

Note that eg. #warning_error and #load_rec are also affected by this behavior. This is a bit worrying for #load_rec as it should probably be specifically handled with DynLoader.

@vicuna
Copy link
Author

vicuna commented Aug 6, 2012

Comment author: @lefessan

I still don't understand what is wrong. "camlp4" does not understand "ocaml" directives, except if they are the same ones as "camlp4" directives (i.e. #load, #directory). So, there are two possible reports here:
1/ all "ocaml" directives should be understood by "camlp4o", if somebody wants to preprocess a source file targetting the toplevel;
2/ a new "#remove_directory" directive (and probably #load_rec too) should be implemented also for camlp4, as they extend directives that are available on both camlp4 and ocaml.

Well, 1/ could be implemented by just discarding all directives, issuing a warning instead of an error. 2/ while #remove_directory seems easy to implement, #load_rec is not (the "ocaml" code for it already has a few bug reports...)

@vicuna
Copy link
Author

vicuna commented Aug 7, 2012

Comment author: @bobzhang

I am for the second report. Fails to parse is too strict

@vicuna
Copy link
Author

vicuna commented Jan 13, 2015

Comment author: @damiendoligez

Transferred to camlp4/camlp4#76

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