id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc,lang,patch,platform
314,.HLL_map doesn't do what we want,whiteknight,coke,"See #216 for more background information. The {{{.HLL_map}}} directive doesn't really do what we want it to do: It can't be used to map HLL types defined at runtime, only HLL types that are defined at compile time. As a general workaround, you can use the {{{$P0.'hll_map'()}}} method on the ParrotInterpreter PMC to map classes defined at runtime.

I don't think it's a good idea to have a {{{.HLL_map}}} directive that silently fails depending on where the class is defined. I think there are two solutions to this:

1) Deprecate .HLL_map, and use ParrotInterpreter.'hll_map'() exclusively.
2) Work on some kind of cache that .HLL_map can use to store mapped type names that aren't known at compile time, and get resolved to a class type at runtime after that type has been properly defined.

Either way, the current implementation of .HLL_map is too confusing and unhelpful for what we need, and we need to get it right by 1.0.",todo,closed,normal,1.1,core,,medium,fixed,imcc hll,,,,all
