Show where compiled functions are

[ChrisJefferson]

When GAP displays information about a compiled function, it doesn't show where it comes from. a compiled function, it doesn't show where it came from.

We do store this information at the C level, in the final argument here we find this function is src/range.c:IS_RANGE

{ "IS_RANGE", "obj", &IsRangeFilt, FuncIS_RANGE, "src/range.c:IS_RANGE" },

But at the moment, this information is not accessible at the GAP level. I would like to make it available, preferably with minimal existing changes. I can think of two sensible options:

1. Make the FILENAME_FUNC equal to src/range.c:IS_RANGE (so technically the filename now isn't a filename)

2. Make FILENAME_FUNC equal to src/range.c, and make STARTLINE_FUNC equal to IS_RANGE (so now STARTLINE_FUNC isn't always an integer). We could rename STARTLINE_FUNC to START_FUNC, as it is already undocumented (leaving in an alias..)

3. Just set FILENAME_FUNC, and let users go and find the function in the file.

I don't really want to introduce a new separate way of getting the C name

If no-one expresses a strong opinion, I plan on doing (2), as that (in my mind) fits most nicely with what's already in GAP in my opinion.

[stevelinton]

Just so you know -- that field in the C level structure is only required to be a unique string (used in workspace save-load). The convention to use filename:function-name is just a convention and is even deliberately violated in a handful of places to make the string shorter (since it appears many times in a saved workspace).

[ChrisJefferson]

That's good to know, I knew it didn't have meaning, but I was considering standardising them on filename:function. I didn't know there was any reason not to do that. It would be easy to add another, optional field which would be the actual filename:function info, for when we don't want to put that in the cookie.

[fingolfin]

I am not very enthusiastic about changing a function called STARTLINE_FUNC to sometimes return a string, no matter whether it is internal and undocumented or not. It just has a bad smell :/.

As to renaming it: Don't forget there's also ENDLINE_FUNC...

Looking at StructGVarFunc, the relevant member is named cookie. So, how about instead adding a new COOKIE_FUNC which returns that string, if available, and else returns fail?

[fingolfin]

Or how about replacing all these custom functions with one likely FUNC_INFO or so, which returns a record containing information about the function, in a nicer way?

[ChrisJefferson]

Yes, that's probably nicer. I wanted to avoid breaking any code that's using this stuff, but only NAME_FUNC is used in packages, and none of it is documented, so this is probably good time to do something nicer!

NAME_FUNC gets some use, so I'll be sure to leave that in as a backwards-compatable wrapper (maybe the others too, at the GAP level, as it is shouldn't be any work to leave them in, except a few extra methods).

[olexandr-konovalov]

Closed by #755.