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

pa_macro: __LOCATION__ and DEFINE interaction #5456

Closed
vicuna opened this issue Dec 29, 2011 · 3 comments
Closed

pa_macro: __LOCATION__ and DEFINE interaction #5456

vicuna opened this issue Dec 29, 2011 · 3 comments

Comments

@vicuna
Copy link

vicuna commented Dec 29, 2011

Original bug ID: 5456
Reporter: gerd
Assigned to: @diml
Status: closed (set by @xavierleroy on 2013-08-31T10:44:08Z)
Resolution: fixed
Priority: normal
Severity: feature
Version: 3.12.1
Fixed in version: 3.12.1+dev
Category: -for Camlp4 use https://github.com/ocaml/camlp4/issues
Monitored by: @diml @ygrek

Bug description

I'm trying to use pa_macro to generate compile-time IDs. For this puepose I defined something like

open Camlp4.PreCast

let register name f =
(* The idea is to register the function f under name. For testing we
only do: *)
prerr_endline (Loc.to_string name);;

DEFINE Rfun(f) = (register LOCATION f);;

Rfun(fun _ -> 10);;
Rfun(fun _ -> 29);;

However, I notice that LOCATION always returns the same location, namely where this word occurs in the source code. This is very unfortunate in conjuction with DEFINE: One is normally interested in the location of the caller of the macro, but not in the location of the macro itself.

A better mechanism would be something like LOCATION_OF(id) where id would be a macro parameter. It would return the location of the actual parameter (i.e. where the macro is called).

Additional information

As we are at it: LOCATION generates a Loc.t value. This means I have to link in camlp4 into the executable - which makes it slightly harder to use (it took 30 minutes to locate the signature of Loc, and to find Loc.to_string). It would be more useful if it just generated the location tuple, or even just a string.

@vicuna
Copy link
Author

vicuna commented Dec 29, 2011

Comment author: @gasche

The workaround is to pass LOCATION as an argument of the macro, at the usage site. It's a bit heavier but frankly bearable.

As we are at it: LOCATION generates a Loc.t value. This means I have to link in camlp4 into the executable

That is not exactly true. LOCATION expands to "Loc.of_tuple ". You can link and use Camlp4's Loc module, but you can equally well define your own Loc module, where of_tuple is just the identity, to get the tuple directly without linking anything. That's admittedly a hack (like the people that shadow Array.get to use the array indexing notation...), but a very reasonable workaround; and I consider this is by design.

Besides, it would be quite difficult to change this without breaking backward compatibility. On the contrary, it seems reasonable -- if technically feasible -- to try to expand LOCATION after expanding macro definitions, rather than before; that's a change in behavior, but maybe not compatibility-breaking (LOCATION should only be used for end-user reporting anyway).

@vicuna
Copy link
Author

vicuna commented Jan 5, 2012

Comment author: @diml

I changed the way LOCATION is expanded. Now it is replaced after macro expansion, so it will be replaced by the location of the caller if used inside a macro definition. I also added LOCATION_OF to get the location of a macro parameter.

@vicuna
Copy link
Author

vicuna commented Jan 5, 2012

Comment author: @diml

Commits 11991 and 11992.

@vicuna vicuna closed this as completed Aug 31, 2013
@vicuna vicuna added the camlp4 label Mar 14, 2019
@vicuna vicuna assigned ghost Mar 14, 2019
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