|Anonymous | Login | Signup for a new account||2013-05-22 12:16 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005456||OCaml||Camlp4||public||2011-12-29 17:12||2012-01-05 15:40|
|Target Version||Fixed in Version||3.12.1+dev|
|Summary||0005456: pa_macro: __LOCATION__ and DEFINE interaction|
|Description||I'm trying to use pa_macro to generate compile-time IDs. For this puepose I defined something like|
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.|
|Tags||No tags attached.|
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 <the location 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).
|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.|
|Commits 11991 and 11992.|
|2011-12-29 17:12||gerd||New Issue|
|2011-12-29 17:12||gerd||Status||new => assigned|
|2011-12-29 17:12||gerd||Assigned To||=> ertai|
|2011-12-29 17:36||gasche||Note Added: 0006554|
|2012-01-05 15:38||dim||Note Added: 0006599|
|2012-01-05 15:40||dim||Assigned To||ertai => dim|
|2012-01-05 15:40||dim||Status||assigned => resolved|
|2012-01-05 15:40||dim||Resolution||open => fixed|
|2012-01-05 15:40||dim||Fixed in Version||=> 3.12.1+dev|
|2012-01-05 15:40||dim||Note Added: 0006600|
|Copyright © 2000 - 2011 MantisBT Group|