Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005456OCamlCamlp4public2011-12-29 17:122013-08-31 12:44
Reportergerd 
Assigned Todim 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version3.12.1 
Target VersionFixed in Version3.12.1+dev 
Summary0005456: pa_macro: __LOCATION__ and DEFINE interaction
DescriptionI'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 InformationAs 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.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0006554)
gasche (developer)
2011-12-29 17:36

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).
(0006599)
dim (developer)
2012-01-05 15:38

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.
(0006600)
dim (developer)
2012-01-05 15:40

Commits 11991 and 11992.

- Issue History
Date Modified Username Field Change
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
2013-08-31 12:44 xleroy Status resolved => closed


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker