Why not mangle the => to to import hy from python

[minghu6]

I mean there are mapping relationship bettwen hylang and python "symbol"

Hylang	Python
*global-and-constant*	GLOBAL_AND_CONSTANT
this-is-a-func	this_is_a_func

and I recommend add mapping: arrow->two <=> arrow_to_two, according to clojure style

In particular:
Not about the hy2py #970 , just add new rule in hy_symbol_mangle in hy.lex.parser.
So, I can write a function in demo.hy:

(defn camelcase->snakecase [name]
  (->> (sub "([A-Z]+)([A-Z][a-z0-9])" r"\1_\2" name)
       (sub "([a-z0-9])([A-Z])" r"\1_\2")
       (.lower)))

and using it in python

# or camelcase_2_snakecase etc, I don't mind
from demo import camelcase_to_snakecase

[Kodiologist]

In the title of this issue, you mention a mangling rule mapping => to to, and in the body, you mention a rule mapping -> to _to_. Are you proposing both of those, or only one?

You might want to check out #1458, where I'm currently proposing some sweeping changes to mangling.

[gilch]

I'm not feeling very enthusiastic about making the mangling rules any more complicated then they already are. I'd even approve removing the ?/is thing. #1458 has pretty straightforward rules though.

By the way, Clojure would munge foo->bar to foo__GT_bar. In Clojure, if you're writing methods to be used from Java, you make them easy to write in Java. It's the same with Hy and Python.

[minghu6]

@Kodiologist actually, what I am concerned is there is some way to mangle this symbol camelcase->snakecase, no mater the rule.

The name scope of Hy is larger than Python, mapping every special character perfectly is hard and make the variable name legible which is worried by @gilch.

In my opinions, we can only be care about specific case (mangle based on the whole name other than single character):

In fact, most symbol whose name contans special character writen and expected to use inner hy module, such as func* (and maybe no one wants to using Hy, hello world in python).

We can only mangle the symbol name which can be exposed from hy module to py module (the naming rule is part of coding style), for example: *global-and-constant*, func-no-special-char, returnbool? sideeffect! a->b
and ignore such as *!!no-obvious-meaning?!*. (maybe can use (sub r"^(\w[a-zA-Z0-9]*)\?$" r"is_\1" symbol-name) to match returnbool?)

[Kodiologist]

I'm not sure I understand you. Mangling, as currently conceived, is applied to entire symbols, but defined in terms of its effects on individual characters. After all, the whole point is to remove characters that aren't legal in Python identifiers. So, mangling camelcase->snakecase requires deciding how to treat - and >. Under what I'm proposing in #1458, - would become _ (as Hy already does) and > would become Δgreater_thanΔ.

At any rate, I agree with Gilch in that I would prefer not to add more mangling rules.

[minghu6]

Let me rephrase that, #1458 isn't releated about my issue. How to mangle each single char is hy2py's work.

If we can set some convention about name mapping bettwen py and hy. And in other case, we use mangle rule.

[gilch]

hy2py is just the compiler then astor. If we want valid symbols in Python, the compiler has to put them in the AST in the first place. And what should ->> mangle to? _to_Δgreater_thanΔ? How does that make any sense? And it introduces a leading underscore, which can mean something in Python. Maybe hyx__to_Δgreater_thanΔ? Or do we ignore the -> to _to_ conversion when it happens to be in front? when we have to introduce hyx_? It's not clear you've thought this through.

[vodik]

How about, as an alternative, using metadata (#1482) you could override the mangling? Something like:

(defn ^{:export "camelcase_to_snakecase"} camelcase->snakecase [name]
    ...)

Its certainly wordier, but could improve python/hy interop without having to add more and more mangling rules.

[Kodiologist]

If you want to explicitly define a Python-friendly name for a value, it suffices to say e.g. (setv camelcase_to_snakecase camelcase->snakecase).

[vodik]

Very good point!

[gilch]

Using metadata is an interesting approach. It could work on any symbol and this would allow the user to specify a more appropriate name for the AST than the automatic mangling rules ever could. But names have to be used more than once, otherwise there's no point to assigning names. And the same symbol name can have different metadata attached. That means every use of that name would need the same metadata to refer to the same value/compile to the same name in the AST. So there's no benefit on the Hy side whatsoever. You might as well use the Python-side name in the first place. It would be shorter. That particular approach is not going to work.

You could perhaps allow the user to create a lookup table of custom translations that apply to a single module, which the compiler would use when naming things in AST. But you'd have to use the translated name outside the module, unless you imported the table somehow. But then there could be collisions. It seems like more trouble than it's worth, unless it's a coherent part of a better namespacing system, which I've considered before. #277 #434 #1407.

If you want to explicitly define a Python-friendly name for a value, it suffices to say e.g. (setv camelcase_to_snakecase camelcase->snakecase).

That works fine for module-level things that you'd import directly by name, but for method names, this amounts to monkeypatching, which has other problems. You could pull the method off the class and rename the resulting function but then you lose polymorphism. You could use some object to translate on your behalf, but this doesn't seem any better than using getattr with the Hy name.

[Kodiologist]

At any rate, it looks like we're not going to add a special mangling rule per se for -> or =>