name mangling and symbolic freedom

[Per Bothner]

I'm thinking of changing Kawa's name mangling (at least for class names),
and it would be helpful to have some information before doing so:

(1) I'd like a feel for home common/popular is the mangling
described by John Rose:
https://blogs.oracle.com/jrose/entry/symbolic_freedom_in_the_vm

(2) What tools, if any, such as IDEs, support this mangling?

(3) Any problems or suggested modifications to John's proposal?

Historically, I've used a mangling that translates into valid Java
identifiers, in the interest of Java interoperability: It is a feature
if Java can reference Scheme compiled classes and members without
reflection. However, are some downsides, most obviously that it
makes for ugly and surprising class and member names. For package
names it could means that the compiled class is in a different
directory than the source file. More generally, it is desirable
that source class names (modules names in Kawa) matches compiled class
names. Finally, Java reserved word cause a problem: Should we mangle
the identifier 'package' just because it is a reserved word in Java?

So I'm planning to "mangle less" when it comes to at least package and
class names. And if I'm going to change it, it may be reasonable to
change it to John's proposal, at least if other people are using it,
as is my understanding.

(I'm not changing procedure -> method name mangling and possible not
variable ->field mangling, because that affects the programming experience.
For example Kawa will compile a procedure name lookup-file-name to a
method name lookupFileName, and a property access path-name may get
compiled to a method getPathName. Those are useful features for Java
interoperability.)
--
--Per Bothner
p...@bothner.com http://per.bothner.com/

[John Rose]

On Sep 25, 2015, at 11:13 AM, Per Bothner <p...@bothner.com> wrote:

Finally, Java reserved word cause a problem: Should we mangle
the identifier 'package' just because it is a reserved word in Java?

For Project Panama we have been making a distinction between

"source name" (a Kawa identifier in this case) and "carrier name"

(a name subject to other formation rules, therefore needing mangling).

If your carrier namespace is JVM identifiers, there's no need to transform

the source names "package", "int", etc.  If your carrier namespace is

Java identifiers, you need much more mangling, probably using hex

numerals at some points, and you need to mangle keywords

like "package" also.  "Symbolic freedom" won't help much with

Java language interop.

I don't see a reason to mangle the Kawa source name "package"

using the "symbolic freedom" system, since that system is only

for the carrier names that are JVM identifiers.  But if you wanted

to tweak it anyway, you could consider adding the null prefix "\=".

HTH

— John

[Per Bothner]

On 09/26/2015 01:26 PM, John Rose wrote:

I have never mangled "package" and I don't intend to. I've already
decided to give up on mangling to "almost-always-Java-safe" names
("almost always" because "package" isn't Java-safe, for example),
in favor JVM-safe names that are more readable. What I'm deciding
between is either (1) loosening up of the existing Kawa mangling
(mangling fewer characters, but don't change the current encoding
for those characters that remain mangled), or (2) implementing the
"symbolic freedom" system. Hence my question about which
languages and tools use/support the latter.

[Per Bothner]

On 09/25/2015 11:13 AM, Per Bothner wrote:
> I'm thinking of changing Kawa's name mangling (at least for class names),
> and it would be helpful to have some information before doing so:
>
> (1) I'd like a feel for home common/popular is the mangling
> described by John Rose:
> https://blogs.oracle.com/jrose/entry/symbolic_freedom_in_the_vm
>
> (2) What tools, if any, such as IDEs, support this mangling?
>
> (3) Any problems or suggested modifications to John's proposal?

I didn't get any answers to the above questions, but I went ahead anyway:
I checked in a patch to the Kawa repository to use the "Symbolic Freedom"
mangling for class names (though not at this point for fields or methods).